Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
Vulnerability management is the continuous cycle of discovering, assessing, prioritizing, and remediating weaknesses across an organization’s assets — distinct from vulnerability *scanning*, which is just one input to it. A program that runs scans but has no reliable asset inventory, no risk-based prioritization, and no enforced remediation SLA will accumulate a growing backlog of findings that never meaningfully reduces risk, regardless of how sophisticated the scanning tool is.
The core insight that separates a mature program from a scanning checkbox is that not all vulnerabilities are equally urgent, and CVSS base score alone is a poor prioritization signal — a critical CVSS score on an internet-facing asset with a public exploit available is a different risk than the same score on an isolated internal system with no known exploitation. Prioritization has to combine severity, real-world exploitability, and business context (asset criticality, exposure) to direct limited remediation capacity where it actually reduces risk.
Attack Prerequisites
A vulnerability management program’s *gaps* are, from an attacker’s perspective, exactly the conditions that keep a known weakness exploitable:
- Assets missing from inventory — shadow IT, unmanaged cloud resources, or forgotten legacy systems that never enter the scanning scope in the first place.
- Known, actively-exploited vulnerabilities left unpatched past any reasonable window, often because prioritization was driven by CVSS alone rather than known exploitation status.
- No enforced remediation SLA, or an SLA with no escalation path when an owning team misses it, letting findings age indefinitely.
- No verification step — a finding marked “remediated” in a ticketing system without a rescan confirming the fix actually applied.
How It Works
The vulnerability management lifecycle runs: discover (asset inventory, ideally continuous rather than periodic, since unmanaged assets are a leading source of breach) -> assess (authenticated scanning where possible, since unauthenticated scans miss most OS/application-level findings; agent-based coverage for cloud and remote endpoints) -> prioritize (enrich each finding with context beyond CVSS) -> remediate (patch, configuration change, or a documented compensating control) -> verify (rescan to confirm closure) -> report (track program-level metrics over time, not just point-in-time finding counts).
Modern prioritization layers several signals on top of CVSS base score: CISA’s Known Exploited Vulnerabilities (KEV) catalog, a curated list of CVEs with confirmed real-world exploitation, which US federal agencies are required to remediate on a fixed timeline under Binding Operational Directive 22-01 (2021) and which many private-sector programs adopt as a de facto “patch these first” signal regardless of CVSS score; and the Exploit Prediction Scoring System (EPSS), maintained by FIRST.org, which estimates the probability a given CVE will be exploited in the wild within the next 30 days based on observed scanning and exploitation activity. A medium-CVSS finding that is KEV-listed or has a high EPSS score is frequently a higher real-world priority than an unexploited critical-CVSS finding on a well-segmented internal asset.
Remediation SLAs are typically tiered by a combination of severity and exposure — internet-facing critical findings on the shortest clock, internal low-severity findings on the longest — and programs that lack an escalation mechanism for missed SLAs routinely find the backlog simply grows rather than shrinks, since there is no consequence for an owning team deprioritizing remediation against other work.
Practical Example / Configuration
A risk-based prioritization scoring policy combining the three signals above into a single triage score, rather than sorting the backlog by CVSS alone:
{
"scoring_policy": "risk-based-triage-v1",
"inputs": {
"cvss_base": {"weight": 0.3},
"epss_score": {"weight": 0.3},
"cisa_kev_listed": {"weight": 0.25, "boolean_boost": 40},
"asset_criticality": {"weight": 0.15, "scale": ["low", "medium", "high", "crown_jewel"]},
"internet_facing": {"boolean_boost": 20}
},
"action": "sort_desc(triage_score)"
}
A corresponding SLA policy tying triage tier to remediation timelines and escalation, the kind of artifact a program should have codified and enforced through its ticketing integration:
sla_policy:
critical: # KEV-listed OR (CVSS>=9 AND internet-facing)
remediate_within: 7d
escalate_after: 5d
high:
remediate_within: 30d
escalate_after: 21d
medium:
remediate_within: 90d
escalate_after: 75d
low:
remediate_within: 180d
escalate_after: null
exception_process:
requires: [risk_acceptance_ticket, expiry_date, compensating_control]
Walkthrough / Exploitation
Standing up or maturing a program follows a repeatable build sequence:
1. Establish continuous asset discovery (cloud API-based inventory,
network scanning, agent deployment) -- an accurate inventory is
the prerequisite for every later step meaning anything.
2. Deploy authenticated scanning against the inventory; supplement
with agent-based coverage for endpoints and ephemeral cloud
resources unauthenticated network scans miss.
3. Pull in CISA KEV and FIRST EPSS feeds and re-score the existing
backlog -- this alone often reprioritizes the queue significantly
versus CVSS-only sorting.
4. Tag assets with criticality and define SLA tiers combining
severity, exploitability, and exposure.
5. Automate ticket creation to owning teams with the SLA and
escalation path attached.
6. Rescan on remediation to verify closure before marking a finding
resolved; track exceptions with an expiry date, not indefinitely.
7. Report program-level metrics (mean time to remediate by tier,
SLA compliance rate, KEV-listed findings outstanding) to
leadership on a regular cadence.
Querying the CISA KEV feed directly to cross-reference against an existing finding export is a common, low-effort first pass at reprioritization even before full EPSS integration:
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
| jq -r '.vulnerabilities[].cveID' > kev_cves.txt
comm -12 <(sort kev_cves.txt) <(sort our_open_findings_cves.txt)
# Findings in this intersection: treat as critical regardless of
# CVSS score, since they have confirmed real-world exploitation.
Note: CVSS base score measures theoretical severity assuming exploitation occurs, not the likelihood it will — a 9.8 CVSS finding with no public exploit and requiring adjacent network access is routinely less urgent than a 7.0 finding that is actively being exploited at internet scale. Programs that sort purely by CVSS consistently misallocate remediation effort.
Opsec: Authenticated scanning requires credentials with read access across the fleet, which makes the scanner’s own credential store a high-value target — scope scanning credentials to read-only where the tool supports it, and treat the scanning platform itself as a Tier-0/Tier-1 asset in its own right.
Detection and Defense
- Maintain continuous, automated asset discovery rather than periodic manual inventory — unmanaged assets are a leading source of unpatched exposure.
- Prioritize with CISA KEV and EPSS alongside CVSS, not CVSS alone, to focus limited remediation capacity on real-world risk.
- Enforce SLA with automated escalation, and require a time-bounded risk-acceptance ticket with a compensating control for any documented exception.
- Verify remediation with a rescan before closing a finding, not just on the owning team’s attestation.
- Deploy compensating controls for unpatchable systems (network segmentation, virtual patching via WAF/IPS signature) where a fix is not immediately available.
Real-World Impact
CISA’s Binding Operational Directive 22-01, which mandates federal civilian agencies remediate KEV-listed vulnerabilities on fixed timelines, formalized what mature private-sector programs had already converged on: exploitation status, not CVSS alone, should drive remediation urgency. Breach post-mortems across the industry continue to trace initial access back to known, patchable vulnerabilities that had been open for months, which is consistently a program-maturity failure (prioritization, SLA enforcement, verification) rather than a scanning-coverage failure.
Conclusion
A vulnerability management program is a discipline of prioritization and follow-through, not a scanning tool — the scanner supplies findings, but asset inventory, risk-based scoring against real exploitation data, enforced SLAs, and rescan verification are what actually convert findings into reduced risk. Programs that skip any of those steps accumulate a backlog that looks like coverage but does not translate into fewer real opportunities for an attacker.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments