OWASP Security Culture
This project aims to help organizations tailor their security efforts so developers can consistently build secure software. Version 2 introduces SECUR-E, an open framework based on COM-B and DASP research, to identify whether barriers to secure development stem from capability, opportunity, or motivation. Users can then select targeted interventions. Features include self-assessment, scoring, persona guidance, team visualizations, playbooks, and progress tracking to support better security culture. Personas reflect current conditions, not fixed identities. Results should never be used for hiring, performance, or disciplinary decisions. The framework is under expert review and community testing.
Make one part clearer, safer, more useful or more defensible.
SECUR-E becomes trustworthy through specific reviews, honest pilots, transparent disagreements, careful translations and research that is willing to disconfirm the current model.
Read this once before contributing.
Responsible use is the project’s non-negotiable rule. No contribution may enable hiring, promotion, performance review, discipline, access control or non-consensual individual profiling.
Read the full statement in the Responsible Use section.
Every rung is a legitimate stopping point.
Learn: Understand COM-B, the workflow and interpretive limits.
Try: Take and score the assessment yourself.
Facilitate: Run the 90-minute workshop safely.
Pilot: Complete a four-week or longitudinal pilot.
Validate: Review methods, collect data or lead a study.
Adapt: Translate, localize or extend the toolkit.
Publish: Share field notes, case studies or papers.
Behavior, psychometrics, survey clarity or interventions
30 min–5 hrs. Review one subscale, threshold set, persona card or visualization. Name the issue, explain why it matters and cite evidence where the change affects an intervention claim.
Behavioral science: D1 + D6
Psychometrics: D1 + D3
Survey / UX writing: D2
Intervention feasibility: one D6 persona section
Dry run, workshop, pilot or field note
30 min–6 months. Report where the process confused, stalled or changed the team’s understanding. A failed tactic is more informative than a polished testimonial.
Individual feedback
Team dry run
Four-week pilot
Organizational pilot
300-word field note or full case study
Translation, adaptation, tooling or visualization
2 hrs–ongoing. Make the framework more usable without silently changing constructs or scoring behavior.
Translation decisions log required
Two native-developer reviewers
“Not equivalence-tested” label until invariance evidence
Tooling checked against D3 worked examples
Validation, prediction or intervention research
Study-dependent. Choose an open question, preregister where appropriate, use purpose-specific consent and publish null or contradictory findings.
Cognitive interviews
Reliability / EFA / CFA
Threshold and clustering studies
Longitudinal intervention evaluation
Cross-cultural adaptation
Facilitation, chapter events and contributor support
2–4 hrs/month. Help people use the materials safely, route contributions and make learning visible.
Community assessment hour
Workshop host
Localization maintainer
Contributor mentor
Project update support
Start with one concrete observation.
“Item 15 was interpreted in two different ways,” “the team grid exposed a small group,” or “this tactic would fail in regulated fintech” are all valid starting points.
Contact Maintainers via OWASP
Honest, specific and evidence-aware.
Disagreement is documented, not suppressed.
Failure and surprise are reported, not edited out.
Individual confidentiality is preserved even in internal pilots.
Intervention changes include an evidence anchor or clearly labeled field evidence.
Translations document what was adapted and why.
Tooling reproduces D3’s worked examples before release.
Transparent intake, two-step review, public rationale.
A named maintainer performs a scope, license and responsible-use check within 14 days. Domain review then follows: content changes need practitioner and research-side review; tooling needs correctness testing; translations need native-developer and cultural review.
Any contribution can be declined on responsible-use grounds. That criterion overrides all others.
Submit through form, issue or PR
Scope and safety check
Domain review
Public decision and rationale
Changelog and attribution
Project Resources
Project Information
Slack