To stay ahead of new CVEs, keep a current inventory of what you run, match it against vulnerability data every day, rank findings by evidence of exploitation and exposure, and set fix deadlines in advance. Reading headlines does not scale. Knowing which of your systems are affected does.
What is a CVE, and what is it not?
A CVE is an identifier for a publicly known vulnerability, assigned through the CVE Program. It gives everyone the same name for the same flaw. It is not a severity rating, a risk score or an instruction.
Severity usually comes from CVSS, which describes the technical characteristics of the flaw. Your risk also depends on whether the software is present, reachable and exposed, which no public score can know.
Why is the volume the real problem?
Tens of thousands of CVEs are published each year. Nobody patches all of them at once, and most do not affect any given environment. The skill is filtering quickly and accurately.
Three questions do most of the filtering.
Do we run it? This needs an inventory. For applications, that means a list of dependencies per service, including transitive ones. For infrastructure, a list of products and versions.
Is it being exploited? CISA's Known Exploited Vulnerabilities catalog lists flaws with evidence of exploitation in the wild. FIRST's Exploit Prediction Scoring System, EPSS, estimates the probability that a CVE will be exploited in the near term. Neither is perfect, but together they beat severity alone.
Can an attacker reach it? An internet-facing service with the vulnerable function is different from a library that sits unused in a build tool. Reachability analysis for code and exposure mapping for infrastructure answer this.
What does a daily routine look like?
A constructed example for a team of ten engineers.
Every morning an automated job compares the inventory with new advisories. Items on the KEV catalog that match the inventory open a ticket marked urgent with a fix deadline of a few days. Items with a high EPSS probability and internet exposure get a short deadline too. Everything else goes into a weekly batch. Findings in unreachable code are recorded with a reason and reviewed monthly.
On a bad day, a widely used library gets a critical advisory. The team already knows within an hour which four services include it, and which one calls the vulnerable function. They patch that one first.
What if there is no fix yet?
Mitigate. Options include disabling the affected feature, adding a web application firewall rule, restricting network access, or adding a runtime check. Record the mitigation, the owner and a date to revisit. Subscribe to the vendor's advisory feed for a patch.
For flaws with no CVE yet, zero-day discovery in your own dependencies is a separate effort. Safeguard offers zero-day discovery, reachability analysis and policy gates, so a newly disclosed flaw can be matched to your inventory and blocked from new builds.
Who should own the process?
Name one owner for the vulnerability intake process and one deputy. Give them authority to open urgent tickets directly into team queues, with a published deadline that teams accept in advance. Without that agreement, every urgent item turns into a negotiation. Review the numbers monthly: time to fix known exploited flaws, count of open exceptions, and share of services with a current inventory. When a number slips, look for a process cause such as unclear ownership before blaming individual teams.
How to check or apply this
- Build a per-service dependency inventory and keep it current with each build.
- Match it to vulnerability data at least daily.
- Flag anything on the KEV catalog for fast action.
- Use EPSS and exposure to rank the rest.
- Add reachability to cut noise.
- Write fix deadlines by category and measure how often you meet them.
- Track exceptions with an owner and expiry date.
Quick check
Is a high CVSS score the same as high risk?
No. CVSS rates the flaw's characteristics. Risk depends on exploitation, exposure and whether your code uses the vulnerable part.
What is the KEV catalog?
CISA's list of vulnerabilities with evidence of active exploitation. It is a strong signal for priority.
Sources
- CVE Program
- Known Exploited Vulnerabilities Catalog, CISA
- Exploit Prediction Scoring System, FIRST
- BOD 22-01, CISA
Last reviewed: 18 October 2026.
