Vulnerability Management Standard¶
| ID | STD-07 · Status: Template. Adapt it and have it approved in your organization (SLAs and risk model). |
| Owner | AppSec lead |
| Configuration | config/risk-model.yaml, Risk model |
| Related | ADR-011, ADR-012, ADR-018 |
1. Scope¶
All security findings for registered applications: code (SAST), dependencies (SCA), secrets, IaC, containers, DAST/API, cloud posture, malicious packages, licences, pen-test and architecture-review findings, and control gaps.
2. Lifecycle¶
Detection → Normalisation → Deduplication → Asset mapping → Risk calculation → Ticket
→ Assignment → Remediation → Verification (re-scan) → Closure
| Stage | Requirement | Owner | Proven by |
|---|---|---|---|
| Detection | Findings come from approved scanners/pipelines, GHAS, Dependency-Track, cloud posture tools and manual assessments | Platform | Evidence + connectors |
| Normalisation | Scanner output is normalised (DefectDojo parsers or the platform) into the finding model | Platform | — |
| Deduplication | One finding per real issue, by deterministic fingerprint (data model section 4) | Platform | PS-6 test |
| Asset mapping | Every finding maps to an application and owner. Unmapped findings go to a triage queue. | Platform / AppSec | ASC-VUL-01 |
| Risk calculation | Priority P1–P4 from the contextual risk model. Never CVSS alone. | Platform | Risk assessment record |
| Ticket | P1–P3 tickets created automatically (grouped by fix unit). P4 optionally batched. | Platform | ADR-018 |
| Assignment | To the technical owner / champion of the owning team | Team | — |
| Remediation | Within SLA (below) | Team | ASC-VUL-02 |
| Verification | Re-scan of the same scope no longer reports the finding | Platform | closure_evidence_id |
| Closure | Only on verification evidence. Ticket closure alone never closes a finding. | Platform | DB constraint (test T4) |
3. SLAs (defaults)¶
| Priority | Triage | Remediate (verified) |
|---|---|---|
| P1 | 1 day | 7 days |
| P2 | 3 days | 30 days |
| P3 | 10 days | 90 days |
| P4 | 30 days | 180 days |
Overrides that force P1: CISA KEV-listed on an internet-facing app · active exposed secret · malicious package.
4. Requirements¶
| ID | Requirement | Proven by |
|---|---|---|
| VMS-01 | Findings shall be triaged within the triage SLA (ticketed, false positive, or excepted) | ASC-VUL-01 |
| VMS-02 | P1/P2 false positives require confirmation by a second reviewer (AppSec), not the marker | Workflow SoD |
| VMS-03 | Findings shall be remediated within SLA or covered by an approved exception before the due date | ASC-VUL-02, ASC-VUL-03 |
| VMS-04 | Tool-level suppressions (risk accepted, dismissed, skip comments) do not count as risk acceptance | Unmanaged-suppression tracking |
| VMS-05 | Active secrets: revoke/rotate first, then remove from code. Never close as "false positive" without verification. | ASC-SRC-04 (no exceptions) |
| VMS-06 | Malicious packages: treat as a security incident (SOC event, runner/secret compromise assessment) | ASC-BLD-09, SIEM event |
| VMS-07 | Recurring weakness classes shall be analysed quarterly (Tier 1) | ASC-VUL-04 |
| VMS-08 | Priority overrides require justification and a second approver. They are audited. | Override workflow |
5. Escalation¶
Per governance model section 5.
6. Vulnerability disclosure¶
External reports are received via SECURITY.md / private vulnerability reporting (ASC-GOV-05), recorded as findings with source_system=manual, and handled under this standard. Coordinated disclosure timelines are agreed with the reporter.