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.
Summary
This roadmap covers the implementation of the SECUR-E Developer Security Self-Assessment Tool as version 2 of the OWASP Security Culture Project. SECUR-E is a structured, evidence-based tool for diagnosing and improving developer security behavior in software teams. It consists of six deliverables: (D1) a psychometric instrument, (D2) a self-assessment survey, (D3) a scoring and persona-classification framework, (D4) individual and team profile grids, (D5) visualization concepts, and (D6) a persona-specific intervention guide, all grounded in empirical research with software practitioners.
Phase 1: Foundation & Infrastructure
Objectives:
Kick off SECUR-E as a formal OWASP project (v2) in the OWASP Security Culture Project site.
Align the core team on roles, decision protocols, and communication cadence across time zones.
Publish the six SECUR-E deliverables (D1–D6) as versioned, openly licensed artefacts.
Establish an SME advisory panel from the security culture, behavioral science, and DevSecOps communities.
Define quality and maturity criteria for each deliverable in line with the OWASP Incubator - Lab - Flagship pathway.
Phase 2: SME Review & Instrument Refinement
Objectives:
Obtain structured expert review of the psychometric instrument (D1) and scoring framework (D3) for face validity, construct validity, and usability.
Review the survey instrument (D2) for language clarity and suitability for self-administration by developers without specialist knowledge.
Review the intervention guide (D6) with security culture and DevSecOps practitioners for ecological validity.
Incorporate SME feedback into a revised v1.1 artefact bundle.
Develop a facilitator guide and digital administration kit ready for the pilot phase.
Phase 3: Pilot Design & Participant Recruitment
Objectives:
Design a two-wave pilot protocol: Wave 1 (individual self-assessment, 80–120 developers) and Wave 2 (facilitated team sessions, 3–5 engineering teams).
Establish a GDPR-compliant data collection, storage, and privacy protocol.
Recruit Wave 1 participants from the OWASP community and external partner organizations.
Confirm Wave 2 engineering teams and sign data handling agreements with partner organizations.
Conduct an internal dry run to validate the instrument and logistics before Wave 1 opens.
Phase 4: Pilot Execution & Data Collection
Objectives:
Run Wave 1: individual self-assessment by 80–120 developers using the D1/D2 instrument and D3 scoring framework.
Analyze Wave 1 data for reliability, persona distribution, classification confidence, and participant usability feedback.
Revise the instrument and scoring rules based on Wave 1 findings before Wave 2 begins.
Run Wave 2: 3–5 facilitated engineering team sessions using the complete D1–D6 system.
Publish a public pilot findings report on the OWASP project page.
Phase 5: Refinement & Community Iteration
Objectives:
Incorporate all Wave 1 and Wave 2 findings into a refined, publication-ready v2.0 artefact bundle.
Open a structured community contribution process, inviting translations, sector-specific adaptations, and digital tool extensions.
Prepare a peer-reviewed academic submission based on the pilot data.
Phase 6: Maturity, Dissemination & Sustainability
Objectives:
Present SECUR-E v2 at an OWASP Global AppSec conference or chapter events.
Publish a practitioner adoption guide for organisations wanting to implement the system independently.
Establish a community maintenance model that is not dependent on the core team members.
Document lessons learned for the broader OWASP project community.
Draft the SECUR-E v3 scope based on community feedback, pilot findings, and academic peer review....