Security Update Management¶
The security-update-management practice (62443-4-1 Practice 7, SUM-1…SUM-5) for Cloud-Native DCS.
Qualification (SUM-1)¶
A security update ships only after: the fix is verified against the
vulnerability it addresses (regression test or reproduction check on the
tracking issue), the full make verify gate suite passes (regression
protection), and the release images are rescanned (Trivy). This applies
identically to fixes we author, dependency bumps (Dependabot PRs run the
same CI), and platform-driven rebuilds (base-image refresh). Updates
must not contradict operational or safety constraints. A security fix
that touches the control path (unit-runtime, fail-state behavior) also
runs the integration suite and is flagged in the release notes for
site change-management.
Update documentation (SUM-2)¶
Each security release publishes, in the release notes: affected/fixed
version numbers, how to apply the update (Helm upgrade command and the
GitOps pin-bump path), operational impact (component restarts and
expected control-plane behavior during rollout, with edge autonomy
covering control continuity per ADR 0006), how to verify the update (image digest +
cosign verification + dcs version), and the risk of not applying with
available mitigations.
Dependency and platform updates (SUM-3)¶
For security updates to dependencies or the platform that we do not ship: compatibility statements go in the release notes / compatibility table (supported Kubernetes versions), and where we cannot yet approve a platform update, the notes state interim mitigations. Go-module security updates are folded into product releases (the product statically links its dependencies, so no separately-patchable dependency exists at a customer site).
Delivery and authenticity (SUM-4)¶
Updates are delivered as versioned container images on GHCR and the OCI
Helm chart, each cosign-signed (keyless) with SBOM attached. A user can
therefore verify authenticity of every artifact before rollout
(cosign verify ... documented in the security hardening guide).
GitOps-managed sites consume updates as reviewable pin bumps.
Timeliness policy (SUM-5)¶
Target timeframes from triage (DM-3 scoring) to available update, per context-adjusted severity:
| Severity (CVSS, context-adjusted) | Target |
|---|---|
| Critical (9.0+), or actively exploited / public exploit | Fix or effective mitigation published ≤ 7 days; update ≤ 30 days |
| High (7.0–8.9) | Update ≤ 30 days |
| Medium (4.0–6.9) | Update ≤ 90 days (matches the SECURITY.md patch target) |
| Low (< 4.0) | Next scheduled release, or DM-4 residual-risk closure |
The factors the clause names (impact, public knowledge, exploit availability, deployment volume, mitigation availability) can move an issue up a tier. Downward movement is capped at one tier. Meeting these targets is checked in the DM-6 periodic review.