You cannot hire your way out of a rising inquiry volume, and you cannot triage faster forever. A PSIRT scales by answering most "am I affected?" questions from data it recorded when each version was built, and by publishing the answer before customers ask. The expensive step today is asking engineering what is in a product. Move that step to build time, and most inquiries become lookups that support can close.
This post assumes you already run a PSIRT; if you are setting one up, start with what a PSIRT is and how to build one. Below: why the volume changed, where the time goes in the usual pipeline, and what to change, in order.
Why the volume changed
The increase is structural, not a bad quarter. Four things are pushing on the same queue at once.
More CVEs. The CVE Program published 39,718 CVE records in 2024 and 47,801 in 2025. In 2026 the count passed 2025's full-year total well before the year was out; our live CVE publication trends track it day by day. FIRST's 2026 vulnerability forecast update (15 June 2026) raised its estimate for the year to about 66,000 CVEs and put the cause plainly: AI can find significantly more flaws than human analysts, and "the constraint is no longer discovery; it is the human capacity to verify, coordinate, and patch". A PSIRT is that human capacity.
Customers scan your product. Customers run scanners against your images, firmware and appliances and forward every finding as a ticket. Most of those findings are scanner noise about components you do not ship or versions that are not affected, and the noise becomes your intake. Reducing vulnerability noise covers the scanner side.
Regulation adds clocks. Since 11 September 2026, the reporting obligations of the EU Cyber Resilience Act apply. An actively exploited vulnerability in a product sold in the EU needs an early warning within 24 hours of the manufacturer becoming aware of it.
Less help from the NVD. On 15 April 2026 NIST moved the National Vulnerability Database to risk-based enrichment: CVEs in CISA's KEV catalog, software used by the federal government and EO 14028 critical software come first, and the rest are marked "Lowest Priority - not scheduled for immediate enrichment". Fewer CVEs arrive with CPE data, so matching by product name gets worse just as the volume rises.
| Driver | What it does to the PSIRT's queue |
|---|---|
| CVE volume, AI-assisted discovery | More third-party CVEs to assess per product, every month |
| Customer scanning | More inquiries per CVE, many about components you do not ship |
| CRA reporting | A 24-hour clock on actively exploited vulnerabilities |
| Less NVD enrichment | More manual work to map a CVE to the products it affects |
Where the time goes: the inquiry pipeline as it usually runs
We hear the same pipeline from product security teams again and again. A two-person PSIRT at a hardware vendor described it to us like this: a customer asks the support desk, support routes the question to the PSIRT through the CRM, the case lands in the PSIRT's tracker, the PSIRT investigates the products customers ask about most, then hands the question to engineering and waits.
Take one illustrative inquiry. A customer forwards a scanner report that lists 40 CVEs against firmware version X. Support opens a case and attaches the report, but not the exact build the customer runs. The PSIRT checks which of the 40 it has already assessed, finds a dozen it has not, and asks the owning engineering team whether the components are in version X. Engineering has to find the source for version X, work out which dependency versions went into it, and reply. The numbers are made up; the shape is not.
The analysis itself is rarely what takes the time. Two hidden costs are:
- The same CVE is investigated again for every customer who asks. When the answer lives in an email thread, the next customer starts the investigation over.
- "Most-asked products first" leaves the long tail unanswered. Older products still in the field never get checked, and that is often where the risk is: older components, fewer updates, fewer people who remember how they were built.
Intake: separate questions from reports
A researcher's vulnerability report and a customer's "am I affected?" are different work, and they need different paths. The FIRST PSIRT Services Framework already expects messy input: a PSIRT should "expect to receive vulnerabilities through various channels and of variable quality" (sub-function 2.1.1.1). Its triage service area goes further: "Where organizations receive a high volume of vulnerability reports, they may consider performing initial triage to validate reports before cases are created." Take that as permission not to open a PSIRT case for every inquiry.
Split inquiries at the support desk into three paths:
| The customer asks about | Path | Who answers |
|---|---|---|
| A published CVE in a third-party component you have already assessed | Answer from the published VEX statement or advisory; no PSIRT case | Support |
| A published CVE you have not assessed yet | One PSIRT case per CVE, not per customer; link every inquiry to it | PSIRT, then support replies to everyone linked |
| A new vulnerability in your own code | A vulnerability report: the full coordinated vulnerability disclosure process | PSIRT |
Support needs two things to work the first path: a searchable list of assessed CVEs per product and version, and reply templates. How to answer customers after a supply chain attack has templates you can adapt.
Capture the product and the exact version the customer runs at intake. Without the version, every answer is "it depends", and the case comes back.
Prioritize by exposure, not only popularity
"Most-asked products first" is a reasonable heuristic. It needs a second axis. Keep popularity (install base, revenue, how often support asks) and add exposure: is the product still supported, is it internet-facing in typical deployments, and is the CVE in CISA's KEV catalog or high on EPSS? The vulnerability prioritization guide covers the signals in depth.
| Low exposure | High exposure | |
|---|---|---|
| High install base | Answer from the inventory; publish VEX for not-affected versions | Investigate first; advisory and fix on the shortest deadline |
| Low install base | Answer from the inventory on request; no proactive work | Do not skip it: answer from the inventory, then decide on a fix or a mitigation notice |
The point of the matrix is the left column and the bottom row. The long tail gets an answer from data, not from an investigation nobody has time for.
Under the CRA, the support period you declared for each product decides which older products you still owe answers and security updates for (what the CRA requires).
The engineering hand-off is the bottleneck
This section is for the engineering lead who receives the PSIRT's escalations.
PSIRT deadlines are public: a customer, a regulator or a disclosure date is waiting. Engineering's deadlines usually are not, so the PSIRT absorbs the gap. A critical issue handed over on a Monday with no reply by Tuesday leaves two days before the public answer is due.
The PSIRT sends engineering two different questions, and only one of them should need engineering:
- "Is the component in the product?" is a data question. It should be answered from a record, not by a person reading build files.
- "Can you fix it by date X?" is a work question. That one belongs to engineering.
The FIRST framework says how to take the first question off engineering's desk. Function 2.3.5 asks PSIRTs to "establish automated channels to distribute identified third-party vulnerability notifications directly to the development teams of affected products", so that third-party advisories are processed in the development process and the PSIRT handles fewer of them by hand.
Agree three things with engineering:
- An owner per product. In large vendors remediation is spread across product teams; the framework's distributed model exists because it lets the PSIRT mission scale through the engineers who own the products.
- Response targets per severity, written down, for the fix rather than for the investigation.
- What happens when a target is missed. Function 4.2.4 asks for "a process for formal risk acceptance for any vulnerabilities not remediated within the internal SLAs time requirements". Somebody with authority signs the risk; it does not just sit open.
Fix cadence varies. One team ships an overnight patch, another needs a six-month platform upgrade. The advisory has to say which, so customers can plan.
Turn "are we affected?" into a lookup: an SBOM for every shipped version
This is the change that removes the most work. FIRST function 2.3.1, the inventory of product components, calls it "essential to quickly identify affected products for inherited vulnerabilities". The PSIRT maturity levels put a product registry with dependency mapping at the intermediate level and monitoring of product component vulnerabilities at the advanced one.
An inventory only removes work if it holds up under volume. Each requirement below is there for a reason:
- One SBOM per shipped version, not per repository and not of the default branch. Customers run versions, not branches.
- Taken from the build that produced the release. A rebuild later, or a scan of today's repository, describes different software (build-time SBOMs).
- Transitive and hidden dependencies included. The vulnerable package is rarely one you added yourself (transitive dependencies), and install scripts, base images and restored caches bring in components no lockfile lists.
- A completeness signal. A partial record treated as a full one produces confident "not affected" answers that are wrong.
- Kept for as long as the version is supported. The record for a version from three years ago is the one you will need when nobody remembers how it was built.
- Vendor SBOMs for bought-in components, so third-party software is in the same inventory as your own.
- Re-matched continuously as new CVEs are published, instead of rescanned when someone asks.
A worked example. A new CVE is published in a widely used compression library. Without the inventory, the PSIRT asks every product team, answers trickle in over days, and the oldest products are never checked. With it, one query returns the affected products and versions, plus the first and last builds that contained the vulnerable version. That is the exposure window customers ask about next; are we affected by a CVE? shows how to establish it for a single case.
Embedded and Yocto portfolios have it hardest. Scanners that read a finished firmware image have to guess what was compiled into it, and teams we talk to have had scanner proofs of concept fail on Yocto-based products. Recording the build as it runs avoids the guessing (Yocto builds on CRACI).
When a customer then asks for the SBOM itself, in a particular format, see answering customer SBOM requests.
The output side: advisories and VEX that answer before anyone asks
The cheapest inquiry is the one that never arrives.
- Publish "not affected" as VEX, so customers' scanners stop flagging the CVE, and publish "affected" and "fixed" as advisories with exact versions.
- Make it machine-readable. FIRST sub-function 5.3.2.3 suggests PSIRTs "consider publishing advisories in a machine-readable format such as the Common Security Advisory Framework (CSAF)", so customers can consume them with their own tools. The CSAF guide covers how to move from web pages and RSS feeds to CSAF.
- Brief support before you publish. Function 5.3.4: "Providing advanced, confidential notification and FAQ for coming advisories prepares those who may be asked about them upon publishing." Support can then answer on the day.
- Push, do not just post. Sub-function 5.4.1.3 notes that low page views on advisories "may drive your strategy to go towards proactive notification". Feeds and notifications reach customers who never visit an advisory page.
The CRA makes part of this a duty. Article 14(8) requires the manufacturer, after becoming aware of an actively exploited vulnerability or a severe incident, to inform the impacted users "and where appropriate all users", and to do so "where appropriate in a structured, machine-readable format that is easily automatically processable". The regulation does not name a format.
What to automate, in order
Each step removes a kind of work; the metric shows whether it did.
| Step | Work it removes | Metric that shows it worked |
|---|---|---|
| 1. A per-version inventory from the build | The "what is in it?" question to engineering | Engineering investigation requests per month falls |
| 2. Continuous matching of new CVEs to every supported version | Rescanning on request | Time from CVE publication to an affected or not-affected decision |
| 3. One case per CVE, with inquiries linked | Duplicate investigations | Inquiries per case rises, cases per CVE stays at one |
| 4. Automated routing of affected findings to the owning team (FIRST 2.3.5) | Manual hand-offs | Time from decision to an owner acknowledging it |
| 5. A searchable library of published VEX statements and advisories | PSIRT involvement in repeat questions | Share of inquiries closed by support |
| 6. Machine-readable publishing (CSAF) | Customers asking for what their tools could have fetched | Inquiries per published advisory falls |
| 7. AI assistance for drafting advisories and replies | Writing time | Time from decision to published advisory |
AI comes last for a reason. It drafts well on top of recorded data, and it should never be the source of the "affected" decision.
Some things should not be automated: the "not affected" judgement and the severity call stay with a person, with the evidence attached. Automation decides how fast that person gets the evidence.
Metrics that show the PSIRT is scaling
- The share of inquiries answered without a PSIRT case.
- Time from CVE publication to an affected or not-affected decision, per product.
- Engineering investigation requests per month. It should fall.
- On-time remediation rate by severity; the framework's sub-function 4.4.2.4 defines it as how well product teams meet the agreed time from report to fix.
- VEX and advisory coverage of the versions you still support.
We do not quote industry benchmarks for these. No primary source we trust publishes one.
Where CRACI fits
CRACI covers steps 1 and 2, and parts of steps 4 and 5, for software built in GitHub Actions. Your builds run on CRACI's runners, and CRACI records what each job actually pulled in as it ran: direct and transitive dependencies, packages installed by scripts and packages restored from CI caches. Each job's SBOM carries a completeness state, so a partial record is never mistaken for a full one.
CRACI keeps the build history, so when a new CVE is published you see which builds contained the vulnerable dependency, and since when, as far back as your retention goes. Monitored SBOMs are re-evaluated continuously, findings are aggregated across builds and repositories, and vendor SBOMs can be added so bought-in components are monitored alongside your own builds. CRACI notifies the relevant people of a new vulnerability and its severity. The inventory view shows which software versions are deployed to which products, and security teams triage each finding in CRACI and route it to the team that owns the fix. CRACI supports VEX. See CRACI for PSIRTs and vulnerability tracking.
See which of your shipped versions contain a CVE.
When CRACI is not the answer
- Your bottleneck is intake and case management, the CRM-to-tracker part. CRACI is not a case management or advisory publishing tool; you need a case tool for that half (PSIRT tools compared).
- Your products are not built in GitHub Actions on Linux runners. GitHub Actions is the supported CI today; GitLab CI and Jenkins are on the roadmap, with no date.
- You need binary or firmware analysis of products you did not build yourself. That is what output analysis tools do (embedded security tools compared).
- You need reachability analysis to argue "not affected". CRACI does not offer it.
Frequently asked questions
How do you scale a PSIRT without hiring?
Stop investigating the same question repeatedly. Record what every shipped version contains when it is built, match new CVEs against it continuously, decide once per CVE, and publish the decision as VEX or an advisory that support can point to. The PSIRT then works the genuinely open cases, and engineering is asked to fix, not to investigate.
How should a PSIRT handle customer "are we affected?" inquiries?
Treat them as a separate intake stream from vulnerability reports. Support answers questions about CVEs you have already assessed from published material. A CVE you have not assessed yet gets one PSIRT case, with every customer inquiry linked to it. Only a new vulnerability in your own code goes through the full disclosure process.
What does the FIRST PSIRT Services Framework say about volume and automation?
It expects reports "through various channels and of variable quality", allows triage before cases are created when volume is high, calls an inventory of product components "essential to quickly identify affected products", and asks for automated channels that send third-party vulnerability notifications straight to the development teams of affected products (function 2.3.5).
What should a PSIRT automate first?
The per-version inventory taken from the build, then continuous matching of new CVEs against every supported version. Those two remove the most repeated work: the "what is in it?" question to engineering and the rescan on request. Case deduplication, routing, a searchable VEX and advisory library, and CSAF publishing come after.
How do you get engineering to answer PSIRT questions on time?
Ask engineering fewer questions. Answer "is the component in the product?" from the build record, and send engineering only "can you fix it by this date?". Agree an owner per product, response targets per severity for the fix, and a formal risk acceptance when a target is missed.
Why does an SBOM per release matter for a PSIRT?
Customers run specific versions, often old ones. An SBOM of the default branch says nothing about version X from two years ago. One SBOM per shipped version, recorded from the build that produced it and kept for the support period, is what lets a PSIRT answer for every version still in the field, including the exposure window.
Do customers want VEX or advisories?
Both, for different statuses. VEX tells customers' scanners which CVEs do not affect a product, so the findings stop. Advisories tell people what is affected, what is fixed and what to do. Publishing both, machine-readable where you can, answers most questions before they are asked.
