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 persona language only after the three-dimensional profile and confidence level are clear. Say “a Skeptic-pattern profile under current conditions,” never “this person is a Skeptic.”
These patterns are heuristics. They are not personality types, diagnoses or competency grades. A result may be mixed or low-confidence, and a developer’s profile can shift when skills, team norms, tools, time or motivation change.
Primary lever: Reflective motivation
Profile: CAP: Moderate - OPP: Moderate - MOT: Low
Adequate skills and some support are present, but the perceived benefit-to-effort ratio remains unconvincing.
Strategy:
Evidence-based ROI persuasion
What may help:
Present domain-specific risk and remediation-cost evidence; involve the developer in a bounded security decision; address concrete past bad experiences; use technically credible peers.
What may backfire:
Do not answer ROI concerns with generic awareness training, unexplained policy or increased enforcement.
Transition target: Embedded
Typical timeframe: 6–18 months
Primary lever: Opportunity
Profile: CAP: High - OPP: Low - MOT: High
Strong capability and intrinsic motivation are compensating for limited time, tools, formal mandate or access to support. This creates burnout risk.
Strategy:
Close the organizational support gap
What may help:
Formalize a champion role; allocate protected time; provide the tools already identified; connect to peers; monitor workload and security isolation.
What may backfire:
Do not add security responsibility without resources, use the person as a substitute for organizational investment or assign generic motivation training.
Transition target: Embedded
Typical timeframe: 3–9 months
Primary lever: Motivation: reflective → automatic
Profile: CAP: Moderate - OPP: High - MOT: Low
Security behavior is being driven mainly by policy, monitoring and environmental enforcement. The behavior is real but fragile if those structures weaken.
Strategy:
Build internalized motivation while keeping support stable
What may help:
Connect security to user protection; reward proactive initiative; increase autonomy progressively; use intrinsically motivated peer models; keep support in place during transition.
What may backfire:
Do not remove enforcement to “test” commitment, treat stable compliance as the final outcome or appoint a champion before motivation has shifted.
Transition target: Embedded
Typical timeframe: 9–18 months
Primary lever: Capability first
Profile: CAP: Very low - OPP: Any / often low - MOT: Very low
Security is not yet visible enough for the developer to recognize risks, interpret tools or identify their own learning needs. Low motivation reflects invisibility rather than active opposition.
Strategy:
Build foundational capability before other levers
What may help:
Use concrete stack-relevant examples; scaffold skill maps; pair with a capable mentor; celebrate early milestones; introduce tools only when output can be interpreted.
What may backfire:
Do not begin with persuasion, mistake confidence for competence or frame slow foundational progress as an attitude problem.
Transition target: Skeptic or Compliant
Typical timeframe: 6–12 months to next viable profile
Primary lever: Autonomy and identity
Profile: CAP: Moderate - OPP: Moderate - MOT: Very low
Security requirements are experienced as threats to professional autonomy. Active opposition may also contain valid critique of noisy tools or wasteful processes.
Strategy:
Redesign security to preserve meaningful control
What may help:
Invite co-design of security processes; address specific bad experiences; reduce workflow friction; offer developer-controlled learning; act visibly on legitimate critique.
What may backfire:
Do not escalate compliance pressure, argue only about the content of objections or exclude the person from security decision-making.
Transition target: Skeptic
Typical timeframe: 6–18 months
Primary lever: Sustain and amplify
Profile: CAP: High - OPP: High - MOT: High
Security is habitual, intrinsically valued and supported by the environment. The risk is stagnation, isolation or becoming the team’s unresourced security function.
Strategy:
Recognize, develop and distribute security leadership
What may help:
Formalize an appropriately resourced champion role; fund advanced development; give process influence; support mentoring; distribute responsibility and plan succession.
What may backfire:
Do not assume no support is needed, overload the person or assign generic training below their level.
Transition target: Embedded
Typical timeframe: Sustain; review annually
Start foundational capability work for Unaware-pattern profiles. It is slow and cannot be replaced by motivation campaigns.
Invest early in Enthusiast-pattern profiles. Closing Opportunity gaps can create the fastest path to an Embedded security champion.
Put Resistant-pattern profiles on an autonomy-preserving track. Do this before compliance-framed team campaigns.
Use evidence-based persuasion with Skeptic-pattern profiles. Engage the actual cost-benefit question.
Build internalization over time for Compliant-pattern profiles. Keep environmental support stable while motivation shifts.
SECUR-E’s contraindications are intended to prevent standard security interventions from deepening burnout, reactance, dependence on enforcement or early-stage learning anxiety.
Download the full intervention guide.