Secure Development Lifecycle Process

The security-management practice (62443-4-1 Practice 1, SM-1…SM-13) for Cloud-Native DCS. This document is the written process. The practice-by- practice conformance assessment lives in IEC 62443-4-1 Assessment.

Development process (SM-1)

Product development runs through a single, enforced pipeline:

• Configuration management with change control and audit logging: all product source, manifests, Helm chart, and documentation live in one git repository. Every change is a commit on main with author attribution. Generated artifacts (config/crd/bases/, RBAC) are never hand-edited. They are regenerated, and CI fails on drift (make verify parity, enforced by lint-ci-parity).
• Requirements definition with traceability: product security requirements are the clause-verified 62443 matrices (see Security Requirements Specification). Functional requirements trace through GitHub issues. Every non-trivial change references its issue.
• Design and implementation practices: Kubebuilder controller pattern, modular per-binary operators, design decisions recorded as ADRs (docs/adr/) with status lifecycle.
• Repeatable V&V: make verify runs the full gate suite (unit, integration, lint families, Helm verification, docs contracts) locally and in CI identically. UI behavior runs via Playwright (make test-ui).
• Review and approval of records: pre-commit hooks enforce the gate suite. The standing independent review agent audits each day's main commits and records findings as review-digest issues (#483). Zero-finding digests are filed as evidence the review ran.
• Life-cycle support: versioned releases (signed images, OCI chart), documented upgrade path, defect management and update management processes.

Roles and responsibilities (SM-2)

62443-4-1 permits responsibilities to be assigned to personnel external to the organization. The current assignment:

Role	Held by	Responsibilities
Product owner / release authority	Founder	Approves releases, accepts residual risk (DM-4 threshold), owns process scoping decisions (SM-5)
Engineering (design, implementation, inline testing)	Founder + AI engineering agents under founder direction	All Practice 3/4 activities; SCA and software-composition analysis (no independence required per Table 3)
Independent daily code review	Standing review agent (#483), records public	SI-1 support: convention/security audit of each day's commits with dispositions
Security advisor seat (SR-5, SD-3 reviews)	External security firm (engagement planned — see the V&V and independence plan)	Requirements review, design review participation
Independent V&V (SVV-1/2/4 rows of Table 3)	Same external engagement	Security-requirements testing, threat-mitigation testing, penetration testing
Vulnerability intake and disclosure	Founder (via GitHub Security Advisories, SECURITY.md)	DM-1/DM-5

AI engineering agents act under founder direction and review. For Table 3 purposes they are tooling within the developer role, and independence rows are satisfied only by the external engagement.

Applicability and scoping (SM-3, SM-5)

This standard applies to the entire product: every shipped binary and the Helm chart (all classified as software applications, per the 4-2 component assessment). Scoping decisions that exclude a 4-1 requirement require a documented security analysis approved by the security-expertise role. Current scoping exclusions and their justifications are listed in the 4-1 assessment. Hardware-specific requirements (debug headers, JTAG) are excluded by the documented analysis that the product contains no supplier-manufactured hardware.

Security expertise (SM-4)

Personnel (and agents) assigned to security-relevant roles work against the purchased 62443 standards and the documented practice files in this directory. The external security firm provides the demonstrated independent security expertise for review and V&V seats. Training records for the ML3 evidence trail start with the engagement.

File integrity (SM-6)

Every released artifact carries an integrity mechanism: SHA-256 checksums for binaries, cosign keyless signatures for container images, SBOM attached per image, and the Helm chart delivered via OCI digest pinning.

Development environment security (SM-7)

• Source of truth is the GitHub repository with branch-protection on release tags. Write access is limited to the founder.
• CI runs on GitHub-hosted runners from pinned action SHAs (third-party actions are commit-pinned in .github/workflows/).
• Build provenance: images are built in CI and signed keylessly (Sigstore Fulcio OIDC identity bound to the workflow), so a compromised laptop cannot forge a release signature.
• AI-agent development workflow: agents operate in sandboxed sessions with permission-gated tool use. Every agent change lands as an attributed git commit subject to the same lint/test gates and the independent daily review (#483). Credentials available to agent sessions follow the operations credential conventions (dedicated per-purpose tokens, mode-0600 on-disk caches).

Controls for private keys (SM-8)

Code signing uses keyless Sigstore signing: there is no long-lived private signing key to protect. Signatures bind to the CI workflow's short-lived OIDC identity, which exceeds the requirement's intent. The remaining private keys (cert-manager CA, gateway HMAC keys) are runtime deployment secrets outside the development process, managed per the rotation runbook.

Externally provided components (SM-9, SM-10)

• Go module dependencies are integrity-pinned (go.sum), updated via Dependabot on a weekly cadence with grouped PRs, and scanned by govulncheck (CI) and Trivy (release images).
• The dependency set is intentionally small and auditable. SBOMs make the composition inspectable per release.
• No custom-developed third-party components exist (SM-10 currently has no in-scope suppliers). If one is engaged, its SDL conformance becomes part of the intake requirements in this section.

Release gate (SM-11, SM-12)

A release requires: green make verify parity in CI, zero open security-related issues tagged for the release (tracked to closure per defect management), a clean Trivy scan of the release images, and the release checklist recording completion of each applicable process. The checklist record is the SM-12 evidence artifact and is retained with the release.

Three of those requirements are enforced by the release workflow itself rather than by the checklist:

• Green CI parity. Every job in the release workflow depends on a gate job that requires a successful CI run for the exact tagged commit. A tag push does not trigger CI, so without this the tag was the only gate and a release could be cut against a tree with failing lint and tests. Releases v0.2.1 through v0.2.3 were cut exactly that way. The gate waits out a CI run still in flight and blocks on a red, cancelled, or absent one. A commit CI skipped (it ignores docs-only paths) is resolved by running CI against the tag (gh workflow run ci.yml --ref <tag>) and re-running the gate job. Re-tagging is never the fix.
• Clean image scan. The scan runs on the built image before it is pushed, so a CRITICAL or HIGH finding blocks publication outright. Scanning after the push made the gate advisory in practice.
• Chart image resolution. Before the chart is pushed, every image it resolves (each published component at the release version, and every reference the packaged chart renders) must already exist in the registry. Chart 0.2.0 published resolving a gateway tag that an earlier image rename meant nothing had ever pushed, and every chart from 0.1.4 to 0.2.0 was uninstallable the same way. A rename breaks already-published charts while leaving future ones fine, so the release proves resolution of the exact artifact it is about to publish.

All three properties are lint-enforced (make lint-ci-release-gate), so the workflow cannot drift back to asserting them without enforcing them.

Continuous improvement (SM-13)

Security defects that escape to the field are analyzed for root cause (DM-3) and the lesson is fed back as either a lint gate (the preferred and enforced form, exemplified by the make lint-* families born from field issues), a test, or a practice-doc update. The annual DM-6 review doubles as the SDL improvement review.