Tracking CVEs and Vulnerabilities
Tracking CVEs and Vulnerabilities
Section titled “Tracking CVEs and Vulnerabilities”Tens of thousands of CVEs are published every year — far more than any team can patch immediately. Effective vulnerability management is not “patch everything”; it’s knowing what to patch first. That requires understanding the data sources and the scoring systems, then combining them with the context of your own environment.
The CVE landscape
Section titled “The CVE landscape”- CVE — a program run by MITRE that assigns a unique
identifier (e.g.
CVE-2024-12345) to a vulnerability. The ID is just a name and a short description; it is the shared reference everyone else builds on. - NVD — the U.S. National Vulnerability Database enriches CVEs with CVSS severity scores, affected-product data (CPE), and references.
- CVSS — the Common Vulnerability Scoring System rates severity 0–10. Useful, but it measures intrinsic severity, not the likelihood you’ll actually be attacked — don’t prioritize by CVSS alone.
NVD vs vendor: source of truth
Section titled “NVD vs vendor: source of truth”NVD is the common reference, but its enrichment has at times lagged badly (large analysis backlogs), so a CVE can sit without a score or CPE data for weeks. For timeliness and accuracy, the vendor’s own advisory is often the authoritative source for whether their product is affected and what the fix is. In practice:
- Subscribe to advisories for the products you actually run (vendor mailing lists/RSS, GitHub Security Advisories, distro security trackers).
- Treat NVD as the cross-vendor index, but verify affected versions and remediation against the vendor advisory.
Prioritize with KEV and EPSS
Section titled “Prioritize with KEV and EPSS”Two free signals turn the firehose into a short list:
- CISA KEV — the Known Exploited Vulnerabilities catalog. If a CVE is on KEV, it is being exploited in the wild right now. This is the strongest “patch immediately” signal that exists.
- EPSS — the Exploit Prediction Scoring System (FIRST.org) gives each CVE a probability (0–1) that it will be exploited in the next 30 days. It separates the small set of likely-exploited CVEs from the large set that technically could be.
A practical priority order:
| Priority | Signal |
|---|---|
| Drop everything | On CISA KEV (actively exploited) and exposed in your environment |
| High | High EPSS + high CVSS + internet-facing asset |
| Medium | High CVSS but low EPSS, or internal-only asset |
| Low / scheduled | Low EPSS, low exposure |
Always weight by your context: an internet-facing, business-critical asset outranks a higher-CVSS bug on an isolated internal box. Feed your asset/exposure model from threat modeling.
Automation
Section titled “Automation”At scale this must be automated:
- Scanners map CVEs to your inventory (OpenVAS/Greenbone, Trivy for containers, and
dependency scanners like
osv-scanner/Dependabot for code). - Data feeds — VulnCheck and the OSV database provide machine-readable vulnerability data; Vulnogram helps author/format CVE records.
- Enrich + route — automatically tag incoming CVEs with KEV/EPSS, match against your asset inventory, and open tickets only for what crosses your priority threshold so the team isn’t buried.
Detections for exploitation attempts belong in your SIEM — see Blue Team Tools — so you catch attempts on the CVEs you haven’t patched yet.
Related
Section titled “Related”- Blue Team Tools — detecting exploitation of unpatched CVEs
- Threat Modeling — weighting CVEs by real exposure
- Enterprise Incident Response — when a CVE becomes an incident
- Malware Analysis — understanding exploit payloads