Security Defect Management

The management-of-security-related-issues practice (62443-4-1 Practice 6, DM-1…DM-6) for Cloud-Native DCS. SECURITY.md is the public-facing summary. This document is the internal procedure.

Intake (DM-1)

Security-related issues are received and tracked to closure from every source the practice names:

Source	Channel
External reporters / researchers	GitHub Security Advisories (private), per SECURITY.md — never public issues
Third-party component suppliers	Dependabot alerts, govulncheck findings, Trivy scan results
Internal development and testing	GitHub issues labeled area: security; review-digest findings (#483)
Product users (integrators, asset owners, maintenance)	Security Advisories or the support channel, triaged into the same tracker
Independent V&V engagement	Engagement report items, filed as tracked issues on receipt

Every intake lands as a tracked item with a unique ID (advisory or issue number). Nothing is handled out-of-band.

Review and triage (DM-2)

Within the SECURITY.md acknowledgment window (72 h) each report is assessed for: applicability to the product (affected versions), verifiability (reproduction or refutation, with a refuted report closed and the evidence recorded), and the threats that trigger it (mapped to the threat model, where a threat the model lacks triggers a threat-model update per SR-2).

Assessment (DM-3)

Verified issues are scored and analyzed:

• Severity: CVSS v3.1 base score, adjusted by the product security context (an issue reachable only from the control zone scores the attack vector accordingly).
• Impact analysis against the discovered context, the documented security context, and the defense-in-depth layers (which layers contain it, and whether any single-layer failure exposes it).
• Version sweep: all supported versions checked (currently the single supported line per SECURITY.md).
• Root cause, recorded on the tracking issue and evaluated for a preventing gate (SM-13).

Disposition and residual-risk threshold (DM-4)

Acceptable residual risk: an issue may be closed without a fix only if its context-adjusted CVSS is below 4.0 (Low) AND it is contained by at least one independent defense-in-depth layer AND the disposition is recorded with rationale. Everything at or above 4.0 gets one of: fix (design change, added capability, compensating mechanism, or feature removal), a remediation plan with a target release, or a documented deferral with reason and risk, reviewed each release cycle until closed. When a fix lands, sibling products/versions and any third-party component supplier are informed as applicable, and the prevent-recurrence question (new gate? new test?) is answered on the issue before closure.

Disclosure (DM-5)

Reportable issues (per the DM-4 disposition) are disclosed via a GitHub Security Advisory containing: description, CVSS score, affected versions, and the resolution (patched version or mitigation), following the SECURITY.md timeline (patch target ≤ 90 days). For third-party-component vulnerabilities we track the upstream disclosure and do not front-run it, while preparing the dependency bump per update management.

Periodic review (DM-6)

At least annually, folded into the release retrospective, the issues handled since the last review are examined for completeness of the process (was every intake tracked to closure? were dispositions recorded? did fixes generate prevention gates?). The review record is a review-digest-style issue tagged sdl-dm6. Its first instance is the ML3 evidence starting point.