Vulnerability and Exposure Management
Vulnerability management is the continuous loop of finding weaknesses in what you run, deciding which matter, getting them fixed and proving they're fixed. It sounds like admin work, but in 2026 it is the front line: Verizon's 2026 Data Breach Investigations Report found that exploiting a vulnerability (31%) overtook stolen credentials (13%) as the most common way attackers got in, the first time in the report's 19 years. This page covers the lifecycle, how to prioritise (CVSS vs EPSS vs KEV), SLAs, edge devices, and how to talk about it in an interview.
Last verified2026-10
What Is It?
What is this?A vulnerability is a specific weakness, usually with a CVE ID (Common Vulnerabilities and Exposures), like CVE-2023-4966 in Citrix NetScaler. Vulnerability management handles those one by one. Exposure management is the wider view: everything an attacker could use, including misconfigurations, exposed services, weak identities and missing MFA, not only CVEs.
Why it mattersNobody can patch everything. In October 2026 FIRST's EPSS model scored 385,738 published CVEs, while CISA's Known Exploited Vulnerabilities catalog listed 1,739 that attackers had actually used. The job is finding the few that matter for your systems before attackers do, and getting busy engineers to fix them.
How it works
-
Know what you haveInventorycontinuous
- Assets, owners, internet exposure, software versions, SBOMs
- You can't patch what isn't on the list
-
Find weaknessesDiscoverdaily to weekly
- Network and agent-based scanners, container and dependency scanning, cloud posture tools, external attack-surface scans
-
Decide what matters firstPrioritiseper finding
- Known exploited? Likely to be exploited? Internet-facing? Critical asset?
-
Fix, mitigate or acceptRemediateby SLA
- Patch, upgrade, config change, compensating control, or documented risk acceptance
-
Prove it's goneVerifyafter the fix
- Rescan, check versions, and for some bugs kill sessions or rotate secrets too
-
MeasureReportmonthly
- Time to remediate, SLA compliance, coverage, overdue critical items by owner
Prioritisation: CVSS, EPSS, KEV and SSVC
What is this?Four common inputs, each answering a different question. Using only one is the most common mistake.
Common Vulnerability Scoring System, 0–10. How bad is this bug in theory? v4.0 (2023) adds threat and environmental metrics, but most feeds still publish only the base score
Exploit Prediction Scoring System from FIRST. Probability (0–1) that the CVE is exploited in the next 30 days, recalculated daily from real-world signals
CISA's Known Exploited Vulnerabilities catalog: CVEs with evidence of exploitation in the wild, with a due date for US federal agencies
Stakeholder-Specific Vulnerability Categorization: a decision tree (exploitation, exposure, automatable, impact) that outputs Track, Track*, Attend or Act
Why CVSS alone failsRoughly half of all scored CVEs rate "high" or "critical" on CVSS, far more than any team can treat as urgent. CVSS describes the bug, not whether anyone is using it. EPSS and KEV add the "is it being used?" signal.
In practiceReal scores from the FIRST EPSS API and the CISA KEV feed, 11 October 2026:
$ curl -s "https://api.first.org/data/v1/epss?cve=CVE-2023-4966,CVE-2024-3094"
{"cve":"CVE-2023-4966","epss":"0.99999","percentile":"0.99997"} ← Citrix Bleed: near-certain exploitation
{"cve":"CVE-2024-3094","epss":"0.85974","percentile":"0.99727"} ← xz backdoor
$ curl -s "https://api.first.org/data/v1/epss?epss-gt=0.1&limit=1" | jq .total
17299 ← only ~4.5% of 385,738 CVEs score above 10%
$ jq '.vulnerabilities[] | select(.cveID=="CVE-2023-46805") | {dateAdded, dueDate, knownRansomwareCampaignUse}' kev.json
{ "dateAdded": "2024-01-10", "dueDate": "2024-01-22", "knownRansomwareCampaignUse": "Known" } ← Ivanti: 12 days to fixA practical rule set most teams can defend in an interview:
| Condition | Priority | Example target |
|---|---|---|
| In KEV and internet-facing | Emergency | Mitigate within 24–72 hours |
| In KEV, internal; or EPSS ≥ 0.1 and internet-facing | High | 7–14 days |
| CVSS ≥ 7, low EPSS, not exposed | Medium | 30–60 days |
| Everything else | Low | Next maintenance cycle, or accept |
Adjust for asset criticality: a domain controller or payment system moves up a level, a lab VM moves down.
Memory hookCVSS is how sharp the knife is, EPSS is how likely someone picks it up, KEV is the knife already used in a crime. Prioritise what's been used, then what's likely to be used, then what's merely sharp.
Edge Devices: Where Exploitation Concentrates
What is this?Edge devices are the boxes facing the internet: VPN gateways, firewalls, load balancers, file-transfer appliances (Ivanti, Citrix NetScaler, Fortinet, Palo Alto, MOVEit). They are reachable by anyone, often run old code you can't add an EDR agent to, and sit right at the boundary of your network.
Why it mattersState actors and ransomware crews mass-exploit them within days, sometimes hours, of disclosure. Verizon's 2025 report found exploitation of edge devices and VPNs rose to 22% of exploitation cases, up from 3%.
📰Real incident — Ivanti Connect Secure (2024, CVE-2023-46805 and CVE-2024-21887). An authentication bypass chained with command injection gave attackers root on Ivanti VPN gateways. It was exploited as a zero-day, and CISA issued an emergency directive telling US agencies to apply mitigations and then disconnect the appliances and rebuild them. Attackers had also tampered with the device's built-in integrity checker. Lesson: for edge appliances, patching may not be enough. Assume compromise, check with the vendor's external tool, and rebuild.
📰Real incident — Citrix Bleed (2023, CVE-2023-4966). A memory leak in NetScaler let attackers read session tokens from the appliance's memory and take over already-authenticated sessions, bypassing passwords and MFA. Patching stopped new leaks but did not invalidate tokens already stolen. Victims that patched without killing all active sessions stayed compromised. LockBit used it against Boeing and the US arm of ICBC, China's largest bank. Lesson: "verify" means asking what the bug may already have leaked, not just checking the version.
🎯On the job. Keep a list of every internet-facing appliance with its owner, version and vendor advisory feed. When a KEV entry lands for one of them: apply the vendor's mitigation the same day, hunt for the published indicators, kill sessions or rotate credentials if the bug leaks them, and plan the rebuild if exploitation was possible before you patched.
Remediation in Real Organisations
What is this?Finding vulnerabilities is easy; getting them fixed is the hard part. Security usually doesn't own the systems, so remediation is a negotiation with engineering teams.
How it works
Map asset → team through tags, CMDB or code ownership, and open tickets in the team's own tracker, not a security spreadsheet.
One base-image update fixes 400 container findings. A golden AMI pipeline fixes every VM. Report "47 findings, one fix".
when a patch isn't possible: WAF rule, disable the feature, block the port, isolate the host. Record them with an expiry date.
has a named owner, a reason and a review date. Never an open-ended "won't fix".
(Vulnerability Exploitability eXchange) lets a supplier state "this CVE is in our SBOM but not exploitable in our product", cutting noise from dependency scanners.
In practiceWhat a useful ticket looks like (enough context that an engineer can act without asking security):
[VULN-HIGH] CVE-2024-6387 (regreSSHion) on 14 hosts — payments-api ASG Due: 2026-10-18 (7 days)
Why now: EPSS 0.995, public exploit, hosts accept SSH from the VPN range ← reason, not just a score
Fix: bump base AMI to ami-0abc… (OpenSSH 9.8p1); redeploy ASG
Interim: restrict sg-0123 port 22 to the bastion only
Verify: `ssh -V` on a host reports 9.8p1; scanner finding auto-closesMetrics that mean something
- Median and 90th-percentile time to remediate, by priority.
- SLA compliance for KEV and emergency items (the number leadership should see).
- Coverage: percentage of assets scanned in the last 7 days. Unscanned assets are the real risk.
- Recurring findings: the same CVE coming back means the build pipeline, not the team, needs fixing.
📰Real incident — Equifax (2017, CVE-2017-5638). Apache Struts published a patch on 7 March 2017; Equifax's patch notice went out, but the vulnerable dispute portal wasn't on the list of systems to patch, and a scan missed it. Attackers got in on 13 May and stayed for 76 days, taking data on about 147 million people. An expired certificate on a traffic-inspection device meant nobody saw the exfiltration. Every step of the lifecycle failed: inventory, discovery, verification and monitoring.
The Wider Picture: Exposure Management and the CVE Ecosystem
Last verified2026-10
is Gartner's five-stage programme (scoping, discovery, prioritisation, validation, mobilisation). The new part is validation: proving an exposure is actually reachable and exploitable, through attack-path analysis, breach-and-attack simulation or penetration testing, before asking a team to drop everything.
finds what you expose that you didn't know about: forgotten subdomains, test servers, cloud storage, leaked credentials.
NIST's National Vulnerability Database stopped enriching most new CVEs with CVSS and product data in February 2024, leaving a large backlog. In April 2025 MITRE's contract to run the CVE program nearly lapsed and was extended at the last minute. ENISA launched the EU Vulnerability Database in May 2025. Don't build a programme that depends on one feed.
The EU Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities in their products within 24 hours from 11 September 2026. CISA's Binding Operational Directive 22-01 makes KEV deadlines mandatory for US federal agencies.
Interview Questions
I don't start with CVSS, because roughly half of all CVEs are rated high or critical. I start with what's being exploited: anything in CISA's KEV catalog on an internet-facing asset is first, then high EPSS scores on exposed systems, then KEV items on internal critical assets. That usually turns 10,000 into a few dozen. Then I look for fixes that close many findings at once, like a base image or golden AMI update, and send each owner a ticket with the reason, the fix and a due date. Verizon's 2026 report showing exploitation as the top initial access vector at 31% is why the exploited ones go first.
CVSS measures how severe a vulnerability would be if exploited, on a 0–10 scale, based on the bug's characteristics. EPSS, from FIRST, estimates the probability that it will actually be exploited in the next 30 days, using real-world signals, and it's updated daily. They answer different questions: in October 2026 only about 4.5% of 385,000 scored CVEs had an EPSS above 10%, while far more have a high CVSS. Good prioritisation combines both with KEV for confirmed exploitation and with your own context, like internet exposure and asset value.
They're internet-facing by design, often closed appliances where you can't run EDR, and they sit at the network boundary, so one bug gives an attacker a foothold with access inside. When a KEV entry lands for our VPN, I apply the vendor mitigation the same day, hunt for the published indicators of compromise, and check whether the bug leaks sessions or credentials. Citrix Bleed taught that patching doesn't revoke stolen session tokens, and Ivanti in 2024 taught that a device exploited before the patch may need rebuilding, not just updating.
I make it easy and visible. Findings go automatically to the owning team's own tracker with a clear reason, a concrete fix and a due date based on agreed SLAs, rather than a PDF from security. I group findings into fixes, like one base-image bump that clears hundreds of container CVEs, and I report SLA compliance by team to leadership monthly. When a patch isn't possible, I agree a compensating control and a documented risk acceptance with an expiry, so nothing stays open forever by default.
Rescanning confirms the version changed, but some bugs leave consequences behind. If the vulnerability could leak secrets or sessions, like Citrix Bleed or Heartbleed, I kill active sessions and rotate keys and credentials. If it could give code execution before we patched, I treat the host as possibly compromised: check for web shells and persistence, and rebuild if there's doubt. And I check that the build pipeline is fixed too, so the old version doesn't come back with the next deployment.
Time to remediate by priority, median and 90th percentile, because averages hide the long tail. SLA compliance for KEV and emergency items, which is the number leadership should care about. Scan coverage, meaning the share of assets scanned in the last week, since unscanned assets are where surprises come from. And recurring findings, because the same CVE coming back means the image or pipeline needs fixing, not the team. I avoid raw counts of open vulnerabilities; they mostly measure how many scanners you run.