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.
Use SECUR-E to improve conditions-not to evaluate people.
Psychological safety is not a side constraint. It is a precondition for honest responses, trustworthy interpretation and any useful team action.
Never use SECUR-E for personnel decisions.
Results must not influence hiring, promotion, performance review, disciplinary action, compensation, access control, team ranking or judgments about a developer’s general competence or character.
Appropriate uses
Private self-reflection and development planning
Voluntary, aggregate-first team learning
Designing organizational support and interventions
Evaluating the usability of project materials
Consented research under an appropriate protocol
Anonymized, failure-friendly case studies
Red-line uses
Comparing or ranking individual developers
Classifying colleagues without self-report
Mandatory disclosure of individual personas
Small-group reporting that enables re-identification
Using low Motivation as evidence of misconduct
Using a profile as a diagnosis or validated prediction
Individual results are private by default.
Voluntary participation: Explain purpose, use, audience, retention and deletion before the assessment. A team exercise is not voluntary if refusal carries a penalty.
Data minimization: Section A context is optional (D2). Use pseudonyms, collect only what the agreed purpose requires and avoid unnecessary demographic cuts.
Explicit ownership: Choose individual-held, facilitator-held or research-partnered data handling in writing before collection.
Separate consent: Team use, research use and publication are distinct purposes and require separate consent. Withdrawal includes deletion where promised.
Safe aggregation: Do not report any group or subgroup below five. For teams of four or fewer, skip persona counts and use band-level discussion only.
Retention limits: Set access, storage, review and deletion dates at intake. Do not keep individual sheets “just in case.”
Language changes behavior.
Avoid: “Alex is Resistant.” Use: “The current profile shows a Resistant-like pattern with moderate confidence.”
Avoid: “Half the team lacks motivation.” Use: “Motivation scores cluster low under current conditions; Opportunity data suggests specific environmental barriers.”
Avoid: “Who are our weak developers?” Use: “Which conditions are limiting secure behavior, and what can the organization change?”
Avoid: “The assessment proved the intervention worked.” Use: “The profile changed after the intervention; further evidence is needed to attribute causality.”
Aggregate first. Environment first. One action.
Teach the model before showing data. Open the results conversation with Opportunity. Never announce an individual pattern. Treat resistance as possible process feedback, and protect any T4 signal from group exposure.
Sponsor commitment
No performance use
No request for individual profiles
Resources for at least one environmental action
Aggregate results only
Confidentiality incidents escalated
Reassessment follows the original data model
Concerns jump the normal contribution queue.
The governance model requires acknowledgment within 72 hours and review within 14 days. Outcomes may include correction, additional safeguards, revocation of pilot status or referral to OWASP Foundation processes. Use the official project page to locate the monitored reporting channel.
Low Opportunity is an organizational finding.
When tools are noisy, security work has no protected time, expertise is inaccessible or delivery pressure dominates, the appropriate response is to improve the environment-not to assign blame or demand more individual motivation.
Project Resources
Project Information
Slack