Skip to main content

Developer Security Training Policy

Document control

FieldValue
OwnerRon Benisty — CTO & CSO (ron.b@iontwrks.com)
StatusApproved
Version1.0
ClassificationConfidential
Approved byRon Benisty — CTO & CSO
Approval date2026-05-26 (Tuesday)
Last reviewed2026-05-26
Review cycleAnnual — next review due May 2027
Parent policySecure SDLC (SSDLC)

Satisfies ISO/IEC 27001:2022 A.6.3 (information security awareness, education and training) and NIST SSDF PO.2 (organizational roles, training, and communications). Closes Gap 11 of the SSDLC gap analysis.


1. Purpose

Every developer who contributes code to S.E.T must have — and maintain — the security knowledge appropriate to building a multi-tenant compliance platform. This policy specifies what they learn, when they learn it, who must complete it, and how completion is evidenced for audit sampling.

2. Scope — who must complete

Every developer who contributes code to S.E.T:

This is the same scope as the Secure Coding Standard §10 acknowledgement. The same "did you read and acknowledge the standard?" gate and the "did you complete required training?" gate apply to the same set of people.

Out of scope: non-developer staff (their security awareness is a separate, lighter regime); sub-processor employees (governed by their own employers' training).

3. Training stack — free + in-house

S.E.T uses a layered free-stack approach combined with internal sessions for our specific context. No paid platform is required. All five components are mandatory in combination — none replaces another.

3.1 Snyk Learn — structured curriculum + completion tracking

The primary structured platform. Free, language-specific (TypeScript first-class for our stack), built-in module completion tracking.

Required modules per developer:

  • Top vulnerability classes (OWASP Top 10 series)
  • Secure JavaScript / TypeScript
  • Dependency vulnerability management
  • Container security
  • Cloud security fundamentals (AWS)

3.2 PortSwigger Web Security Academy — hands-on labs

Free, in-depth hands-on AppSec labs. Industry-recognized.

Required modules for everyone:

  • Authentication
  • Access control (BOLA / IDOR)
  • Cross-site scripting
  • SQL injection

Additional required modules for developers touching tenant-isolation, authentication, or cryptography code paths (per the Secure Coding Standard §8 heightened-review list):

  • OAuth + JWT vulnerabilities
  • Server-side request forgery (SSRF)
  • HTTP request smuggling
  • Web cache poisoning

3.3 OWASP curricula — reference baseline

Vendor-neutral reference material. Required readings for everyone:

  • OWASP Top 10 (most recent version)
  • OWASP Top 10 for LLM Applications (relevant to our AI workers — Phase 2)
  • OWASP Cheat Sheets for any topic touched by the developer's work

3.4 GitHub Skills — workflow-integrated micro-courses

Light-touch courses integrated with our actual toolchain.

Required courses:

  • Reviewing pull requests
  • Code security
  • GitHub Actions security

3.5 In-house S.E.T-specific sessions

The content no external platform covers — our actual architecture, our actual policies, our actual incidents. Delivered by CTO & CSO; recorded so new joiners can complete them asynchronously.

Required sessions for every developer:

SessionWhat it covers
S.E.T multi-tenancy patternsHow schema-per-tenant works, the Tenant Context Middleware, the connection-pool RESET search_path discipline, the cross-tenant isolation test suite (per Multi-Tenancy)
Amendment 13 + GDPR specificsWhat our data classification means in practice, residency obligations, breach-notification timelines
SSDLC sibling-policy walkthroughEvery policy in ssdlc-policies/, what each requires from a developer day-to-day
Threat-model walkthroughTwo or three real S.E.T threat models (from docs/threat-models/) read together, end to end
Recent-incident lessonsWithin 30 days of any Sev 1 or Sev 2 incident close, a 15-minute session covering what the RCA identified and what developers should change
S.E.T-specific risk reviewWalk-through of the Risk Register items that affect day-to-day dev decisions

4. Required curriculum — mandatory topics

The combined free stack + in-house sessions cover these mandatory topics. The topic checklist is tracked per developer in the training-records register (§6):

TopicPrimary source(s)
OWASP Top 10 (most recent)Snyk Learn + OWASP
OWASP Top 10 for LLM ApplicationsOWASP
Authentication, session management, JWTPortSwigger + Snyk Learn
Tenant-isolation patterns (S.E.T-specific)In-house
Cryptography correct usageSnyk Learn + Cryptography Standard reading
SQL injection / ORM safety (Drizzle-specific)Snyk Learn + in-house
XSS prevention (React-specific)PortSwigger + Snyk Learn
Access control / BOLA / IDORPortSwigger
Dependency vulnerability managementSnyk Learn
Secret management (AWS Secrets Manager)Snyk Learn + in-house
Supply-chain awareness (Shai-Hulud / tj-actions classes)In-house + Supply Chain & CI/CD Security §Threat model
Container securitySnyk Learn
Cloud security (AWS fundamentals)Snyk Learn
GitHub Actions securityGitHub Skills + in-house
Amendment 13 + GDPRIn-house
SSDLC + sibling policiesIn-house
Threat modeling (STRIDE)In-house + Security Requirements & Threat Modeling Policy

5. Cadence

TriggerRequired completion
OnboardingThe full curriculum (every required topic, every platform) must be completed within 30 days of the developer's first PR
Annual refresherEvery developer re-completes the curriculum every February, alongside the SSDLC annual review. Any new modules added in the past year are completed for the first time
Topic-specific micro-trainingWithin 30 days of a new threat class or material lesson — e.g. a new supply-chain attack pattern (another tj-actions-class event), a new major vulnerability class in our stack, a Sev 1 / Sev 2 incident with dev-applicable lessons

6. Completion tracking — the training-records register

The training-records register lives in the repo at docs/training-records.md — single Markdown file, versioned in git, diffable across cycles, no separate platform. Same pattern as the threat-model directory and the Risk Register.

6.1 Per-developer record

Each developer has a section in the file listing:

  • Developer name + role (S.E.T-team member or contractor)
  • Onboarding completion date + per-topic checklist
  • Annual refresher completion date per cycle
  • Topic-specific micro-training completed (date + topic)
  • Evidence link per module:
    • Snyk Learn — screenshot or shareable link to the platform's completion view + module date
    • PortSwigger Academy — completion certificate from the Academy
    • GitHub Skills — completion badge link
    • OWASP readings — self-attested + tested in an in-house follow-up quiz (one quiz per onboarding + one per annual refresher)
    • In-house sessions — attendance recorded + brief follow-up quiz

6.2 Verification

CTO & CSO spot-checks completion claims quarterly: pick 1–2 developers, verify the evidence links resolve and the claimed completions match. The spot-check finding (pass / fail per developer) is recorded in the quarterly Risk Assessment review record.

6.3 Non-completion handling

A developer who has not completed the required training by their target date:

  • S.E.T-team member: cannot have new PRs reviewed for merge until training is current.
  • Contractor developer: their dev-firm manager is notified; their PRs are not reviewed until current; persistent non-completion is escalated under the right-to-audit clause in Supply Chain & CI/CD Security §3.

The CTO & CSO grants individual extensions in 30-day increments only, with documented justification recorded in the training-records file.

7. Evidence + retention

ArtifactRetention
Training-records register (docs/training-records.md)Lifetime of S.E.T (versioned in repo)
Per-developer completion evidence (screenshots, certificates, badge links)≥ 24 months
In-house session recordings + attendance records≥ 24 months
Quarterly spot-check records≥ 24 months (part of quarterly risk-assessment evidence)
Annual cycle completion summary≥ 24 months

All per the Evidence Collection & Retention Policy. SOC 2 Type II will sample training records across the audit window.

8. Integration with other policies

  • Secure Coding Standard §10 — the signed standard acknowledgement is captured as a training-record entry; the two gates (acknowledgement + training) apply to the same developer scope.
  • Roles & Responsibilities (RACI) — "Developer security training — S.E.T team" and "Developer security training — dev firm" are explicit RACI rows. CTO & CSO is accountable.
  • Risk Assessment — the quarterly review covers training-compliance status; spot-check findings flow into the quarterly review record.
  • Incident Response — every Sev 1 or Sev 2 incident's RCA is evaluated for dev-applicable lessons; lessons become §5 topic-specific micro-training within 30 days.
  • Vulnerability Management — recurring vulnerability classes (per RCA's "third occurrence in 12 months" trigger) feed §5 topic-specific micro-training.

9. Dogfood note (clarification)

S.E.T's product trains MSSPs' end clients on security awareness. This policy is S.E.T's own developer training — entirely separate scope.

The two will not be confused: this policy governs the people who build S.E.T; the product's training module is for people who use S.E.T's customers.

10. Document change history

VersionDateAuthorDescription of changeApproved by
1.02026-05-26Ron Benisty (CTO & CSO)Initial version — free-stack curriculum (Snyk Learn + PortSwigger Web Security Academy + OWASP curricula + GitHub Skills) plus in-house S.E.T-specific sessions; 30-day onboarding + annual refresher + on-threat-emergence cadence; all contributors (S.E.T team + contractor devs) in scope; Markdown training-records register with quarterly CTO & CSO spot-checks; non-completion blocks PR merges.Ron Benisty (CTO & CSO)