Vulnerability Management Standards

Vulnerability management standards

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

Applies when designing or operating the lifecycle of known third-party vulnerabilities: asset inventory, scan coverage and execution, enrichment and identifiers, prioritisation based on real risk, SLAs and remediation windows, closure verification, compensating controls, exceptions and risk acceptance, EOL tracking and reporting. Triggers: "CVE", "CVSS", "EPSS", "KEV", "scanner result", "Nessus/Qualys/Tenable/OpenVAS", "Trivy/Grype/OSV-Scanner output", "false positive", "VEX", "patching SLA", "maintenance window", "risk exception", "end of support", "vulnerability report".

Guiding principle: severity is not risk. A CVSS 9.8 with no known exploitation on an internal service that is switched off matters less than a 6.5 actively exploited at the edge. Prioritisation goes by the intersection of real exploitability × exposure × asset criticality (§3), and for that the inventory is a hard prerequisite, not a later phase: what is not inventoried is not scanned, and what is not scanned does not exist until somebody else finds it.

Not applicable: see appsec-standards (for vulnerability classes in your own code, threat modelling and SAST/DAST selection), cicd-standards (for scanning, SBOM and signing gates inside the pipeline), onprem-standards (for executing patching and maintenance windows on servers), linux-hardening-standards (CIS baseline, auditd, OpenSCAP), kubernetes-standards (for image scanning, admission and deployment policy), iac-standards and the cloud skills — aws-standards, azure-standards, gcp-standards — (for managed findings services: Security Hub, Defender for Cloud, Security Command Center), cloud-security-posture-standards (excessive permission does not enter this funnel because it has no CVE: multi-account posture, effective permission and cloud attack path are theirs; here only the CVE with its triage and its SLA), offensive-security-standards (the authorised exercise that produces findings: scope, RoE, execution and report — here their triage, prioritisation and remediation SLA once delivered), sre-practice-standards (for incident management once the vulnerability has already been exploited), data-platform-standards (for patching and EOL of data engines), grc-compliance-standards (the formal acceptance of risk, the regulatory framework and the audit evidence — here only the operational workflow that feeds it), opensource-licensing-standards (fine and reciprocal boundary, mirrored from its §1: the same SBOM serves both and that is why they get confused. It is generated once and consumed twice: for CVEs —triage, EPSS/KEV, VEX, patching SLA— it belongs here; for licence obligations —what can be combined, what forces publication, what must be attributed— it is theirs. Rule: if the question is "can this compromise me?", it is ours; if it is "does this oblige me to something?", it is theirs. Operational corollary: a dependency's EOL belongs here, but its relicensing is theirs — and both produce the same work, replacing it).

2. Default decisions

Verify the latest version on the web before pinning it in a real project (§8). The data below is from August 2026 and expires fast: this domain moves in months.

3. Lifecycle and prioritisation

The six phases (none is optional)

1. Inventory → 2. Discovery → 3. Enrichment → 4. Prioritisation → 5. Remediation → 6. Verification and reporting. The programme is worth whatever its weakest phase is worth, and that is almost always 1 or 6.

Phase 1 — Inventory: the hard prerequisite

• Without an inventory there is no measurable coverage, only the illusion of being covered. Every asset (host, VM, container, function, network device, repository, SaaS application) with: technical and business owner, environment, exposure (internet / internal network / isolated), criticality (explicit tiering), and classification of the data it handles.
• Automatic and reconciled sources, never a hand-maintained spreadsheet: IaC/CMDB, cloud APIs, active network discovery, image registry, service catalogue. Reconcile periodically and treat the discrepancy as a finding: an unknown asset is a control failure, not a curiosity.
• Criticality and exposure are attributes of the asset, not of the CVE: they are half of the prioritisation equation and without them SSVC cannot be applied.

Phase 2 — Scan coverage by layer

Scanning the image in the registry does not cover the container that has been running that image for 200 days: the inventory of what is deployed and the inventory of what is stored are different and both get scanned.

Authenticated vs unauthenticated: authenticated (credentials or agent) is the source of truth for patch state; unauthenticated serves to validate the external view and detect what the inventory does not know about. Use both, for different things — and a large delta between them is a sign of a coverage problem.

Phase 4 — Prioritisation based on real risk

The input is not the scanner's severity. These are combined, in this order of weight:

1. Observed exploitation? Presence in KEV (or equivalent vendor intelligence). It is the strongest signal and it collapses the deadline.
2. Probability of exploitation? EPSS. Anchor the policy to the probability if you want a stable threshold, or to the percentile if you want a queue of predictable size (the percentile drifts as the catalogue grows and as the model is recalibrated). Always communicate both: "15.3 % (p92)". The 0.10 threshold is folklore: it has no authority from FIRST; the right one depends on your remediation capacity.
3. Is it exposed? Reachable from the internet, from an untrusted network or only from an isolated segment.
4. Which asset is it? Criticality tier and data classification.
5. Is it automatable and what technical impact does it have? An exploitation chain automatable end to end; total or partial control.
6. Is it reachable? In dependencies, if the vulnerable function is never invoked, it drops in priority — but document the analysis with VEX, do not decide it verbally. Careful: the leading OSS scanners do not perform function-level reachability analysis.

Reference model (BOD 26-04): four binary variables per vulnerability-asset pair — publicly exposed, known exploitation (KEV), automatable, technical impact — which map to a deadline ranging from 3 days with mandatory forensic triage (all four affirmative) down to "fix at the next system update". The deadlines are dynamic: taking the system off the internet or the CVE's entry into KEV recalculate the date. It is the model that replaces BOD 22-01's flat 14-day deadline, and the best documented starting point for a policy of your own.

Expected effect: using real exploitation to reorder turns "1,000 criticals" into dozens of real urgencies. If your critical queue does not shrink by an order of magnitude when you apply KEV and EPSS, you are not prioritising: you are renaming.

Remediation SLAs

There is no universal standard; it has to be written down, measured and achievable. A defensible starting point across two dimensions:

Rules that make the SLA enforceable:

• Define the clock in writing: which event starts it (detection, publication in KEV, ticket creation) and which stops it (remediation verified by rescan, not "ticket closed").
• The asset tier compresses the deadline: the same vulnerability may be 24 h in Tier 1 and 30 days in Tier 3.
• Set achievable targets: an SLA that is systematically breached is not a target, it is theatre. If the real figure is 245 days, the right question is which structural constraint causes it (e.g. a single quarterly window), not raising the demand on paper.
• Never issue an SLA for a patch that does not exist: that goes to compensating controls and an exception (§6).
• Check the applicable contractual and regulatory minimums before publishing the policy.

4. Data quality and verification

• Closure is verified, not declared: a rescan or version check that confirms the remediation. A ticket closed without evidence is hidden debt and falsifies every metric.
• False positives: they are investigated and documented with a reason (the vulnerable configuration does not apply, component not present, function not reachable, already mitigated). The result is encoded in VEX, which is reusable and auditable, not in a ticket comment. Consume your vendors' VEX so you do not triage what they have already declared non-exploitable.
• False negatives, the silent risk: they are detected by measuring coverage (assets scanned / inventoried), failed scan credentials, agents not reporting and deltas between authenticated and unauthenticated scanning. A scan that fails silently looks like a clean scan.
• Source quality: with the NVD enrichment gap, the quality of the CVSS and the CPE now depends on the CNA. Prefer the vendor advisory and OSV for dependencies; treat missing data as uncertainty to be resolved, not as absence of risk.
• Deduplicate by vulnerability, not by finding: the same CVE on 400 hosts is one remediation job, not 400 triage decisions.
• Quality metrics for the programme itself: scan coverage, average age of scan data, FP rate per tool and reopen rate (things closed that reappear indicate unverified remediation or reintroduction through the base image).

5. Security of the programme itself

• Scan credentials: dedicated accounts, least privilege (read-only unless authenticated scanning demands more), rotated, in a secrets manager and with their use audited. They are privileged credentials over the whole estate: compromise them and you hand over the complete map.
• The scanner is attack surface. The Trivy supply chain compromise (March 2026: tag poisoning of trivy-action and setup-trivy, malicious binaries and images published) demonstrates the pattern: these tools run in CI with access to secrets by design. Pin actions by immutable SHA, images by digest, verify signature and checksum, and follow the advisories of the vendor of your own security tools as you follow those of the rest of the estate.
• The results are sensitive data: a vulnerability report is a prioritised attack plan. Classify it, restrict access on a need-to-know basis, do not paste it into open channels or public tickets and apply retention to it.
• Isolate intrusive scanning: tests that could degrade OT/ICS or fragile systems are agreed with the owner and executed in a window; in those environments, passive or inventory-based scanning.
• Inbound disclosure: a public security contact channel (security.txt, disclosure policy) and safe harbour for researchers. External findings enter through the same queue and with the same SLA, not through a parallel path.

6. Operation: windows, compensating controls, exceptions and EOL

• Patching windows: predictable, published cadence (ordinary monthly, weekly security) plus an out-of-window emergency procedure with an activation criterion (e.g. KEV + exposed) pre-agreed with the business. Negotiating the exception during the incident is too late. Execution, rollback and deployment order: onprem-standards and kubernetes-standards.
• Compensating controls when there is no patch or it cannot be applied: remove the exposure (the most effective mitigation, and it also recalculates the deadline), segment, virtual patching in WAF/IPS, disable the vulnerable feature or module, harden the configuration and raise monitoring with exploitation-specific detection. They are recorded as a temporary mitigation with an expiry date, not as closure.
• Exception workflow (an exception without the six pieces is not an exception, it is an ignored finding):
  1. Vulnerability, asset and technical justification for why it is not remediated within the deadline.
  2. Residual risk assessed with the same prioritisation model.
  3. Compensating controls implemented and verified.
  4. Expiry date — mandatory and finite; without an expiry it is not approved.
  5. Approver at a level appropriate to the risk: the risk owner is the business, never the security team, which advises. Formalisation and its documentary record belong to GRC.
  6. Scheduled review: it expires automatically and is re-evaluated; renewing requires new justification, not a rubber stamp.
• EOL tracking as part of the programme, not apart from it: an inventory with the end-of-support date per component (OS, runtime, framework, database, firmware, device), an alert with enough lead time to plan the migration (12 months for platform components) and budget allocated. An EOL component is a permanent vulnerability with no future patch: it is treated as accepted risk with an exit plan and a date, or it is migrated. Verify the dates in endoflife.date and in the vendor's official lifecycle, never from memory.
• Metrics and reporting (to steer, not to show off):
  • Operational: SLA compliance by severity and by tier, mean time to remediate, age of the open queue and its trend, backlog of open KEVs (the number you look at first), scan coverage, number and age of the exceptions in force, EOL assets in production.
  • To management: exposure and trend, not raw counts. "1,200 open vulnerabilities" is not information; "3 exposed KEVs out of SLA, with these owners and these dates" is.
  • Forbidden to use the vulnerability count as an individual yardstick over teams: it guarantees they stop reporting.
  • Be careful with time series when changing model: each EPSS version produces a scoring jump on its publication date (v4→v5 on 15 Jun 2026). It is a methodology change, not a change in risk — note it in the report before someone asks.

7. Sustainability

• Quarterly review of thresholds (EPSS), SLAs and asset tiers against real performance: if a deadline is systematically breached, either the structural constraint gets fixed or the deadline does — it does not get ignored.
• Automate the repeatable: ingestion, deduplication, enrichment, ticket creation and routing to the owner, and closure verification. The human decides exceptions and edge cases; the toil of moving CSVs does not scale with the 50,000+ CVEs a year forecast.
• Prefer eliminating whole classes over patching instances: minimal base images updated centrally, reduced dependencies, retirement of ownerless services. A fixed base image closes thousands of findings; a ticket closes one.
• Watch source fragmentation: CVE Program, EUVD, GCVE, GHSA, OSV and vendor advisories. Review every 6 months whether your tools still cover the sources relevant to your estate.

List of prohibitions

• ❌ Prioritising by CVSS severity alone, ignoring exploitation, exposure and asset criticality.
• ❌ Treating the vendor's base CVSS (CVSS-B) as if it were your risk: the environmental and threat parts are missing.
• ❌ A vulnerability programme without an asset inventory with owner, exposure and criticality.
• ❌ Unauthenticated scanning as the only source of patch state.
• ❌ Closing a finding without verification by rescan or version check.
• ❌ Marking false positives without a documented reason or a reusable VEX.
• ❌ An exception without an expiry date, without verified compensating controls or approved by the security team itself.
• ❌ Compensating controls recorded as definitive remediation.
• ❌ Issuing an SLA for a patch that does not exist, instead of processing an exception with mitigations.
• ❌ Uniform SLAs that ignore asset tier and exposure.
• ❌ Publishing SLAs that are known to be unachievable.
• ❌ Relying exclusively on NVD for enrichment after the April 2026 policy change.
• ❌ Counting identifiers (CVE vs GHSA vs OSV vs EUVD) as if they were distinct vulnerabilities.
• ❌ Using 0.10 EPSS as the "official" threshold: it is not.
• ❌ Comparing EPSS scores across a model version change without noting it.
• ❌ Static, over-privileged scan credentials or credentials outside the secrets manager.
• ❌ Scanning tools pinned by mutable tag in CI.
• ❌ Vulnerability reports in open channels or unclassified.
• ❌ EOL software in production without formally accepted risk, an exit plan and a date.
• ❌ Raw vulnerability count as a team performance metric.

8. Mandatory web verification

This domain expires in months, not years. Before pinning any threshold, deadline or source, verify with WebSearch:

1. EPSS: the model version in force at first.org/epss/data (v5 / v2026.06.15 since 15 Jun 2026) and the threshold guidance at first.org/epss/using-epss.
2. CVSS: whether v4.0 is still FIRST's current version and what your source actually publishes (v3.1, v4.0 or both).
3. KEV and directives: the state of the catalogue and of BOD 26-04 (10 Jun 2026; revokes BOD 22-01 and BOD 19-02) at cisa.gov, including the deadline table and its implementation milestones.
4. CVE Program: the state of funding and governance (CISA-MITRE contract, CVE Foundation) and the role of ENISA's EUVD and GCVE; check which sources your tool ingests today.
5. NVD: the enrichment policy in force (since April 2026 it only prioritises KEV, federal and EO 14028 critical software) and its impact on your scanner's CPE matching.
6. VEX/SBOM: the state of CSAF 2.1 at OASIS, the OpenVEX version, and the CycloneDX/SPDX version your consumer actually supports (Dependency-Track was still rejecting CycloneDX 1.7 in 2026).
7. EOL: end-of-support dates at endoflife.date and in the vendor's official lifecycle. Never from memory.
8. Advisories for your own scanning tools before introducing or updating them (the Trivy case, March 2026).

If the web contradicts this document, the web wins — flag the discrepancy.