IEC 62443-4-1 Secure Development Lifecycle Assessment¶
Standard: ANSI/ISA-62443-4-1-2018: Secure product development lifecycle requirements (8 practices, 47 requirements) Assessed: 2026-07-18 against the purchased standard text (#970, epic #967) Maturity self-assessment: see Maturity. The headline is ML 2 (Managed) on this documentation baseline for seven of eight practices, with SVV the structural gap pending an external V&V engagement.
The SDL itself lives in docs/sdl/:
process (SM),
security requirements (SR),
secure design (SD),
secure coding standard (SI),
defect management (DM),
update management (SUM). Security
guidelines (SG) are the existing user-facing docs, mapped below.
Public wording rule¶
4-1 conformance is a claim about documented and practiced process. Until the backlog is cleared and one release cycle has produced records, the only defensible public wording is: "developed under a documented secure development lifecycle aligned to IEC 62443-4-1 practices." Never "conformant to", "certified", or "meets 62443-4-1". Component-level (4-2) wording must carry the CCSC 4 note that the SDL is self-assessed (already in the 4-2 assessment).
Practice-by-practice assessment¶
Dispositions: Met / Partial / Gap / N-A, judged against the requirement text. "Doc" points at the practice document that satisfies the written- process half. Partial rows say what practice/evidence is missing.
Practice 1 -- Security management (SM)¶
| Req | Title | Disposition | Notes |
|---|---|---|---|
| SM-1 | Development process | Met | process.md: single pipeline, change-controlled config management, traceability, ADRs, make verify parity, review records (#483) |
| SM-2 | Identification of responsibilities | Met | RACI in process.md; the standard permits external personnel — the vacant independent seats are explicitly assigned to the planned external engagement |
| SM-3 | Identification of applicability | Met | Whole product in scope; classification in the 4-2 assessment |
| SM-4 | Security expertise | Partial | Expertise process documented; the demonstrated-independent-expertise half arrives with the external engagement; no training records yet |
| SM-5 | Process scoping | Met | Scoping with documented justification (hardware-specific requirements excluded — no supplier hardware); scoping cannot and does not waive Table 3 independence |
| SM-6 | File integrity | Met | SHA-256 checksums, cosign signatures, SBOM per image, OCI digest pinning |
| SM-7 | Development environment security | Met | Pinned CI actions, CI-bound keyless signing identity, sandboxed AI-agent workflow with gated commits — documented proactively as an SM-7 item |
| SM-8 | Controls for private keys | Met | Exceeds intent: keyless Sigstore signing means no persistent code-signing private key exists to protect |
| SM-9 | Externally provided components | Met | go.sum integrity, Dependabot weekly, govulncheck + Trivy, SBOM transparency |
| SM-10 | Custom third-party components | N/A | No custom-developed third-party components; intake rule documented for when one appears |
| SM-11 | Assessing/addressing issues pre-release | Partial | Issue tracking to closure exists; the formal release gate is newly documented — first practiced execution pending |
| SM-12 | Process verification | Partial | Release checklist defined (process.md); first record pending next release |
| SM-13 | Continuous improvement | Met | The practiced defect→lint-gate loop (the make lint-* families born from field issues) is exactly this, now documented |
Practice 2 -- Specification of security requirements (SR)¶
| Req | Title | Disposition | Notes |
|---|---|---|---|
| SR-1 | Product security context | Met | security-requirements.md § context |
| SR-2 | Threat model | Partial | threat-model.md covers flows, boundaries, STRIDE, MITRE, mitigations; annual-review cadence newly adopted — first recorded periodic review pending |
| SR-3 | Product security requirements | Met | The clause-verified 3-3/4-2 matrices are the requirements spec, incl. installation/operation/maintenance/decommissioning pointers |
| SR-4 | Requirements content | Met | Scope/boundaries + SL-C target stated |
| SR-5 | Security requirements review | Partial | Review process + discipline seats documented; independent tester + security-advisor seats vacant until the engagement — interim reviews marked provisional |
Practice 3 -- Secure by design (SD)¶
| Req | Title | Disposition | Notes |
|---|---|---|---|
| SD-1 | Secure design principles (interface catalog) | Met | secure-design.md interface catalog with the clause's per-interface attributes |
| SD-2 | Defense in depth design | Met | Layer table with per-layer responsibility incl. delegated shares |
| SD-3 | Security design review | Partial | ADR + daily-review practice exists and is documented; external security-advisor participation pending engagement |
| SD-4 | Secure design best practices | Met | Documented, applied, and partially gate-enforced |
Practice 4 -- Secure implementation (SI)¶
| Req | Title | Disposition | Notes |
|---|---|---|---|
| SI-1 | Security implementation review | Met | SCA on all code and changes (golangci-lint in CI; Table 3 requires no independence for SCA), daily independent-of-author review with public dispositions (#483), traceability notes on security-relevant changes |
| SI-2 | Secure coding standards | Met | secure-coding-standard.md — gate-enforced core, banned constructs, boundary validation, error handling, periodic review rule |
Practice 5 -- Security verification and validation testing (SVV)¶
The structural gap. What exists today is the two Table-3 rows requiring no independence (static analysis, software composition analysis) plus non-independent functional tests of auth/validation code.
| Req | Title | Disposition | Notes |
|---|---|---|---|
| SVV-1 | Security requirements testing | Gap | No documented security-requirements test plan/execution; requires independent department (Table 3) → engagement |
| SVV-2 | Threat mitigation testing | Gap | No mitigation-thwarting test program; independent department → engagement |
| SVV-3 | Vulnerability testing | Partial | Met: software composition analysis (govulncheck, Trivy, SBOM — "None" independence) and CI known-vuln scanning tooling. Missing: abuse-case/fuzz testing of external interfaces, attack-surface analysis as a tested activity, and independent-person execution of the scanning rows → engagement + fuzz backlog |
| SVV-4 | Penetration testing | Gap | None performed; independent department or organization → engagement |
| SVV-5 | Independence of testers | Gap (plan documented) | See V&V and independence plan — the documented plan below becomes the process once the engagement executes it |
Practice 6 -- Management of security-related issues (DM)¶
| Req | Title | Disposition | Notes |
|---|---|---|---|
| DM-1 | Receiving notifications | Met | GitHub Security Advisories + tracked internal/supplier channels (defect-management.md) |
| DM-2 | Reviewing issues | Met | 72 h acknowledgment, applicability/verifiability/threat triage — documented and consistent with practiced issue handling |
| DM-3 | Assessing issues | Partial | CVSS + context adjustment + root-cause procedure documented; not yet exercised on a live security report |
| DM-4 | Addressing issues | Partial | Residual-risk threshold now defined (context-adjusted CVSS < 4.0 + layer containment + recorded rationale); disposition options and release-cycle review documented; first practiced record pending |
| DM-5 | Disclosing issues | Met | Advisory-based disclosure with required content documented (none yet required in the field) |
| DM-6 | Periodic review | Planned | First annual review scheduled as the ML3 evidence starting point |
Practice 7 -- Security update management (SUM)¶
| Req | Title | Disposition | Notes |
|---|---|---|---|
| SUM-1 | Update qualification | Met | Fix verification + full make verify + rescan, identical for own fixes and dependency bumps (update-management.md) |
| SUM-2 | Update documentation | Partial | Required release-note content now specified; template first applies to the next security release |
| SUM-3 | Dependent component/OS updates | Partial | Kubernetes compatibility statements exist; the policy for unapproved-platform-update mitigations is newly documented |
| SUM-4 | Update delivery | Met | Signed images + OCI chart with verifiable authenticity (cosign) — strong |
| SUM-5 | Timely delivery policy | Met | Severity-tiered targets documented, consistent with SECURITY.md |
Practice 8 -- Security guidelines (SG)¶
| Req | Title | Disposition | Notes |
|---|---|---|---|
| SG-1 | Product defense in depth | Met | Threat model + IDS narrative + secure-design layers |
| SG-2 | Environment defense-in-depth expectations | Met | CCSC 2 delegation register + SL-3 operator checklist state exactly what the environment must provide |
| SG-3 | Security hardening guidelines | Met | Security Hardening — configuration, defaults, rationale |
| SG-4 | Secure disposal guidelines | Gap | No disposal/decommissioning user guide → #977 (same deliverable as CR/SR 4.2) |
| SG-5 | Secure operation guidelines | Met | Security Operations |
| SG-6 | Account management guidelines | Met | Role model + custom-roles doc; no default passwords exist (per-role MQTT credentials are deployment-generated; documented) |
| SG-7 | Documentation review | Met | Docs are lint-gated (make check-docs, style/contract gates), drift-checked against code, and errors are tracked to closure as issues |
V&V and independence plan¶
Verified against Table 3 (SVV-5), the required independence per test type, with two corrections to earlier internal reads. Penetration testing requires an independent department or organization (a separate legal entity is sufficient but not necessary), and the "independent department" rows can alternatively be satisfied by QA- department membership. For a solo-founder organization, no internal person can satisfy any independence row. AI engineering agents are developer tooling with no standing as persons or departments, and they cannot satisfy independence. SM-5 scoping cannot waive this.
The plan: one contracted external security firm covers every independence row in a single recurring engagement.
| Engagement item | Covers | Table 3 row satisfied |
|---|---|---|
| Security-requirements test plan + execution against the 3-3/4-2 matrices (functional, error/invalid-input handling, boundary/stress) | SVV-1 | Independent department |
| Threat-mitigation test plan from the threat model: verify each mitigation works, then attempt to thwart each | SVV-2 | Independent department |
| Abuse-case/fuzz testing of external interfaces (gateway REST/auth, MQTT ingest, OPC UA client paths, historian ingest), attack-surface analysis, authenticated + unauthenticated vulnerability scans of the reference deployment | SVV-3 a/b/c | Independent person |
| Penetration test of the reference deployment (product in its documented security context) | SVV-4 | Independent department or organization |
| Review seats: SR-5 requirements review (tester + security advisor disciplines) and SD-3 design reviews for security-relevant revisions | SR-5, SD-3, SM-4 | — |
| Findings delivered as DM-1 intake, scored per DM-3, tracked to closure; re-test of fixes | DM practice exercise | — |
Cadence: initial engagement, re-test after material interface/trust- boundary changes, annual re-validation aligned with the DM-6 and SR-2 reviews. What we keep in-house (no independence required): static analysis, software composition analysis, and building the fuzz harnesses the engagement then runs or reviews independently.
Maturity¶
Against Table 1, the ML 1 → ML 2 transition is completed by this baseline for SM, SR, SD, SI, DM, SUM, SG. Written policies now exist and match what is actually practiced, and the Partial rows above mark where practiced evidence is still thin. SVV sits at ML 1 until the external engagement runs. ML 3 (Defined/Practiced) requires the processes practiced for at least one product cycle with records. The backlog below is sequenced to produce exactly those records.
Prioritized backlog to ML 2/ML 3¶
- Contract the external security engagement — the only structural blocker. It unblocks all of SVV plus the SR-5/SD-3 independent seats.
- #977: SG-4 disposal guidelines (also closes CR/SR 4.2).
- Practice the release gate on the next release: SM-11/SM-12 checklist execution with retained records.
- First recorded annual reviews: SR-2 threat-model review and DM-6
process review (
sdl-dm6record). - Fuzz harnesses for gateway DTO validation and historian MQTT ingest (SVV-3a substrate for the engagement to execute independently).
- Security release-note template applied on the next security release (SUM-2 record).
Related corrections¶
The former "IEC 62443-4-1" table in the main traceability doc used an invented "SD 1–SD 7" numbering that does not exist in the standard (the real structure is 8 practices, SM/SR/SD/SI/ SVV/DM/SUM/SG). It has been replaced by a pointer to this assessment.