Role-based training
Role-based security training teaches each role the security skills its work needs: developers the weaknesses their languages and frameworks produce, platform engineers secrets and build security, champions threat modeling and secure design. It is hands-on, with exercises whose tests fail until the code is fixed.
Generic awareness courses rarely change what a team ships. A team that keeps building SQL from strings in one service needs practice on that pattern in its own language, ideally on the day the finding lands. Tying training to findings also produces the evidence assessors ask for: SSDF task PO.2.2 asks for role-based training and periodic review of proficiency, and PCI DSS 6.2.2 for developer training at least yearly.
- Who
- AppSec or the program lead builds the curriculum, champions help deliver it, and every engineer takes their role's track
- When
- At onboarding, when a security finding is assigned to someone, and when a team's most common weaknesses change
- How often
- Onboarding, a refresher at least yearly, a fix guide with each security ticket, and often a quarterly curriculum review
- You end up with
- A curriculum per role, dated training records per person with evidence, and before-and-after counts of repeat findings per team
Do this
Find each team's top weaknesses
Group the last two quarters of confirmed findings by CWE and team. Those, not a generic top-10 list, set each team's topics: a checkout team with repeated CWE-89 practices parameterized queries in its own language, and a platform team with leaked keys practices moving secrets out of code (Secrets out of code).
Define the roles and the outcome for each
List the roles that touch the software, such as web and API developers, platform engineers, testers, tech leads and champions. For each, write the outcome you want, such as "writes and tests object-level authorization checks", then the curriculum and a training plan. These are the first notional examples SSDF lists for PO.2.2.
Make every module hands-on
Use exercises with a test that fails until the learner fixes the code: browser labs (Labs and projects), fix cards that show a vulnerable, a fixed and a plausible but wrong fix in several languages (Fix cards), or a closed finding from the team's own code. SAMM's level-2 training activity asks for training customized by role and for the technologies each group works with.
Train at the moment of need
When a finding is assigned, link the matching fix card or guide in the ticket and ask for its regression test in the fix. A ticket template with a fix guidance field filled in from the CWE is enough to start. BSIMM16 lists the shift from traditional training to just-in-time training and open collaboration among its trends.
Give champions and leads a deeper track
In SAMM, champions get the same training as developers and testers, plus threat modeling, secure design and the security tools that can run in the build. A regular session built from the organization's own findings and test reports keeps it relevant; see Owners and champions.
Keep a dated record per person
Record who was trained, when, on which topics, languages and tools, with evidence an outsider can check, such as a lab result, a CI run of a project's tests or a merged fix with its test. PCI DSS v4.0.1 requirement 6.2.2 asks for training at least once every 12 months for staff developing bespoke and custom software, and SAMM's level-1 activity asks for an auditable sign-off.
Measure repeat findings, not completion
For each team and trained CWE, compare findings in a window before and after training, such as 180 days each, using the same scanners and review checklist in both windows. Report completion and quiz scores only as inputs. If a team still ships the weakness, look for a missing shared library, an unsafe framework default or a skipped review before scheduling more training.
Done when
Each team's training topics come from the findings it actually gets, and its repeat findings are compared before and after.
Mark it in the gap checkCommon mistakes
- Buying a video library and reporting completion as success: the completion rate rises while the same findings keep arriving.
- Teaching the OWASP Top 10 in the abstract instead of the weaknesses each team ships, in the languages it uses.
- Training once a year with nothing linking a later finding back to the lesson, so nobody learns whether it worked.
- Ranking teams or people by training scores. It rewards gaming and hides the teams that need help; compare each team with its own history instead.
- Keeping records that cannot say who was trained, when and on which topics, so an assessor cannot rely on them.
- Prescribing more training for every repeat finding when the cause is a missing shared library, an unsafe framework default or a skipped review.
What do common requirements ask for?
None of these asks for slides. Hands-on modules satisfy them when the records show who did what, when, and on which topics.
| Requirement | Who | What it asks |
|---|---|---|
| NIST SSDF 1.1, task PO.2.2 | Everyone with responsibilities that contribute to secure development | Role-based training, with periodic review of proficiency and of the training itself |
| OWASP SAMM Education and Guidance, level 1 | All roles involved in managing, developing, testing or auditing the software | Awareness training with an auditable sign-off, at onboarding and at least every 24 months or when the content changes |
| OWASP SAMM Education and Guidance, level 2 | Product managers, developers, testers and security auditors; champions | Training customized by role and technology, updated and delivered annually |
| PCI DSS v4.0.1, requirement 6.2.2 | Software development personnel working on bespoke and custom software | Training at least once every 12 months on security relevant to their job and languages, secure design and coding, and the security testing tools they use |
Tools and guides
- Browser labs
- Fix cards by stack
- Learning paths
- Workflow: Fix a finding
- Run a developer security training program that changes code
Build role-based, hands-on developer security training from this site's learning paths, labs and fix cards, meet PCI DSS 6.2.2, NIST SSDF PO.2.2 and ISO/IEC 27001 A.6.3 with real evidence, and measure the effect with repeat findings instead of completion rates.
- Run a security champions program with protected time and outcome metrics
Put a trained engineer with protected hours in every in-scope team, write the role into a one-page charter, route sensitive changes and findings through champions and AppSec, and judge the program by coverage and outcomes instead of attendance.
Standards
- NIST SSDF 1.1
- PO.2 Implement Roles and Responsibilities
- OWASP SAMM 2
- Education and Guidance
Sources
- OWASP SAMM: Education and Guidance, stream A (Training and Awareness)
- NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. February 2022.
- NIST OSCAL content: SP 800-218 version 1.1 catalog (PO.2.2 task and examples). oscal-content v1.5.0.
- PCI SSC document library: PCI DSS v4.0.1. v4.0.1 (June 2024).
- Black Duck: BSIMM report page (BSIMM16 trends). BSIMM16, January 2026.