June 2026 · 7 minute read
Vulnerability prioritization after the NVD
NIST stopped scoring most CVEs and CISA took CVSS out of its patch deadlines. The scores were never built for the code most teams now ship.
Shlomie Liberow
Founder & CEO, aisy
We spent ten years in bug bounty, first finding bugs and then making the calls on thousands of reports. Hackers often got paid for variants of bugs the company had already paid out for the year before, with the same root cause in a different layer of the product.
The companies fixed what was reported, in the order their scores told them to. The order was fine, but it was nobody's job to ask why the bug existed, so the root cause stayed and hackers found more variants of it.
For most security teams, vulnerability prioritization still works that way: take each finding, score it, sort the list, and work from the top. In 2026, NIST and CISA both made changes that undercut that approach.
What changed for vulnerability prioritization in 2026
NIST stopped enriching most CVEs in the NVD
In April, NIST stopped analyzing most new CVEs in the National Vulnerability Database (NVD). It now only analyzes CVEs that are known to be exploited, that affect software the US government uses, or that affect software the government classes as critical. It marks the rest "Not Scheduled". It also stopped adding its own CVSS score when the vendor has already given one.
NIST's reason was volume. CVE submissions rose 263% between 2020 and 2025, and the first three months of 2026 were about a third higher than the same months of 2025.
If your tools read severity scores from the NVD, a growing share of new CVEs now arrive with whatever score the vendor chose to give them, or with no score at all.
CISA took CVSS out of federal patch deadlines
In June, CISA replaced its rules for federal patch deadlines with a new directive, BOD 26-04. Federal agencies now set each patch deadline based on four questions:
- Is the vulnerable asset publicly exposed?
- Is the CVE in CISA's Known Exploited Vulnerabilities (KEV) catalog?
- Can an attacker automate every step of the exploit?
- Does exploitation give partial or total control of the system?
CVSS is not one of the four. The first question has no lookup table: each agency has to answer it about its own assets. For the worst combinations, agencies get three days to fix the vulnerability, and must also check whether the system is already compromised. CISA's stated reason is that attackers' "use of AI may further narrow the time defenders have to react."
KEV is still one of CISA's four questions, and EPSS still estimates the chance of exploitation for the CVEs it covers. But NIST can no longer keep up with the volume of CVEs, and CISA's deadlines now depend on a fact only you can answer about your own assets.
Why CVSS, EPSS, and KEV don't cover vulnerabilities in your own code
CVSS, EPSS, and KEV all describe CVEs, and a CVE only exists for a flaw in published software: an open source library, a vendor product, or an operating system. Third-party code still produces a huge volume of CVEs, and the NVD can no longer keep up with them.
A bug in your own code never gets a CVE. A broken access check in your API, or a trust assumption between two of your services, will never have a CVSS score, an EPSS probability, or a KEV entry. Pentests and bug bounty programs find these bugs, and now AI code review tools find them too.
Teams are writing more first-party code every year, and coding agents write a growing share of it. For this type of code, prioritization has to start from what the bug lets an attacker reach and what it chains with. That was always the standard in bug bounty, where you show the impact or you don't get paid.
What a ranked vulnerability list never tells you
Even where the scores work, a ranked list only answers one question: what to fix first. It can't tell you why the bug exists, who owns the system, how a fix gets shipped there, or whether the last forty findings were caused by the same mistake.
One security team had a scanner flagging an outdated version of 7-Zip on company laptops. The scanner's advice was to patch each machine. Their security lead saw the problem with that advice: the laptops got 7-Zip from one deployment in the company's device management tool, so patching one laptop did nothing to fix the next one. Fixing one laptop takes two minutes, but that laptop was the wrong place for the fix. Every week, the same 7-Zip tickets came back on the list. The ranking was accurate, but it never pointed at the deployment, where the fix belonged.
How to stop the same vulnerabilities coming back
Bug bounty hunters treat every bug as a lead. After they find a bug, they assume the same mistake exists elsewhere in the product, hunt for variants, and come back after each product release to check if it's still there. Some bug hunters feed hundreds of their past reports into AI models at every new release to find those variants faster.
Defenders can work the same way, and they have more to learn from. Every closed ticket can tell you who owned the system, why the bug happened, where the fix went, and what the team decided. A team that keeps learning from its tickets can decide on the next similar finding in minutes, because it already knows the owner, the root cause, and how the fix gets shipped. When several findings share a root cause, one fix at the source closes them all.
How we'd prioritize vulnerabilities now
- Answer the questions about your company first. Is the asset exposed? Is the vulnerable code reachable? Who owns it, and what data does it hold? Exposure is also the first of CISA's four questions.
- Use KEV and EPSS as inputs for third-party CVEs. They still help, but they cover a shrinking share of the findings you need to decide on.
- Judge first-party findings by what an attacker can do with them. No score exists for these bugs, so ask what the bug reaches and what it chains with.
- Group findings by root cause before you rank them. Ten tickets with one root cause need one decision and one fix.
- Record the reasoning behind every decision, including the findings you accept or close as false positives, and look at the decision again when the facts behind that reasoning change.
For more detail on the signals and the model, read the vulnerability prioritization guide.
In bug bounty, we watched companies pay for the same root cause again and again. We built aisy so security teams learn from every finding they close. aisy builds its own picture of your company based on every ticket, its own external scanning, and the code, so your team makes decisions on new findings fast, and one fix closes every ticket that shares a root cause.
Vulnerability management that learns.
Bring a recurring problem from your security backlog. We’ll look at what your team already knows, what it keeps re-checking, and how to get ahead of it.
Shlomie Liberow · Founder, aisy · shlomie@aisy.ai