Secure Software Development Life Cycle (SSDLC)
Document control
| Field | Value |
|---|---|
| Owner | Ron Benisty — CTO & CSO (ron.b@iontwrks.com) |
| Status | Approved |
| Version | 1.1 |
| Classification | Confidential |
| Approved by | Ron Benisty — CTO & CSO |
| Approval date | 2026-02-12 (Thursday); revised 2026-05-26 |
| Last reviewed | 2026-05-26 |
| Review cycle | Annual — next review due February 2027 |
This is S.E.T's Secure SDLC — the lifecycle-wide policy governing how software is securely planned, designed, built, deployed, and maintained. It is explicitly aligned to:
- ISO/IEC 27001:2022 — Annex A controls (clause 8 secure-development cluster + supplier/vulnerability controls)
- SOC 2 Type II — Trust Services Criteria (operating effectiveness over time)
- NIST SP 800-218 (SSDF v1.1) — the practice backbone (PO · PS · PW · RV)
The build, dependency-integrity, and deploy portion is implemented in depth in Supply Chain & CI/CD Security. This document is the umbrella that wraps the whole lifecycle, maps it to the frameworks, and tracks the gaps that build/pipeline controls alone do not cover.
v1.7 status (2026-05-26) — SSDLC fully complete. All 16 of the original gap-analysis items + all 5 unbracketed gaps are closed by named, version-controlled policies. There are no outstanding SSDLC items. The focus shifts from writing the policies to operating them and accumulating audit evidence across the SOC 2 Type II audit window.
Status legend: In place = implemented & documented · Partial = mechanism exists, formalization/evidence missing · Gap = not yet built.
1. Purpose & scope
- Purpose: ensure security is built into every phase of development, not bolted on — and that there is auditable evidence the process runs continuously.
- Scope: all S.E.T application code, infrastructure-as-code, AI prompt assets, and the CI/CD pipeline — developed by the contracted third-party firm and operated by the S.E.T team.
- Audience: engineering, the third-party dev firm, security/compliance, and external auditors.
2. The lifecycle — controls & required evidence per phase
| Phase | Key controls | Evidence an auditor expects | Status |
|---|---|---|---|
| Requirements | Security & privacy requirements per feature; data classification | Security-requirements record, abuse/misuse cases | Gap |
| Design | Secure architecture principles; threat modeling | Threat model (STRIDE / data-flow), design review sign-off | In place (Security Requirements & Threat Modeling Policy v1.0 + principles in Architecture) |
| Develop / Code | Secure-coding standard; developer training | Written coding standard, lint/SAST config, training records | In place (Secure Coding Standard v1.0 + Developer Security Training Policy v1.0; SAST/lint in pipeline) |
| Test | SAST, DAST, code review, pen testing | Scan reports, review records, pen-test report | In place (SAST/SCA per Release Gate Criteria; DAST + pen-testing per DAST & Penetration Testing Policy v1.0) |
| Build | Pinned actions, hardened runners, SBOM, signing | SBOMs, signatures, Harden-Runner logs | In place (Supply Chain & CI/CD Security) |
| Release / Deploy | Change management; signed artifacts; gated deploy; release criteria | Change records w/ approvals, release notes, signatures, gate evidence | In place (Change Management + Release Gate Criteria) |
| Operate / Maintain | Vulnerability management; monitoring; incident response; backup & recovery | Vuln register + remediation SLAs, monitoring/incident logs, restore tests | In place (Vulnerability Management + Incident Response + Backup & Recovery + RCA) |
| Decommission | Information deletion; access & key revocation | Deletion records, key revocation, access removal | In place (Decommissioning & Data Deletion) |
3. ISO/IEC 27001:2022 — Annex A control mapping
| Control | Requirement | Status | Where / Action |
|---|---|---|---|
| A.5.2 Information-security roles & responsibilities | Defined and communicated | In place | Roles & Responsibilities (RACI) |
| A.5.3 Segregation of duties | Conflicting duties separated | In place | Separation of Duties |
| A.5.11 Return of assets | On role change / termination | In place (development scope) | Decommissioning §3 |
| A.5.18 Access rights | Provisioning, review, removal | In place | Access Reviews |
| A.5.24–A.5.28 IR family | Planning, reporting, response, learning, evidence | In place | Incident Response + RCA |
| A.5.31 Key management | Key generation, storage, rotation | In place | Cryptography Standard §8 |
| A.5.33 Protection of records | Records retained tamper-evidently | In place | Evidence Collection & Retention |
| A.6.3 Security awareness, education, training | Recurring training w/ records | In place | Developer Security Training Policy v1.0, 2026-05-26 (Snyk Learn + PortSwigger + OWASP + GitHub Skills + in-house sessions; 30-day onboarding + annual refresher + on-threat-emergence cadence) |
| A.8.8 Technical vulnerability management | Vuln inventory, scanning, remediation | In place | Vulnerability Management Policy v1.0, 2026-05-26 (CVSS v3.1 + KEV override; 7/30/90/120-day SLAs; GitHub Issues register; documented exception process) |
| A.8.10 Information deletion | Documented deletion of data | In place | Decommissioning §2 |
| A.8.13 Information backup | Backups + verified restore | In place | Backup & Recovery |
| A.8.15 Logging | Activities logged, protected, reviewed | In place | Observability + Evidence §4 |
| A.8.24 Use of cryptography | Documented rules for crypto choices | In place | Cryptography Standard |
| A.8.25 Secure development life cycle | Documented SSDLC rules across projects | In place | This document (the policy backbone) |
| A.8.26 Application security requirements | Security requirements specified per app | In place | Security Requirements & Threat Modeling Policy v1.0, 2026-05-26 |
| A.8.27 Secure architecture & engineering principles | Documented, applied | In place | Architecture (BFF, defense-in-depth, least privilege) |
| A.8.28 Secure coding | Written secure-coding principles applied | In place | Secure Coding Standard v1.0, 2026-05-26 |
| A.8.29 Security testing in dev & acceptance | Defined & performed security testing | In place | SAST/SCA via Release Gate Criteria; DAST + pen-testing via DAST & Penetration Testing Policy v1.0, 2026-05-26 (OWASP ZAP + Nuclei + annual third-party pen-test with vendor criteria) |
| A.8.30 Outsourced development | Direct, monitor, review outsourced work | In place | Supply Chain & CI/CD Security — access model, contract clauses, monthly/quarterly reviews |
| A.8.31 Separation of dev / test / prod | Environments separated | In place | Environments |
| A.8.32 Change management | Changes follow a change-management procedure | In place | Change Management |
| A.8.33 Test information | Test data protected; no prod data in non-prod | In place | Test Data Protection |
| A.8.34 Protection during audit testing | Audit-tool use scoped to avoid disruption | In place | Audit Testing Scope |
| A.5.19–A.5.23 Supplier & cloud-supply-chain security | Vendor risk assessment, agreements, ongoing review | ISMS-track (out of SSDLC scope) | Org-wide supplier/vendor management. The development supplier (dev firm) is covered under A.8.30 |
4. SOC 2 Type II — Trust Services Criteria mapping
Type II note: unlike Type I (design at a point in time), Type II tests operating effectiveness over a 3–12 month window. Auditors sample a population of evidence — many change tickets, every scheduled access review, recurring scans, training completions, incident drills. The binding requirement is continuous evidence collection — see Evidence Collection & Retention and §6 below.
| Criterion | What it covers / what auditors test | Status | Where / Action |
|---|---|---|---|
| CC1.x / CC2.x / CC5.x Governance, communication, control activities | Roles, competence, policy communication | In place | Roles & Responsibilities (RACI) + the full sibling-policy set under Secure SDLC — Policies |
| CC3.1–CC3.4 Risk assessment | Identify & assess risks (incl. fraud / SoD) | In place | Risk Assessment Policy v1.0, 2026-05-26 (annual + quarterly + on-major-change cadence; 5×5 qualitative scoring; 7-category register) |
| CC4.1–CC4.2 Monitoring | Ongoing + separate control evaluations | In place | Evidence Collection & Retention §5 quarterly review + Access Reviews |
| CC6.1–CC6.8 Logical access | Access to source, CI/CD, registries, prod (least privilege, provisioning, deprovisioning) | In place | Access Reviews + OIDC + branch protection + CODEOWNERS + Authentication |
| CC7.1 Detect new vulnerabilities | Monitor for changes introducing vulnerabilities | In place | OSV-Scanner, Trivy, GuardDuty |
| CC7.2 / CC7.3 Detect & evaluate anomalies/events | Monitoring + event evaluation | In place | Observability → Logz.io |
| CC7.4 / CC7.5 Incident response & recovery | IR process + recovery | In place | Incident Response + Backup & Recovery |
| CC8.1 Change management | Authorize → design → develop → test → approve → implement changes | In place | Change Management + Release Gate Criteria |
The exact SOC 2 criteria wording should be quoted from the licensed AICPA Trust Services Criteria (2017, rev. 2022) in the final audited version — the descriptions above are summaries.
5. NIST SSDF (SP 800-218) backbone
| Group | Practices | Status |
|---|---|---|
| PO — Prepare the Organization | PO.1 security requirements · PO.2 roles/responsibilities · PO.3 toolchains · PO.4 check criteria · PO.5 secure dev environments | In place — PO.1 (Security Requirements & Threat Modeling Policy v1.0) · PO.2 (RACI v1.0 + Developer Security Training Policy v1.0 for training) · PO.3 (toolchains) · PO.4 (Release Gate Criteria v1.0) · PO.5 (secure dev env per Environments) |
| PS — Protect the Software | PS.1 protect code from tampering · PS.2 verify release integrity · PS.3 archive/protect releases | In place — branch protection, signing (cosign), SBOMs, immutable images |
| PW — Produce Well-Secured Software | PW.1 design to requirements · PW.2 review design · PW.4 reuse secure components · PW.5 secure coding · PW.6 secure build · PW.7 code review/analysis · PW.8 test executable | In place — PW.1 / PW.2 (Security Requirements & Threat Modeling Policy v1.0) · PW.4 · PW.5 (Secure Coding Standard v1.0) · PW.6 · PW.7 · PW.8 (DAST & Penetration Testing Policy v1.0) |
| RV — Respond to Vulnerabilities | RV.1 identify vulnerabilities · RV.2 assess/prioritize/remediate · RV.3 root-cause analysis | In place — RV.1 (scanning) · RV.2 (Vulnerability Management Policy v1.0) · RV.3 (RCA v1.0) |
6. What's in place (do not rebuild)
The named policies that now sit under Secure SDLC — Policies:
- Change Management Policy — v1.0, 2026-05-25
- Separation of Duties Policy — v1.0, 2026-05-25
- Evidence Collection & Retention Policy — v1.0, 2026-05-26
- Roles & Responsibilities (RACI) — v1.0, 2026-05-26
- Incident Response Plan — v1.0, 2026-05-26
- Root-Cause Analysis Process — v1.0, 2026-05-26
- Access Reviews Policy — v1.0, 2026-05-26
- Test Data Protection Policy — v1.0, 2026-05-26
- Cryptography Standard — v1.0, 2026-05-26
- Backup & Recovery Policy — v1.0, 2026-05-26
- Release Gate Criteria — v1.0, 2026-05-26
- Audit Testing Scope Policy — v1.0, 2026-05-26
- Decommissioning & Data Deletion Procedure — v1.0, 2026-05-26
- Secure Coding Standard — v1.0, 2026-05-26
- Security Requirements & Threat Modeling Policy — v1.0, 2026-05-26
- Vulnerability Management Policy — v1.0, 2026-05-26
- Risk Assessment Policy — v1.0, 2026-05-26
- DAST & Penetration Testing Policy — v1.0, 2026-05-26
- Developer Security Training Policy — v1.0, 2026-05-26
The cross-cutting controls implemented elsewhere in this spec:
- Build & pipeline integrity — pinned-by-SHA Actions, Harden-Runner egress control, secret scanning (TruffleHog/Gitleaks), dependency + image scanning (OSV-Scanner/Trivy), SAST (Semgrep), SBOM (Syft/cyclonedx), signing (cosign),
npm ci --ignore-scripts. → Supply Chain & CI/CD Security - Access integrity — OIDC (no long-lived creds), job separation, least-privilege deploy roles, branch protection, CODEOWNERS, required reviews, GitHub-hosted runners only.
- Environment separation — nonprod vs. prod in separate AWS accounts. → Environments
- Monitoring & audit — VPC Flow Logs, GuardDuty, centralized logging, customer audit trail. → Observability & Logging
- Secure architecture principles — BFF, schema-per-tenant isolation, defense in depth. → Architecture · Multi-Tenancy
7. Gap analysis — what is still required (prioritized)
Status reflects the v1.1 sibling-policy set. Closed items are kept in place for traceability.
Priority 1 — foundational
- This SSDLC policy itself (A.8.25 / PO.1 / CC1.x) — Status: In place (v1.0 2026-02-12; v1.1 2026-05-26).
- Change management process (A.8.32 / CC8.1) — Status: In place (Change Management Policy v1.0, 2026-05-25).
- Third-party / outsourced-developer security (A.8.30) — Status: In place (Supply Chain & CI/CD Security).
- Continuous evidence-collection regime (SOC 2 Type II meta-requirement) — Status: In place (Evidence Collection & Retention Policy v1.0, 2026-05-26).
Priority 2 — core technical / process
- Secure-coding standard (A.8.28 / PW.5) — Status: In place (Secure Coding Standard v1.0, 2026-05-26).
- Security requirements + threat-modeling practice (A.8.26, A.8.27 / PW.1, PW.2) — Status: In place (Security Requirements & Threat Modeling Policy v1.0, 2026-05-26).
- DAST + penetration-testing cadence (A.8.29 / PW.8) — Status: In place (DAST & Penetration Testing Policy v1.0, 2026-05-26).
- Vulnerability-management policy with remediation SLAs (A.8.8 / RV.2) — Status: In place (Vulnerability Management Policy v1.0, 2026-05-26).
Priority 3 — governance & completeness
- Separation of duties (A.5.3 / CC3.x) — Status: In place (Separation of Duties Policy v1.0, 2026-05-25).
- Test-data protection policy (A.8.33) — Status: In place (Test Data Protection Policy v1.0, 2026-05-26).
- Developer security training (A.6.3 / PO.2) — Status: In place (Developer Security Training Policy v1.0, 2026-05-26).
- Periodic risk-assessment cadence (CC3.x / A.5.7) — Status: In place (Risk Assessment Policy v1.0, 2026-05-26).
- Defined roles & responsibilities (PO.2 / A.5.2 / CC1.x) — Status: In place (Roles & Responsibilities (RACI) v1.0, 2026-05-26).
- Incident-response plan + drills (CC7.4 / CC7.5) — Status: In place (Incident Response Plan v1.0, 2026-05-26).
- Root-cause-analysis process (RV.3) — Status: In place (Root-Cause Analysis Process v1.0, 2026-05-26).
- Decommissioning procedure (A.8.10) — Status: In place (Decommissioning & Data Deletion Procedure v1.0, 2026-05-26).
Additional items closed in v1.1
- A.8.34 Protection during audit testing — In place (Audit Testing Scope Policy v1.0, 2026-05-26).
- Periodic logical-access reviews (CC6.x) — In place (Access Reviews Policy v1.0, 2026-05-26).
- A.8.24 Cryptography standard — In place (Cryptography Standard v1.0, 2026-05-26).
- A.8.13 Information backup — In place (Backup & Recovery Policy v1.0, 2026-05-26).
- NIST SSDF PO.4 Check criteria — In place (Release Gate Criteria v1.0, 2026-05-26).
Outstanding (zero items) — SSDLC fully complete
All 16 priority items + all 5 unbracketed gaps are closed by named, version-controlled policies. The next phase is operating the controls and accumulating evidence over the SOC 2 Type II audit window — not writing further policies.
8. The Type II evidence model (why this matters)
ISO 27001 certification and SOC 2 Type I can be satisfied by having the controls designed. SOC 2 Type II (and ISO surveillance audits) require proof they operated consistently over months. Practically, every control above must emit a durable, timestamped artifact each time it runs — see the Evidence Collection & Retention Policy for the authoritative register and retention floors.
| Control | Recurring evidence to retain |
|---|---|
| Change management | One change record per production change |
| Access reviews | A signed review each cycle (monthly / quarterly / annual) |
| Vulnerability management | Scan results + remediation tracked to SLA |
| Pen testing | Annual report + remediation evidence |
| Training | Completion records per developer per cycle |
| Incident response | Drill records + any real-incident write-ups |
| Backup & recovery | Weekly restore tests + annual DR drill |
| Supplier review | Annual third-party-dev-firm review record |
All retained per the Evidence Collection & Retention Policy — same retention discipline as Supply Chain & CI/CD Security and Observability & Logging.
9. Document change history
Version-control and change-management record for this policy document (per A.8.32 change management). Every revision is logged here with its approver; the policy is re-approved on each material change and at each annual review.
| Version | Date | Author | Description of change | Approved by |
|---|---|---|---|---|
| 1.0 | 2026-02-12 | Ron Benisty (CTO & CSO) | Initial version — establishes the Secure SDLC policy. | Ron Benisty (CTO & CSO) |
| 1.1 | 2026-05-26 | Ron Benisty (CTO & CSO) | Revision after the sibling-policy build-out: closes 13 of 16 priority items + 4 additional gaps; updates ISO / SOC 2 / SSDF status tables; adds §6 policy inventory; restates §7 with outstanding-six list. | Ron Benisty (CTO & CSO) |
| 1.2 | 2026-05-26 | Ron Benisty (CTO & CSO) | Secure Coding Standard promoted from v0.9-draft to v1.0 Approved (all eight §11 decisions resolved). A.8.28 status flipped Partial → In place; PW.5 added to covered SSDF practices; Develop/Code lifecycle row updated; Outstanding list reduced from six to five items (#5 closed). | Ron Benisty (CTO & CSO) |
| 1.3 | 2026-05-26 | Ron Benisty (CTO & CSO) | Gap #6 closed by Security Requirements & Threat Modeling Policy v1.0 (STRIDE per-epic; four-tier data classification; Markdown+Mermaid templates; before-design-complete approval gate; MITRE ATT&CK assigned its proper home in Observability + IR). A.8.26 flipped Gap → In place; Design lifecycle row updated; PW.1 + PW.2 added to covered SSDF practices; Outstanding list reduced from five to four items. | Ron Benisty (CTO & CSO) |
| 1.4 | 2026-05-26 | Ron Benisty (CTO & CSO) | Gap #8 closed by Vulnerability Management Policy v1.0 (CVSS v3.1 + KEV override; SLAs 7/30/90/120 days; GitHub Issues register with mandatory labels + template; documented exception process with compensating-control requirement; monthly CTO & CSO review). A.8.8 flipped Partial → In place; Operate/Maintain lifecycle row flipped Partial → In place; RV group flipped Partial → In place (RV.2 added). Outstanding list reduced from four to three items. Closed-count reconciled (13 of 16 priority items + 5 unbracketed gaps). | Ron Benisty (CTO & CSO) |
| 1.5 | 2026-05-26 | Ron Benisty (CTO & CSO) | Gap #12 closed by Risk Assessment Policy v1.0 (annual + quarterly + on-major-change cadence; 5×5 qualitative scoring with four risk tiers; seven-category register; Mitigate/Accept/Transfer/Avoid treatment options). CC3.1–CC3.4 flipped Gap → In place. Outstanding list reduced from three to two items. All Bucket B items now closed — remaining two items (#7 DAST/pen-test, #11 dev training) are Bucket C and require external vendor / provider decisions. | Ron Benisty (CTO & CSO) |
| 1.6 | 2026-05-26 | Ron Benisty (CTO & CSO) | Gap #7 closed by DAST & Penetration Testing Policy v1.0 (OWASP ZAP baseline-per-PR + ZAP full-nightly + Nuclei-weekly against nonprod; annual full pen-test + targeted retests on major releases; vendor criteria locked, specific vendor deferred to procurement contract). A.8.29 flipped Partial → In place; Test lifecycle row flipped Partial → In place; PW group flipped Partial → In place (PW.8 added). OWASP ZAP + Nuclei added to the Supply Chain doc's Locked tool stack table. Outstanding list reduced from two to one item (only #11 dev training remains). | Ron Benisty (CTO & CSO) |
| 1.7 | 2026-05-26 | Ron Benisty (CTO & CSO) | Final gap closed — SSDLC fully complete. Gap #11 closed by Developer Security Training Policy v1.0 (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 including contractor developers; Markdown training-records register with quarterly CTO & CSO spot-checks; non-completion blocks PR merges). A.6.3 flipped Gap → In place. Develop/Code lifecycle row flipped Partial → In place. NIST SSDF PO group flipped Partial → In place (PO.1 retroactively recognized as closed by Security Requirements & Threat Modeling Policy v1.0; PO.2 now also covers training via Developer Security Training Policy v1.0). All 16 priority items + all 5 unbracketed gaps closed. Outstanding list at zero. Next phase: operate the controls and accumulate evidence over the SOC 2 Type II audit window. | Ron Benisty (CTO & CSO) |
10. References
- ISO/IEC 27001:2022, Annex A (controls A.5 + A.8 families as mapped in §3); guidance in ISO/IEC 27002:2022
- AICPA Trust Services Criteria (2017, revised 2022) — SOC 2 Common Criteria (CC1–CC8)
- NIST SP 800-218 — Secure Software Development Framework (SSDF) v1.1