Secure Development Lifecycle Audit File¶
The development lifecycle for Cloud-Native DCS, assembled as one file and mapped to the eight practice areas of IEC 62443-4-1. It is written for two readers. The first is the quality unit of a regulated customer running a supplier assessment under GAMP 5 and EU Annex 11 clause 3. The second is a certification assessor evaluating the development organization against IEC 62443-4-1, which is the ISASecure SDLA scheme.
Both readers ask the same question in different vocabulary. GAMP 5 asks whether the supplier has a quality system and a documented development lifecycle, and whether the supplier can show that it followed them. The 62443-4-1 assessor asks the same about eight named practices and 47 numbered requirements. This file answers once, in the 62443-4-1 structure, and carries a crosswalk to the supplier-questionnaire form of the question at the end.
Document control¶
| Field | Value |
|---|---|
| Supplier | Cloud-Native DCS |
| Product | Cloud-Native DCS, an ISA-88 batch control system for Kubernetes |
| Product scope | Every shipped binary and the Helm chart, all classified as software applications under IEC 62443-4-2 clause 3.1.42 |
| Release line covered | v0.7.x, the currently supported line per SECURITY.md. This row reads from that statement, and make lint-supported-versions holds the two equal |
| Normative basis | ANSI/ISA-62443-4-1-2018, purchased text, 8 practices and 47 requirements |
| Clause verification | 2026-07-18, against the purchased standard, #970 under epic #967 |
| Evidence current as of | 2026-08-31 |
| Maturity position | ML 2 on seven practices, ML 1 on SVV. See Maturity position |
| Internal counterpart | IEC 62443-4-1 Assessment, which carries the internal backlog and is held identical to this file on every disposition by make lint-sdl-audit-parity |
What this file claims, and what it does not¶
The claim is a documented and practiced secure development lifecycle aligned to the practices of IEC 62443-4-1. Every disposition below is a self-assessment against the purchased standard text.
Four things are not claimed anywhere in this file, and a reader who finds language that appears to claim them has found a defect worth reporting.
- No certification. No ISASecure SDLA certificate, no TÜV or exida assessment, and no third-party conformance mark of any kind has been issued for this lifecycle. No certification body has reviewed it.
- No conformance statement. "Conformant to 62443-4-1" and "meets 62443-4-1" are claims about an assessed process. The defensible wording is alignment to the practices, and the 4-1 assessment fixes that wording as an internal rule.
- No independent verification. The organization is a single founder working with AI engineering agents. No requirement of IEC 62443-4-1 Table 3 that demands an independent person, department, or organization is satisfied today. That position is stated in full under Independence position, and it is the largest open gap in this file.
- No component or system certificate. IEC 62443-4-2 (component) and IEC 62443-3-3 (system) capability levels are self-assessed in their own matrices and are outside the scope of this file.
What the file does claim is that the process below is written down, that it is the process actually used, and that a reader can inspect the evidence for themselves. Every row of every practice table names an artifact.
How to read the evidence¶
The Evidence column names something an auditor can be shown. Five classes appear, and each is inspectable without privileged access to a running system.
| Class | What it is | How an auditor inspects it |
|---|---|---|
| Repository | Source, manifests, chart, documentation, all in one git repository | Read the file at a named path, or read the commit history for it |
| Gate | A make target that fails the build on a rule violation, run identically in CI and in the pre-commit hook |
Read the target in Makefile and the script it calls, then run it |
| Workflow record | A GitHub Actions run, retained with its logs | Open the run for a named commit or tag |
| Release artifact | A signed container image, an SBOM, an OCI Helm chart | Verify the signature with cosign verify and read the attached SBOM |
| Issue record | A tracked GitHub issue or security advisory with a permanent number | Open the issue and read its dispositions |
Where a requirement is dispositioned Partial or Gap, the Evidence column says what exists and the Open gaps register says what is missing and what closes it.
Dispositions are Met, Partial, Gap, or N-A, judged against the requirement text of the purchased standard.
Organization and responsibilities¶
Cloud-Native DCS is developed by a single founder working with AI engineering agents under founder direction. IEC 62443-4-1 permits responsibilities to be assigned to personnel external to the organization, and the assignments below use that allowance for every role the founder cannot hold.
| Role | Held by | Responsibilities |
|---|---|---|
| Product owner and release authority | Founder | Approves releases, accepts residual risk against the DM-4 threshold, owns scoping decisions under SM-5 |
| Engineering: design, implementation, inline testing | Founder with AI engineering agents | All Practice 3 and Practice 4 activities, plus static analysis and software composition analysis, which Table 3 requires no independence for |
| Daily code review, independent of the change author | Standing review agent, records public as review-digest issues (#483) |
SI-1 support: a convention and security audit of each day's commits to main, with recorded dispositions. Independence here means separation from the author of the change, and it is not the organizational independence Table 3 demands |
| Security advisor seat for SR-5 and SD-3 reviews | External security firm, engagement planned | Requirements review and design review participation |
| Independent V&V for the SVV-1, SVV-2 and SVV-4 rows of Table 3 | The same external engagement | Security requirements testing, threat mitigation testing, penetration testing |
| Vulnerability intake and disclosure | Founder, through GitHub Security Advisories per SECURITY.md |
DM-1 and DM-5 |
The standing of AI engineering agents is stated here because an assessor will ask. They are developer tooling operating within the developer role. Their output lands as an attributed git commit subject to the same gates and the same daily review as any other change. They have no standing as persons or as a department, so they satisfy no independence row of Table 3. The SM-5 scoping allowance cannot be used to waive that.
Practice 1: Security management (SM-1 to SM-13)¶
Product development runs through a single enforced pipeline. All source,
manifests, the Helm chart, and the documentation live in one git repository.
Every change is an attributed commit on main that references its tracking
issue. Generated artifacts are never hand-edited, and CI fails on any drift
between a generated file and its generator. Design decisions that shape
architecture are recorded as Architecture Decision Records with a status
lifecycle. Verification is the single command make verify, which runs the
whole gate suite locally and in CI identically. A gate that runs in one place
and is absent from the other is itself a build failure. The written process is
docs/sdl/process.md.
| Req | Title | Disposition | Evidence an auditor can inspect |
|---|---|---|---|
| SM-1 | Development process | Met | The repository itself: one main line with attributed commits, docs/adr/ carrying 85 ADRs as of 2026-08-31, make verify as the single V&V entry point, and make lint-ci-parity, which fails when a gate in make verify runs in no workflow |
| SM-2 | Identification of responsibilities | Met | The RACI table under Organization and responsibilities, and § Roles and responsibilities of process.md. The vacant seats are assigned to the planned external engagement, which the standard permits |
| SM-3 | Identification of applicability | Met | Whole product in scope. The per-binary classification is the component classification of the 4-2 assessment |
| SM-4 | Security expertise | Partial | Security-relevant work is done against the purchased 62443 standards and the practice documents in docs/sdl/. Missing: demonstrated independent expertise, which arrives with the engagement, and training records |
| SM-5 | Process scoping | Met | One scoping exclusion exists. Hardware-specific requirements such as debug headers and JTAG are excluded by the documented analysis that the product contains no supplier-manufactured hardware. The exclusion is recorded in § Applicability and scoping of process.md |
| SM-6 | File integrity | Met | .github/workflows/release.yml: SHA-256 checksums on binaries, cosign keyless signatures on every image, an SBOM attached per image, and the Helm chart delivered by OCI digest. Verifiable on any published release with cosign verify |
| SM-7 | Development environment security | Met | Third-party GitHub Actions are commit-pinned in .github/workflows/. Write access is limited to the founder. Images are built in CI and signed against a Sigstore Fulcio OIDC identity bound to the workflow, so a compromised development machine cannot forge a release signature. The AI-agent workflow runs in sandboxed sessions with permission-gated tool use, and every agent change lands as a gated, reviewed commit |
| SM-8 | Controls for private keys | Met | Signing is keyless. No long-lived code-signing private key exists to protect, and signatures bind to a short-lived workflow identity. Runtime deployment secrets are covered by the rotation runbook and sit outside the development process |
| SM-9 | Externally provided components | Met | go.sum integrity pinning, .github/dependabot.yml on a weekly grouped cadence, govulncheck in .github/workflows/ci.yml, Trivy on release images, and a per-image SBOM that makes the composition inspectable |
| SM-10 | Custom-developed third-party components | N-A | No custom-developed third-party components exist. The intake rule for when one is engaged is written in § Externally provided components of process.md, so the requirement has a process waiting for its first subject |
| SM-11 | Assessing and addressing security issues prior to release | Partial | The release workflow blocks on three properties, each of them lint-enforced by make lint-ci-release-gate: a green CI run for the exact tagged commit, a clean Trivy scan run before the image is pushed, and resolution of every image the chart references. Those have gated every release since v0.4.x, and the workflow runs are the records. Missing: a per-release record enumerating the security issues considered and their dispositions |
| SM-12 | Process verification | Partial | The automated portion of the release process verifies itself on every release, and 37 releases from v0.1.5 to v0.6.3 carry workflow records. Missing: a retained checklist record covering the process steps the workflow does not automate |
| SM-13 | Continuous improvement | Met | The practiced loop is visible in the Makefile: 79 make lint-* gates as of 2026-08-31, a large share of them written in direct response to a specific field defect and carrying its issue number. A defect class that recurs becomes a gate, which is the improvement mechanism the requirement asks for |
Practice 2: Specification of security requirements (SR-1 to SR-5)¶
The product security requirements are not a separate prose document. They are the clause-verified IEC 62443-3-3 and 62443-4-2 matrices, maintained as living documents with a stated capability target. The security context the product assumes, the scope and boundaries, and the review discipline are in docs/sdl/security-requirements.md.
The product security context in one paragraph: the cluster runs in the plant's control zone at Purdue level 2 or 3 and is never directly exposed to the internet. The customer provides and hardens the Kubernetes platform. Human identity and credential policy live in the customer's IdP. Field devices are reached over a dedicated, physically segmented OT network. The process under control is high-availability, so no security mechanism may prevent an essential function.
| Req | Title | Disposition | Evidence an auditor can inspect |
|---|---|---|---|
| SR-1 | Product security context | Met | § Product security context of security-requirements.md, which states the deployment zone, the platform assumption, the identity assumption, field connectivity, the user population, and the availability constraint |
| SR-2 | Threat model | Partial | docs/threat-model.md: STRIDE per element, MITRE ATT&CK for ICS mapping, trust boundaries, data flows, and a disposition per threat. The annual review cadence is adopted and written down. Missing: the first recorded periodic review. The document's own revision note reads 2026-03-24 |
| SR-3 | Product security requirements | Met | The 62443-3-3 matrix at 51 rows and the 62443-4-2 matrix, both clause-verified against purchased text on 2026-07-18. Installation, operation, maintenance and decommissioning requirements are carried by Security Hardening, Security Operations, the rotation runbook, and Decommissioning and Data Purge |
| SR-4 | Security requirements content | Met | Scope and boundaries are the shipped component list in the component classification, plus the physical boundary described in the security context. The required capability level is stated as SL-C 2 per foundational requirement in both matrices |
| SR-5 | Security requirements review | Partial | The four review disciplines the clause names are assigned in § Requirements review of security-requirements.md. Two of the four seats, independent tester and security advisor, are vacant until the engagement. Reviews conducted without them are marked provisional in the record and are re-ratified during the engagement |
Practice 3: Secure by design (SD-1 to SD-4)¶
The design record is docs/sdl/secure-design.md. It carries two artifacts an assessor will ask for directly. The first is an interface catalog listing every product interface with its exposure, whether its use crosses a trust boundary, its users, the assets reachable through it, and its safeguards. Twelve interfaces are catalogued, from the gateway HTTPS surface to the browser-delivered UI JavaScript. The second is a defense-in-depth layer table assigning nine layers of control, each with the share of responsibility delegated to the customer's platform where one exists.
A design rule binds the catalog to the code. A new interface, or a change to the exposure, users, or reachable assets of an existing one, requires a row in the catalog, a threat-model delta, and an SD-3 design review before the change merges.
| Req | Title | Disposition | Evidence an auditor can inspect |
|---|---|---|---|
| SD-1 | Secure design principles | Met | The interface catalog, which carries every per-interface attribute the clause enumerates |
| SD-2 | Defense in depth design | Met | The defense-in-depth layer table, nine layers with the product's controls and the delegated share named per layer. The delegated shares are registered individually in the CCSC 2 delegation register |
| SD-3 | Security design review | Partial | ADRs record architecture-shaping reviews, and the standing daily review (#483) backstops smaller changes with 65 review-digest issues filed daily from 2026-06-11 to 2026-08-31. Missing: participation by an external security advisor |
| SD-4 | Secure design best practices | Met | § Secure design best practices of secure-design.md. Several of the listed practices are gate-enforced, including attack-surface reduction by make lint-cli-internal-excluded, which keeps the internal command surface out of release builds |
Practice 4: Secure implementation (SI-1, SI-2)¶
The secure coding standard is
docs/sdl/secure-coding-standard.md, and
its defining property is that a rule is enforced by a gate wherever a gate
can express it. The standard therefore has two halves. The enforced half is
a table of rules paired with the gate that fails the build on a violation,
and it is machine-checked on every commit. The practiced half is the rules a
reviewer applies where no gate exists, and a rule that moves from the second
half to the first does so by someone writing a make lint-* target for it.
Banned constructs are named explicitly. One is a raw fetch() against the
API from UI JavaScript, which would bypass the authenticated transport and
its anti-replay nonce. Another is string-concatenated SQL in the historian.
| Req | Title | Disposition | Evidence an auditor can inspect |
|---|---|---|---|
| SI-1 | Security implementation review | Met | Static code analysis runs on all Go code and every change through golangci-lint in CI and in the pre-commit hook, and Table 3 requires no independence for that row. The standing daily review agent audits each day's commits to main against this standard with public dispositions, giving 65 filed digests as of 2026-08-31. Security-relevant changes additionally carry an issue-level note tracing the implementation to the requirement it serves |
| SI-2 | Secure coding standards | Met | The secure coding standard: a gate-enforced rule table, a banned-construct list, trust-boundary input validation tied to the interface catalog, an error-handling rule that keeps internal state out of responses to external callers, and an annual review rule |
Practice 5: Security verification and validation testing (SVV-1 to SVV-5)¶
This is the weakest practice in the file, and the reason is structural. Two rows of Table 3 require no independence, and both are satisfied. Static code analysis and software composition analysis run on every commit and every release. Every other row requires an independent person, department, or organization, and a single-founder organization has no internal person who can satisfy any of them. The closure path is one external engagement, costed and planned under Independence position.
An auditor should read the rest of this file with that gap in view. The design, the coding standard, and the gate suite are strong. The independent adversarial testing that would confirm they work has not been performed.
| Req | Title | Disposition | Evidence an auditor can inspect |
|---|---|---|---|
| SVV-1 | Security requirements testing | Gap | Functional tests of authentication, authorization and validation code exist in the repository and run in CI, and they are not an independent security-requirements test program. Table 3 requires an independent department for this row |
| SVV-2 | Threat mitigation testing | Gap | No program exists that attempts to thwart each mitigation named in the threat model. Table 3 requires an independent department |
| SVV-3 | Vulnerability testing | Partial | Satisfied: software composition analysis by govulncheck in CI and Trivy on release images, with per-image SBOMs, which Table 3 marks as requiring no independence. Missing: abuse-case and fuzz testing of the external interfaces, attack-surface analysis as a tested activity, and execution of the scanning rows by an independent person |
| SVV-4 | Penetration testing | Gap | None performed. Table 3 requires an independent department or an independent organization, and a separate legal entity satisfies this row |
| SVV-5 | Independence of testers | Gap, with a documented plan | The plan is Independence position below. It becomes practice when the engagement executes it |
Practice 6: Management of security-related issues (DM-1 to DM-6)¶
The internal procedure is
docs/sdl/defect-management.md, and
SECURITY.md in the repository root is its public face. Intake is tracked
from every source the practice names, and each intake lands as a tracked
item with a permanent identifier. Verified issues are scored with CVSS v3.1
adjusted for the product security context, so an issue reachable only from
inside the control zone scores its attack vector accordingly.
The residual-risk threshold is written down as a number. An issue may close without a fix only when its context-adjusted score is below 4.0, it is contained by at least one independent defense-in-depth layer, and the disposition is recorded with its rationale. Everything at or above 4.0 gets a fix, a remediation plan with a target release, or a documented deferral reviewed each release cycle until it closes.
| Req | Title | Disposition | Evidence an auditor can inspect |
|---|---|---|---|
| DM-1 | Receiving notifications of security-related issues | Met | The intake table in defect-management.md covers external reporters through GitHub Security Advisories, third-party suppliers through Dependabot and scanner findings, internal development through labelled issues and review digests, product users, and the future V&V engagement. SECURITY.md publishes the external channel |
| DM-2 | Reviewing security-related issues | Met | A 72-hour acknowledgment window is published in SECURITY.md, and the triage covers applicability by affected version, verifiability with a refuted report closed on recorded evidence, and the threats that trigger the issue. The practiced form is visible in the issue tracker under the area: security label |
| DM-3 | Assessing security-related issues | Partial | The procedure specifies CVSS v3.1 with context adjustment, impact analysis against the defense-in-depth layers, a version sweep, and a recorded root cause. Missing: exercise on a live external security report, because none has been received |
| DM-4 | Addressing security-related issues | Partial | The residual-risk threshold, the disposition options, and the release-cycle review are documented. Internally-found security defects are practiced through this path, and closed issues such as #971 through #974 show the fix-and-close shape. Missing: a record produced by the full procedure on an externally reported issue |
| DM-5 | Disclosing security-related issues | Met | The advisory mechanism and its required content are specified: description, CVSS score, affected versions, and resolution, on the SECURITY.md timeline with a patch target of 90 days. No advisory has been required in the field to date, and the absence of advisories is therefore consistent with the record |
| DM-6 | Periodic review of the practice | Planned | The annual review is defined, folded into the release retrospective, and its record form is specified as an issue tagged sdl-dm6. Missing: the first instance, which is the starting point of the ML 3 evidence trail |
Practice 7: Security update management (SUM-1 to SUM-5)¶
The written process is docs/sdl/update-management.md. One property of the product shapes this whole practice and an assessor should know it early. The binaries statically link their dependencies, so no separately patchable dependency exists at a customer site. A dependency security update reaches a customer as a product release, and the qualification path for a dependency bump is therefore identical to the path for a fix we author.
| Req | Title | Disposition | Evidence an auditor can inspect |
|---|---|---|---|
| SUM-1 | Security update qualification | Met | A security update ships only after the fix is verified against the vulnerability on its tracking issue, the full make verify suite passes, and the release images are rescanned. Dependabot pull requests run the same CI. A fix touching the control path also runs the integration suite and is flagged in the release notes for site change management |
| SUM-2 | Security update documentation | Partial | The required release-note content is specified: affected and fixed versions, how to apply the update, operational impact including component restarts and the edge-autonomy behaviour during rollout, how to verify the update by image digest and cosign, and the risk of not applying it. Missing: application of the template, which waits for the next security release |
| SUM-3 | Dependent component or operating system updates | Partial | Supported Kubernetes versions are published as a compatibility statement, and the policy for stating interim mitigations when a platform update cannot yet be approved is written down. The product line those updates are delivered to is stated once, in SECURITY.md, and held to the released chart by a gate. Missing: a practiced instance |
| SUM-4 | Security update delivery | Met | Every image on GHCR and the OCI Helm chart is cosign-signed keyless with an SBOM attached, so a customer can verify authenticity and integrity before rollout. The verification command is documented in Security Hardening. GitOps-managed sites consume updates as reviewable pin bumps |
| SUM-5 | Timely delivery of security patches | Met | Severity-tiered targets are published and consistent with SECURITY.md: a fix or effective mitigation within 7 days and an update within 30 days for Critical or actively exploited issues, 30 days for High, 90 days for Medium, and the next scheduled release for Low. The factors that move an issue up a tier are named, and downward movement is capped at one tier. Adherence is checked in the DM-6 review |
Practice 8: Security guidelines (SG-1 to SG-7)¶
This practice covers the security documentation shipped to the user, and it is the practice a GAMP 5 supplier audit reads most closely, because it is the part of the lifecycle the customer will operate against. Every requirement maps to a published document.
| Req | Title | Disposition | Evidence an auditor can inspect |
|---|---|---|---|
| SG-1 | Product defense in depth | Met | Threat model, the intrusion detection narrative, and the defense-in-depth layer table |
| SG-2 | Defense in depth measures expected in the environment | Met | The CCSC 2 delegation register enumerates every countermeasure delegated to the customer's platform, and the SL-3 operator checklist states what the environment must provide. Removing a delegated control without an equivalent voids the corresponding claim, and the register says so per row |
| SG-3 | Security hardening guidelines | Met | Security Hardening: configuration, shipped defaults, and the rationale for each |
| SG-4 | Secure disposal guidelines | Met | Decommissioning and Data Purge, delivered by #977 and closed 2026-07-18. It covers every data-bearing tier at release from service: edge host paths, historian and MQTT volumes, etcd-resident custom resources and Secrets, and archive buckets, with NIST SP 800-88 sanitization standards and a retention-first ordering that protects 21 CFR Part 11 records |
| SG-5 | Secure operation guidelines | Met | Security Operations |
| SG-6 | Account management guidelines | Met | The shipped role model with custom roles documented. No default password exists anywhere in the product, and the per-role MQTT credentials are generated at deployment time |
| SG-7 | Documentation review | Met | The documentation is gate-enforced. make check-docs fails a code change whose mapped documentation did not move, link and style gates hold the structure, and documentation errors are tracked to closure as issues like any other defect |
Independence position¶
IEC 62443-4-1 Table 3 sets the required independence per test type, and it is the single largest determinant of this file's maturity. Two readings of Table 3 are easy to get wrong, and both are stated correctly here. Penetration testing requires an independent department or an independent organization, so a separate legal entity is sufficient without being necessary. The rows calling for an independent department can alternatively be satisfied by membership of a quality-assurance department.
Neither correction helps a single-founder organization. No internal person satisfies any independence row, AI engineering agents hold no standing as persons or departments, and the SM-5 scoping allowance cannot waive an independence requirement.
The plan is one contracted external security firm covering every independence row in a single recurring engagement.
| Engagement item | Covers | Table 3 row satisfied |
|---|---|---|
| A security-requirements test plan executed against the 3-3 and 4-2 matrices, covering functional behaviour, error and invalid-input handling, and boundary and stress conditions | SVV-1 | Independent department |
| A threat-mitigation test plan derived from the threat model, verifying each mitigation and then attempting to thwart it | SVV-2 | Independent department |
| Abuse-case and fuzz testing of the external interfaces, being the gateway REST and auth surface, MQTT ingest, the OPC UA client paths, and historian ingest, with attack-surface analysis and authenticated and unauthenticated vulnerability scans of the reference deployment | SVV-3 a, b, c | Independent person |
| A penetration test of the reference deployment as the product sits in its documented security context | SVV-4 | Independent department or organization |
| Review seats: the SR-5 requirements review in the tester and security-advisor disciplines, and SD-3 design reviews for security-relevant revisions | SR-5, SD-3, SM-4 | Not an SVV row |
| Findings taken in as DM-1 intake, scored per DM-3, tracked to closure, with re-test of the fixes | Exercises the DM practice | Not an SVV row |
Cadence: an initial engagement, a re-test after any material change to an interface or a trust boundary, and annual re-validation aligned with the DM-6 and SR-2 reviews. Work retained in-house is the work Table 3 marks as requiring no independence. That is static analysis, software composition analysis, and building the fuzz harnesses the engagement then runs or reviews independently.
Maturity position¶
IEC 62443-4-1 Table 1 defines four maturity levels. ML 1 is Initial, where a practice is performed ad hoc. ML 2 is Managed, where the practice is written down and performed by trained personnel. ML 3 is Defined and Practiced, where the process is repeatable across the organization and has produced records over at least one product cycle. ML 4 is Improving, where metrics drive the improvement of the process itself.
| Practice | Level | Basis |
|---|---|---|
| SM: Security management | ML 2 | The written process matches the practiced pipeline, and the release gate is machine-enforced. Two rows carry thin evidence |
| SR: Specification of security requirements | ML 2 | The requirements exist as clause-verified matrices with a stated target. The first periodic threat-model review is outstanding |
| SD: Secure by design | ML 2 | The interface catalog and the layer table exist and bind to a merge rule. The external review seat is vacant |
| SI: Secure implementation | ML 2 | The coding standard is gate-enforced, and the daily review has produced an unbroken record since 2026-06-11 |
| SVV: Security verification and validation testing | ML 1 | Only the two no-independence rows of Table 3 are satisfied |
| DM: Management of security-related issues | ML 2 | The procedure is complete and internally practiced. It has not been exercised on an external report |
| SUM: Security update management | ML 2 | Qualification and delivery are Met. The documentation template awaits its first security release |
| SG: Security guidelines | ML 2 | Every requirement maps to a published, gate-checked document |
ML 3 requires the processes to have been practiced across at least one full product cycle with retained records. The Open gaps register below is sequenced to produce exactly those records. For an ISASecure SDLA assessment specifically, the scheme offers a provisional 12-month certificate for an organization without a completed product cycle, which is the path this maturity position fits.
Open gaps¶
Every disposition in this file that is not Met appears here with what is
missing and what closes it. Nothing is disclosed elsewhere in the file and
omitted from this register, and make lint-sdl-audit-parity fails when a
requirement drops out of the register while still carrying a verdict below
Met.
| # | Gap | Requirements affected | What closes it |
|---|---|---|---|
| 1 | No independent verification and validation of any kind | SVV-1, SVV-2, SVV-3, SVV-4, SVV-5, and the review seats in SR-5, SD-3, SM-4 | The external security engagement described under Independence position. This is the only structural blocker in the file, and it is the first item because it unblocks eight requirements |
| 2 | No retained per-release record of the security issues considered and the process steps followed | SM-11, SM-12 | Executing the release checklist on the next release and retaining the record with the release |
| 3 | The threat model has not had its first recorded annual review | SR-2 | A recorded review, written into the threat model's own revision note. The document currently reads 2026-03-24 |
| 4 | The DM practice has not been exercised on an externally reported issue | DM-3, DM-4 | The first external report, or the engagement findings of gap 1, which enter through the same DM-1 intake path |
| 5 | No first annual review of the defect-management practice | DM-6 | The first sdl-dm6 review record, which is the ML 3 evidence starting point |
| 6 | The security release-note template has not been applied | SUM-2 | The next security release |
| 7 | No practiced instance of the platform-update mitigation policy | SUM-3 | The first platform update that cannot be approved immediately |
| 8 | No training records, and no demonstrated independent security expertise | SM-4 | The engagement of gap 1 supplies the expertise. Training records begin with it |
| 9 | No fuzz harnesses for the highest-value input surfaces | SVV-3 a | Building harnesses for gateway DTO validation and historian MQTT ingest, which the engagement then runs or reviews independently |
Crosswalk to a GAMP 5 supplier assessment¶
A quality unit's supplier questionnaire asks about the same lifecycle in different words. This table routes each common question area to the practice that answers it, so a respondent can answer a questionnaire from this file without re-deriving anything.
| Questionnaire area | Answered by | Where |
|---|---|---|
| Quality system and development methodology | SM-1 | Practice 1 |
| Roles, responsibilities, and organizational independence | SM-2, SM-4, SVV-5 | Organization and responsibilities, Independence position |
| Requirements management and traceability | SR-1, SR-3, SR-4, SR-5 | Practice 2 |
| Design and design review | SD-1, SD-2, SD-3 | Practice 3 |
| Coding standards and code review | SI-1, SI-2 | Practice 4 |
| Testing, verification, and validation | SVV-1 to SVV-4 | Practice 5. The customer's own IQ/OQ/PQ is a separate matter, covered by GAMP 5 and Executable Validation Protocols |
| Configuration management and change control | SM-1, SM-6 | Practice 1, plus Change Control for the customer-facing workflow |
| Defect management and corrective action | DM-1 to DM-6 | Practice 6 |
| Patch, upgrade, and version support policy | SUM-1 to SUM-5 | Practice 7 |
| Third-party and open-source component control | SM-9, SM-10 | Practice 1. The per-image SBOM is the component inventory |
| Documentation supplied with the product | SG-1 to SG-7 | Practice 8 |
| Product security capability, as distinct from process | Out of scope here | The 62443-3-3 system matrix and the 62443-4-2 component matrix |
| Electronic records and signatures | Out of scope here | 21 CFR Part 11 |
| Data purge on decommissioning | SG-4 | Decommissioning and Data Purge |
Two areas a questionnaire commonly raises have no entry above because the honest answer is an absence. There is no ISO 9001 certificate, and the substitute offered is the demonstrable quality system in this file. There is no third-party security certification of any kind, and the position on that is stated under What this file claims, and what it does not.
Related Documentation¶
- IEC 62443-4-1 Assessment: the internal counterpart,
carrying the prioritized backlog and the internal wording rule. The two
files are held to identical dispositions by
make lint-sdl-audit-parity. - Compliance Traceability Index: every standard this product is assessed against.
- GAMP 5: the validation lifecycle mapping the customer's quality unit works from.
- Secure Development Lifecycle Process and the other
practice documents in
docs/sdl/: the full text this file condenses.