How to handle rising CVE counts when your team is small

What changed: the CVE numbers

The figures below come from the CVE Program's own records, rebuilt every day on our CVE publication trends page. As of the snapshot taken Nov 12, 2026 UTC:

• 47,801 records were published in 2025, 20% more than the year before.
• 95,494 records have been published in 2026 so far, 303 a day, +131% on 2025's daily rate.
• 155 a day are rated High or Critical.
• 17% of all records since 2020 carry no CVSS score, from the assigner or from CISA's enrichment. Coverage has improved: in 2026 the share is 6%.
• 505 organizations assigned these records, and the 20 largest account for 75% of them.

• High or Critical
• Other severities and unscored

1. 39 2020
2. 54 2021
3. 68 2022
4. 78 2023
5. 109 2024
6. 131 2025
7. 303 2026*

Daily average of records published in each year; * marks the current year to date. Source: the CVE Program's cvelistV5 records, snapshot Nov 12, 2026 UTC. Filters by month, severity and assigner: CVE publication trends.

This is not a bad quarter. The count has risen every year since 2020, and several structural changes keep it rising:

• More assigners, assigning more broadly. The Linux kernel project became a CVE Numbering Authority in February 2024. Its documented policy is to assign a CVE to any bug fix that might be a vulnerability once the fix reaches a stable kernel, because exploitability is often not clear when a fix lands. The kernel CNA alone has published 18,221 records since.
• AI-assisted discovery. In November 2024 Google's Project Zero and DeepMind reported that their Big Sleep agent had found an exploitable memory-safety bug in SQLite before it reached a release, which they believe was the first public example of an AI agent doing so in widely used software. Tools like it raise how much one researcher can find.
• The NVD can no longer enrich everything. NIST says the National Vulnerability Database built up a backlog of unenriched CVEs from early 2024 and could not clear it as submissions kept rising. In April 2026 it moved to a risk-based model: CVEs in CISA's Known Exploited Vulnerabilities catalog and CVEs in federal or critical software are enriched first, and the rest are listed as not scheduled for immediate enrichment. A process that relies on one database's affected-product data now waits, or misses.
• Less time to respond. Mandiant measured an average time to exploit of 63 days in 2018 and 2019. Its M-Trends 2026 report estimates minus seven days for 2025: exploitation now routinely starts before a patch is released.
• Regulatory clocks. Under the EU Cyber Resilience Act, manufacturers report an actively exploited vulnerability with an early warning within 24 hours, a notification within 72 hours and a final report within 14 days of a fix being available (what the CRA requires). The clock is the same for a team of three as for a team of three hundred.

None of this means software is getting less secure. It means the number of things a team has to look at grows every year, while the team does not.

What breaks in a small team's process

Rising counts do not break vulnerability management because there are more vulnerabilities to fix. They break it because every manual step repeats for every CVE.

Manual step	Why it fails at today's volume
Building the inventory by hand	A spreadsheet, or an SBOM made before an audit, is stale the day after the next release.
Reading the feed	At 155 High or Critical records a day, no one keeps up.
Asking engineering "do we use X?"	The same question for every CVE, to the same busy people. The question is the bottleneck.
One ticket per CVE per repository	A shared library's CVE becomes dozens of duplicate tickets that swamp the backlog.
Answering every customer one by one	Inquiries grow with the customer base, not with the number of vulnerabilities.
Documents in PDF or a wiki	Customers' tools cannot match a PDF against their inventory, so every reader asks again.
Deadlines that do not move	Time to exploit shrinks while a manual process gets slower as the volume grows.

The inventory. Most teams that keep a component list by hand update it before an audit or a customer questionnaire. Between those dates it describes software that no longer ships. Every CVE question then starts with rebuilding what the release contained.

The feed. Reading advisories is the step teams start with, and the first to collapse. We hear from teams that still do it by hand, including one where vulnerability scanning means people reading CVE forums. It works until the day it does not, and there is no signal for that day.

The question to engineering. "Do we use this library, and which version?" interrupts a developer for every CVE that might apply. One two-person product security team told us its work is button pushing just to keep up, with no time left to improve the process.

The tickets. When a shared library has a CVE and every repository opens its own ticket, the backlog counts the same decision many times. Teams learn to ignore the backlog, and then miss the ticket that mattered.

The customer answers. After a widely reported vulnerability or supply chain attack, customers ask "are we affected?". Answering each one separately costs the most time on the day there is least of it.

The documents. A PDF statement or a wiki page has to be read by a person on the customer's side. Customers' scanners, and increasingly regulators, expect SBOMs, VEX and advisories in formats a machine can match.

The deadlines. An early warning due within 24 hours, or an exploit that appears before the patch, does not wait for the queue to clear.

What to automate, in order

Each step removes work from the next one, so the order matters more than the choice of tools.

1. Know what you ship. An SBOM from every build turns "are we affected?" into a lookup.
2. Match continuously, against more than one source. New CVEs are checked against every stored SBOM, so nobody reads the feed.
3. Cut the noise. Findings for things you do not ship, and duplicates, never reach a person.
4. Triage semi-automatically. The facts are filled in; a person makes the decision.
5. Make everything machine-readable. Each decision is made once and reused by every reader.
6. Answer once, publicly. The inquiry that never arrives costs nothing.

1. Generate an SBOM for every build, automatically

What it replaces: the spreadsheet, and the question to engineering. An SBOM generated at build time describes what the build actually used, and keeping one per shipped version means you can answer for last year's release as well as for main. Customers run old versions; your inventory has to cover them.

Minimum version: an SBOM generated in CI for every release build, stored next to the release artifact. Better: an SBOM recorded from the build itself rather than inferred from lockfiles afterward, so components fetched outside the package manager are in it too (build-time SBOMs, SBOM automation).

Cost: a day or two of pipeline work for the minimum version, then nothing per release. Signal that it works: for any release, you can list its components without asking anyone.

2. Match continuously against several vulnerability sources

What it replaces: reading the feed. Matching is a machine's job: every new CVE against every stored SBOM, not only the SBOM of the build that just ran. An old release that was clean when it shipped is affected the day a CVE is published for one of its components.

One source is not enough. The NVD's enrichment backlog means affected-product data can arrive late or not at all. Ecosystem advisories such as the GitHub Advisory Database and OSV are often faster and say which package versions are affected in the ecosystem's own terms. ENISA's EU Vulnerability Database adds EU context.

Minimum version: a scheduled job that re-scans every stored SBOM daily against an aggregated source and reports new matches. Signal that it works: you learn a release is affected before a customer tells you. See vulnerability tracking for what this looks like in CRACI.

3. Cut the noise before anyone looks

What it replaces: manual review of findings that do not matter. Most noise is made upstream: by inventories that list things you do not ship, by several tools reporting the same CVE, and by dependencies nobody needs. Fix the inventory, count each finding once by package URL (PURL), version and CVE, ship fewer dependencies, then add exploitability context from CISA KEV, EPSS and VEX. How to reduce vulnerability noise takes these levers one by one. Signal that it works: findings per shipped release fall, and the reasons are on record.

4. Triage semi-automatically

What it replaces: a person gathering the facts for each finding. Split the work precisely:

• Automatic: severity, whether it is known to be exploited, which products and versions contain the component, the owning team, a proposed priority and a due date.
• Human: the decision. Fix, mitigate, accept with an expiry date, or mark not affected with a justification.

What is not safe to automate: closing a finding as not affected without a recorded reason. That is suppression, and it comes back in an audit or an incident. Ranking rules are covered in vulnerability prioritization.

Minimum version: 15 minutes a day over a queue that is already sorted and filled in. Signal that it works: every decision has a recorded reason, and nothing waits for someone to look something up.

5. Make everything machine-readable

What it replaces: PDFs, wiki pages and emails that a person has to read. Publish SBOMs in CycloneDX or SPDX (CycloneDX vs SPDX), not-affected decisions as VEX, and advisories in CSAF. Customers' scanners and regulators can then consume them without a human, so each decision is made once and reused by everyone who asks.

Minimum version for a small team: SBOMs and VEX on request, from a stable location; CSAF when customers start asking for it. Signal that it works: customers' tools stop flagging what you already answered.

6. Answer once, publicly

What it replaces: one email thread per customer. Publish an advisory or status page for each significant CVE, with the affected and fixed versions, and keep a reply template that links to it. The guide to answering "are we affected by this CVE?" shows how to work out the answer, and how to answer customers after a supply chain attack has reply templates. The cheapest inquiry is the one that never arrives. Signal that it works: most inquiries are answered with a link.

Then fix

Automated dependency update pull requests keep the routine work moving; batch them by week or by release so review stays manageable. Upgrading one upstream package often clears several vulnerable transitive dependencies at once, and is cheaper than patching each one (automated vulnerability remediation). Then stop new known-bad components from coming back with policy gates that block the build.

A plan by team size

The hours are illustrative estimates for planning, not benchmarks.

	One person, part-time	A 2 to 5 person security or PSIRT function	A larger team
Automate first	Steps 1 and 2: an SBOM per build and continuous matching	Steps 1 to 3, then routing to owners in step 4	All six, with policy gates in every pipeline
Stays manual	The decision on each High or Critical finding; customer replies from a template	Decisions, VEX justifications, advisories for significant CVEs	Decisions, exceptions and the process itself
Weekly time, illustrative	2 to 4 hours	4 to 8 hours per person	Set by the decision volume, not by the feed

If you already run a PSIRT, the same order applies; the full process model is in the vulnerability management lifecycle, and scaling a PSIRT covers the customer inquiries that multiply with every CVE.

How to know it's working

• Time from CVE publication to "affected" or "not affected", per product.
• The share of customer inquiries answered from published material.
• Findings per shipped release, not per scan.
• The share of decisions with a recorded reason.
• Hours per week spent on vulnerability work, and whether it is falling.

Measure your own baseline first. There are no reliable industry benchmarks for these, and we do not quote any.

Hire, buy or change the process?

• Hire when the work is fixing vulnerabilities in your own code, or customer-facing security work that needs judgment.
• Buy tooling for the steps that repeat per CVE: steps 1, 2, 3 and 5.
• Change the process for ownership and deadlines: who decides, and by when.

Be honest about the last one. A tool without an owner produces a dashboard nobody reads.

Where CRACI fits

CRACI automates steps 1 and 2, and parts of steps 3 and 4, for software built in GitHub Actions. It replaces your GitHub-hosted runners, and as each job runs it records the packages the job actually pulled in, including packages restored from CI caches and hidden dependencies that no lockfile lists.

• An SBOM from every build. Each job's SBOM identifies every component by PURL and carries a completeness state, so you know when something could not be seen. Build history keeps every past build with its SBOM, so you can see which builds contained a vulnerable dependency, direct or transitive.
• Continuous matching. Monitored SBOMs are re-evaluated continuously, and findings are aggregated across builds and repositories, so a shared library's CVE shows up as one problem, not forty.
• Notifications and gates. CRACI notifies the relevant people of a vulnerability and its severity, and policy gates can stop a build in real time, including a build that contains a specific CVE.
• Triage and routing. Security teams triage findings in CRACI and route each one to the team that owns the fix.
• Machine-readable SBOMs. SBOMs export as CycloneDX or SPDX, and CRACI supports VEX.

CRACI does not publish advisories, does not offer reachability analysis and does not scan your own code. It charges only for build minutes: $0.002 per vCPU-minute ($0.004 for a default 2 vCPU runner), metered per second, with no monthly fee, no per-SBOM charge and no license fee right now. See pricing.

Automate the first two steps today: run your builds on CRACI. We're onboarding every team personally before general availability.

When CRACI is not the answer

• Your software is not built in GitHub Actions. GitLab CI and Jenkins are on the roadmap.
• Your exposure is mainly infrastructure: servers, endpoints and cloud configuration. Infrastructure vulnerability management tools fit better.
• You integrate third-party firmware you do not build. Binary analysis tools fit better.
• Your backlog is mostly true, exploitable findings in your own code. That is a remediation capacity problem, not an automation problem.

Vulnerability management automation: frequently asked questions

Why are there so many more CVEs now?

More organizations assign CVEs, and some assign them broadly: the Linux kernel became a CVE Numbering Authority in 2024 and assigns one to any bug fix that might be a vulnerability. AI-assisted tools find more bugs per researcher. 47,801 records were published in 2025, and 2026 is running at 303 a day. The trend has run for years.

How can a small team keep up with new CVEs?

By not reading them. Generate an SBOM for every build, match new CVEs against every stored SBOM automatically, cut the noise, and let people make only the decisions on what is left. A small team keeps up by removing the steps that repeat for every CVE, not by working faster.

What should we automate first in vulnerability management?

The inventory: an SBOM generated in CI for every release build, stored with the release. Every later step depends on it, and it turns "are we affected?" from a question to engineering into a lookup. Continuous matching against those SBOMs comes second.

Do we need a security team to handle vulnerabilities?

Not to start. One person who owns the process part-time can run it if the inventory, the matching and the noise reduction are automated. You need a named owner and deadlines more than a team. Hire when the work becomes fixing your own code or customer-facing security work.

How do we know which new CVEs affect our product?

Keep an SBOM for every shipped version and re-check all of them whenever new CVEs are published, against more than one vulnerability source. A CVE affects you when it matches a component and version you actually ship. Exploitability context and VEX then say whether it matters.

What does "machine-readable" mean for SBOMs, VEX and advisories, and why does it matter?

It means a standard structured format a tool can parse: CycloneDX or SPDX for SBOMs, VEX for not-affected statements, CSAF for advisories. A customer's scanner can match them against its inventory without anyone reading them, so a decision you make once is reused by every customer and tool.

How much of triage can be automated safely?

Gathering the facts: severity, exploited status, which products and versions contain the component, the owner, a proposed priority and a due date. The decision itself should stay with a person. Never close a finding as not affected automatically without a recorded reason.

How long do we have to respond to a critical CVE?

Less than most processes assume. Mandiant's M-Trends 2026 estimates the average time to exploit in 2025 at minus seven days, meaning exploitation before a patch exists. Under the EU Cyber Resilience Act, an actively exploited vulnerability needs an early warning within 24 hours. Set your own deadline by severity and exploitation, and measure against it.