vulnerability_management v1.0.0

name: "vulnerability_management" description: "Run vulnerability management as a loop: asset scoped scanning, prioritising by real exploitability and exposure instead of raw severity, remediation deadlines by risk, exceptions with expiry dates, and verifying the fix closed the hole. Use when triaging scanner output, building or fixing a vulnerability management program, setting remediation deadlines, handling a new KEV entry, reviewing overdue findings or exceptions, or proving a reported fix actually worked. Ships a triage scoring sheet, a remediation tracker format, a working triage script, and a worked scan to verified fix cycle."

Vulnerability Management

Purpose

A scanner produces findings. A vulnerability management program turns findings into verified fixes, on deadlines set by real risk, with a paper trail that survives an audit and a second look. This skill runs that program as a loop with six stages: inventory, scan, triage, remediate, verify, and review. The method follows NIST SP 800-40 Rev. 4 for the life cycle, CIS Controls v8 Control 7 for the program safeguards, CISA SSVC and BOD 26-04 for prioritisation and deadlines, and FIRST EPSS and CVSS for the two scoring signals, each used for what it actually measures.

The core discipline is simple to state and easy to lose: severity is not priority. A CVSS 10.0 on an isolated box with no exploit activity can wait behind a CVSS 7.5 that attackers are using today on a public service. This skill exists to make that ordering routine, defensible, and repeatable.

Workflow

1. Know the assets before you scan them

• Build the inventory first: hardware, software down to packages and libraries, cloud assets, and owners for each asset. NIST SP 800-40 Rev. 4 puts this first for a reason. You cannot triage a finding on an asset nobody owns.
• Record exposure and criticality in the inventory: publicly exposed or internal, and essential, support, or minimal for the mission. These two fields drive deadlines later, so guessing them at triage time is where programs go wrong.
• Group assets into maintenance groups with similar platforms and owners, so scanning, patching, and reporting run per group instead of as one undifferentiated pile.
• Reconcile the inventory against outside discovery (external scans, cloud provider lists) on a set cadence. Assets found outside the inventory enter it the same week, with an owner named.

2. Scan on a cadence the team can act on

• Run automated credentialed scans of internal assets and unauthenticated scans as a second view. CIS Controls v8 safeguards 7.5 and 7.6 set the baseline: internal assets quarterly or more often, externally exposed assets monthly or more often, with remediation work running monthly or more often under 7.7. Treat that as a floor. Public and regulated estates usually scan weekly or continuously.
• Add event driven scans: a new KEV entry that matches your software, a major deployment, a newly exposed service.
• Match cadence to capacity. A weekly scan into a monthly fix cycle only grows a backlog nobody reads. Where capacity is the constraint, say so in the review and fix the constraint.
• Track scan coverage as a metric: assets scanned divided by assets in inventory. Unscanned assets are an unknown, not a clean bill.

3. Triage every finding against real risk

Score each finding, one CVE on one asset, with the sheet in references/triage-scoring-sheet.md. The signals, in the order they should be checked:

1. CISA KEV status. Confirmed exploitation in the wild. This is a fact about the world, not a model output, and it outranks every forecast.
2. Public exposure. Reachable by unauthenticated or untrusted parties. Unknown exposure counts as exposed.
3. Technical impact and automatability, from CISA Vulnrichment data in the CVE record. Total control and reliable automation are the dangerous pair.
4. EPSS from FIRST. A calibrated probability, 0 to 1, of exploitation in the wild in the next 30 days, updated daily. Use it as a threshold signal, default gate at 0.10.
5. CVSS base score. Technical severity, 0.0 to 10.0. It describes how bad exploitation could be, not how likely it is.
6. Asset criticality and compensating controls, from your own inventory and control review.

Hard rule, from FIRST: never multiply EPSS by CVSS. EPSS is a calibrated probability, CVSS Base is an ordinal ranking, and the product means nothing. Keep the two signals side by side.

For a queue you can sort and hand out, run the bundled scorer on a CSV export of findings:

python3 scripts/triage.py findings.csv --as-of 2026-10-22 --out queue.csv

Input columns, output tiers, and the exact gate logic are documented in the script header and in the scoring sheet. The script also flags expired exceptions and escalates their tier. A sample input and its verified output sit in the scoring sheet, so you can check the tool against hand scoring before trusting it on real data.

4. Set the deadline from the tier, then work the queue

Default deadlines, shaped on the CISA BOD 26-04 tiers:

| Tier | Deadline | |---|---| | P0, in KEV with total impact | 3 days, plus forensic triage | | P0, exposed and automatable with total impact | 3 days | | P1 | 14 days | | P2 | 60 days | | P3 | Next scheduled upgrade or rebuild |

The clock starts at the earlier of the KEV entry date or the date you first found the vulnerability on the asset. Rollbacks, rescans, and reassignments do not restart it. Federal agencies: your compliance deadlines come from the official BOD 26-04 Table 1, which maps all combinations of exposure, KEV status, automatability, and technical impact. This table is a default policy for everyone else, and a starting point for federal teams, not a substitute for the directive.

Assign every P0 and P1 finding a named owner and a named approver for any delay. SSVC frames the same idea as attention levels: Track and Track* run on standard timelines, Attend pulls in supervisory attention and a shorter timeline, Act pulls in leadership and action as soon as possible. Map your tiers to those words when you report upward, it keeps the conversation about decisions instead of scores.

5. Remediate, mitigate, or accept, in that order of preference

• Remediate: patch, upgrade, change the configuration, remove the feature, or decommission the asset. Record the concrete change, for example the version moved to. "Patched" is not a record.
• Mitigate when the fix cannot land in the window: disable the vulnerable feature, restrict who can reach the service, block egress, add a targeted detection. A mitigation lowers risk and buys time inside the same deadline. It does not close the finding.
• Accept only through the exception process in references/remediation-tracker.md: a named requester, an approver one level up, compensating controls in the record, and an expiry date. Defaults: 30 days for P0 and P1, 90 days for P2. No open ended exceptions.
• For P0 findings with total impact, run forensic triage in parallel with the fix. CISA guidance puts scoping inside the first 2 hours and the escalation decision inside 48 to 72 hours, with evidence collected before patching where possible, because patching can destroy artifacts. A patched box that was already compromised is still a compromised box.

6. Verify the fix, with evidence, by a second pair of eyes

• Verify with the strongest method available: credentialed rescan, package version readback from the running system, configuration readback, or a runtime test. Scanner clean plus version check beats either one alone, because scanners miss shaded and relocated library copies.
• The verifier is not the person who applied the fix, wherever staffing allows. Record verifier, date, and method in the tracker.
• A failed verification reopens the finding on its original due date, with a note stating what verification found. Check for a second copy of the component before disputing the scanner.
• Sample already closed findings each month and recheck them. A verification step that never fails anything is not verifying.

7. Review the loop weekly, and the program quarterly

Run the 30 minute weekly review from the tracker reference: P0 and P1 status, overdue and reopened findings by name, exceptions expiring inside 14 days, new KEV matches, and one metric that moved the wrong way. Quarterly, review the program itself: scan coverage, EPSS gate choice, tier deadlines against actual clearing rates, repeat findings, and whether maintenance groups still match how the estate is built. NIST frames patching as preventive maintenance and a cost of doing business. Budget and staff it that way in the quarterly conversation.

references/worked-example.md walks one finding, CVE-2021-44228 on a public gateway, through every stage above: scan, triage output from the bundled script, forensic triage on the CISA timeline, remediation, and a four part verification that closes it.

Output Contract

A completed cycle produces:

1. A current asset inventory with owners, exposure, and criticality recorded.
2. A triaged queue where every finding carries a tier, a due date, an owner, and a reason string naming the signals that set the tier.
3. A remediation tracker in the format in references/remediation-tracker.md, with fix details and verification evidence per finding.
4. An exception register where every entry has an approver, compensating controls, and an expiry date, and where expired exceptions are visibly escalated.
5. For P0 findings, a forensic triage report with a stated conclusion: no evidence of compromise, suspected, or confirmed.
6. A weekly metrics view: open by tier with oldest age, mean time to remediate, overdue rate, verification pass rate, exception counts, and scan coverage.

Operating Rules

1. Severity is not priority. Order work by exploitation, exposure, and impact together. A queue sorted by CVSS alone is a failed triage.
2. KEV outranks forecasts. A KEV listing is confirmed exploitation. EPSS refines the order of everything else, it never demotes a KEV finding.
3. Never multiply EPSS by CVSS, and never present EPSS as a risk score. FIRST is explicit on both. EPSS is the likelihood input, your asset context supplies the rest.
4. Unknown exposure counts as exposed. Unknown ownership blocks closure, not triage: assign the finding to the platform team until an owner is found.
5. Deadlines start at first identification or KEV entry, whichever is earlier, and nothing resets them except a verified change in the facts, such as the asset leaving public exposure, which is itself recorded.
6. A mitigation is not a fix, and an exception is not a deletion. Both keep the finding visible, dated, and owned.
7. Every exception expires. Expired exceptions escalate one tier the day they lapse and stay on the weekly agenda until cleared.
8. Fixes are closed by verification evidence, not by the fixer. Method, verifier, and date go in the tracker, or the finding stays open.
9. For P0 findings, check for compromise alongside the patch. Patching first and asking later can destroy the evidence that answers the question.
10. Accuracy rule. Every factual claim in reports and escalations is verified against the source data: the scan, the KEV feed, the EPSS pull, the version readback. Dates and scores come from those records, never from memory. Unverifiable means it goes in as an open question, not as a fact.