Run a developer security training program that changes code

Developers change how they write code after they have broken and fixed the same mistake in code that looks like theirs. A lab with a failing test gives that experience in minutes; a slide deck about the OWASP Top 10 does not. OWASP SAMM makes the same distinction: its first Education and Guidance activity is awareness training for everyone, with an auditable sign-off, and its second is training customized to roles and technologies, including the security nuances of each language and platform.

This site is built for that second kind. The learning paths at /learn/ combine guides with labs that run in the browser and check the learner's fix against attack cases. The downloadable projects on /labs/ come with a starter that fails its tests and a reference fix that passes. The fix cards at /fix/ show a vulnerable, a fixed and a plausible but wrong fix for one weakness in Node.js, Python, Java and C#, each with a regression test.

Three common obligations ask for training, with different scope. None of them asks for slides; all of them accept hands-on modules if the records show who did what, when, and on which topics.

Start every engineer with the same short, hands-on path, then add one role track. Keep each track to what that role ships. Choose the yearly refresh from the team's own top CWEs rather than repeating the onboarding path.

Store the curriculum as data so the training record, onboarding checklists and reports all read the same source. The file below maps roles to paths, labs and fix cards on this site and states the just-in-time rule. Review it when your top CWEs change and when SSDF PO.2.2's "periodically review" falls due.

# Role-based curriculum built from softwaresecurity.com paths, labs and fix cards.
# Paths and labs are hands-on; "evidence" is what the training record stores.
roles:
  all-engineers:
    onboarding: [/learn/developer-foundations/]
    labs: [/labs/authorization/, /labs/webhooks/]
    yearly_refresh: one lab and one fix card chosen from the team's top CWEs
    evidence: lab verdict screenshots or project test runs, dated
  web-and-api:
    onboarding: [/learn/browser-api-defense/]
    labs: [/labs/csrf/, /labs/archive-paths/, /labs/checkout-race/]
    fix_cards: [/fix/xss/, /fix/sql-injection/, /fix/missing-authorization/, /fix/ssrf/, /fix/csrf/]
  identity-and-accounts:
    onboarding: [/learn/identity-lifecycle/]
    labs: [/labs/token-validation/, /labs/recovery/]
    fix_cards: [/fix/jwt-validation/, /fix/session-cookies/, /fix/password-hashing/]
  platform-and-build:
    onboarding: [/learn/supply-chain-assurance/, /learn/runtime-defense/]
    labs: [/labs/sbom-inventory/, /labs/artifact-policy/, /labs/kubernetes-policy/]
    fix_cards: [/fix/hardcoded-secrets/, /fix/tls-certificate-validation/]
  ai-features:
    onboarding: [/learn/ai-application-defense/]
    labs: [/labs/rag-isolation/, /labs/agent-tool-gateway/, /labs/output-rendering/]
  cryptography-owners:
    onboarding: [/learn/cryptography-foundations/]
    labs: [/labs/nonces/]
    fix_cards: [/fix/insecure-randomness/]
  tech-leads-and-champions:
    onboarding: [/learn/appsec-practitioner/]
    practice: [threat model one feature per quarter, review two security-relevant pull requests per sprint]
  security-leads:
    onboarding: [/learn/security-program-assurance/]
    labs: [/labs/release-evidence/]
just_in_time:
  trigger: a finding is assigned to an engineer
  action: link the fix card for the finding's CWE in the ticket and ask for its test to pass on the fix

The best time to learn about SQL injection is when a SQL injection finding is assigned to you. When a scanner, review or report produces a finding, put the matching fix card or guide in the ticket, and ask for the card's regression test, adapted to the code, in the fix. The engineer learns the pattern, the fix arrives with a test, and the record shows training tied to a real weakness.

Look up the card by CWE on the CWE pages at /cwe/ or the Fix a finding router at /workflows/fix-a-finding/. Add the link automatically where your tracker allows it; a ticket template with a "Fix guidance" field filled from the CWE is enough to start.

• Finding with CWE-89 in a Node.js service: link /fix/sql-injection/node-express/ and ask for its test.
• Finding with CWE-862 or CWE-639 in an API: link /fix/missing-authorization/ and /domains/appsec/authorization/object-level-authorization/.
• Finding in a design review: link the threat pattern and run a 30-minute session with the team on it.

An assessor for PCI DSS 6.2.2 will ask which developers are in scope, when each was last trained, on which topics, and whether the topics match their job and languages. Keep one record per person per year with dates, topics, languages, tools and the evidence of each module. Prefer evidence an outsider can check: a lab result, a CI run of a project's tests, a merged fix with its regression test.

This site's progress export (the "Export progress" button on learning path pages) downloads a list of completed item IDs stored in the learner's browser. It has no name or dates and is self-reported, so use it as input to your own record, not as the record.

{
  "person": "e-1042",
  "role": "web-and-api",
  "languages": ["TypeScript", "Python"],
  "period": {"start": "2026-01-01", "end": "2026-12-31"},
  "requirement": "PCI DSS v4.0.1 6.2.2; NIST SSDF 1.1 PO.2.2",
  "modules": [
    {
      "id": "learn/browser-api-defense",
      "completed": "2026-03-12",
      "topics": ["secure design", "secure coding", "security testing tools"],
      "evidence": "lab csrf passed 2026-03-10; project express-api reference tests passed in CI run 81423"
    },
    {
      "id": "fix/sql-injection/node-express",
      "completed": "2026-06-02",
      "trigger": "finding APPSEC-311 (CWE-89)",
      "evidence": "fix merged in PR 2210 with the card's regression test"
    }
  ],
  "tools_covered": ["Semgrep rules used in CI", "dependency scanner"],
  "recorded_by": "appsec-team",
  "recorded_on": "2026-06-03"
}

Completion rate, quiz score, hours and satisfaction show that training happened, not that code changed. Report them as inputs, and judge the program by outcomes in each team's code, compared with that team's own history: teams that volunteer early are often already stronger, so comparing teams with each other misleads.

The script compares, for each team and trained CWE, the findings opened in a window before the training date with the same window after it. In the sample, checkout's SQL injection findings fell from 3 to 1 in 180 days, while search still had 3 XSS findings after training and billing had 1 IDOR finding in each window. Search is the team to visit: the training did not change what it ships, so look at its templates and code review before scheduling more training.

Small counts are noisy. Use the comparison to decide where to look, not to grade people, and keep the same finding sources (scanner rules, review checklist) across both windows, or the numbers will move for reasons unrelated to training.

"""Compare findings of a trained CWE before and after each team's training.

Usage: python repeat_findings.py findings.csv training.csv [window_days]
Counts findings with the trained CWE in the window before and after the training date.
"""
import csv
import sys
from datetime import date, timedelta


def rows(path):
    with open(path, newline="", encoding="utf-8") as f:
        return list(csv.DictReader(f))


def compare(findings, training, window):
    for t in training:
        trained = date.fromisoformat(t["trained"])
        dates = [
            date.fromisoformat(f["opened"])
            for f in findings
            if f["team"] == t["team"] and f["cwe"] == t["cwe"]
        ]
        before = sum(trained - window <= d < trained for d in dates)
        after = sum(trained <= d < trained + window for d in dates)
        yield t["team"], t["cwe"], before, after


if __name__ == "__main__":
    window = timedelta(days=int(sys.argv[3]) if len(sys.argv) > 3 else 180)
    print(f"{'team':10} {'cwe':8} before after  ({window.days}-day windows)")
    for team, cwe, before, after in compare(rows(sys.argv[1]), rows(sys.argv[2]), window):
        flag = "  <- no improvement" if after >= before else ""
        print(f"{team:10} {cwe:8} {before:6} {after:5}{flag}")

• Onboarding: the foundations path and one role track in the first weeks, about half a day of hands-on work in total.
• Just in time: a fix card or guide with every security ticket, as the default.
• Yearly: one refresher per person chosen from the team's top CWEs, which also satisfies the PCI DSS 12-month cycle when records are kept.
• Quarterly: a review of each team's repeat findings and an update to the curriculum file.
• Champions: a monthly session built from the organization's own findings, as in /frameworks/security-champions-program/.

• Buying a video library and reporting completion as success.
• Teaching the OWASP Top 10 in the abstract instead of the CWEs each team actually ships, in its languages.
• Training once a year with nothing linking a later finding back to the lesson.
• Ranking teams or people by training scores; it rewards gaming and hides the teams that need help.
• Keeping records that cannot answer "who, when, what topics" for an in-scope developer.
• Treating more training as the answer to every repeat finding when the cause is a missing library, framework default or review step.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. PCI SSC document library: PCI DSS v4.0.1. v4.0.1 (June 2024).
2. NIST SP 800-218: SSDF 1.1 (PO.2.2 role-based training). Version 1.1 (February 2022).
3. OWASP SAMM: Education and Guidance, stream A (Training and Awareness)
4. OWASP SAMM: Education and Guidance practice
5. BSIMM16 report: Training practice activities. BSIMM16 (January 2026).
6. OWASP Security Champions Guide
7. MITRE CWE: CWE-312 Cleartext Storage of Sensitive Information. CWE 4.20.

Reference information

Tags

AppSec programsSecure development lifecycleCompliance and assurance evidence

SDLC phase

Security program

Role

DevelopersAppSec engineersSecurity leaders

Download this guide as Markdown

Continue exploring