CVE Triage Process for Compliance Teams Without Developer Access

Why suppression-as-triage fails the audit test

CVE volume crossed 29,000 in 2023, then 34,000 in 2024, and 2025 is on pace for somewhere between 45,000 and 50,000. No compliance team reads that many advisories by hand. The staffing math doesn't hold up either: a ratio of three security engineers to 250 developers has been documented at real organizations, and that ratio only survives if triage runs mostly on autopilot. What follows is a process built for compliance teams that don't have a ticket queue into engineering, don't have build system access, and can't walk over and ask a developer what's actually running in production.

The pressure keeps building from both directions. AI-assisted development has pushed shipping speed to somewhere between four and eight times what it was two years ago, while remediation windows have gone the other way: one day for critical findings, eight for high, thirty for medium. Vulnerability management now costs the average organization a substantial sum each year in direct remediation, and the drag, the lost velocity and rework, can run several times that figure annually. Developers report losing nearly a fifth of their working hours to security tasks. None of that holds together without a process that doesn't depend on developer time to run.

Faced with a backlog that keeps outrunning the team assigned to it, most organizations do the obvious thing: they suppress. Bulk-close the lows and mediums, accept risk on anything transitive, write one blanket exception for a whole scanner category or severity tier. That's the wrong move, and it's wrong in a specific, provable way. It collapses the moment an auditor asks for the reasoning behind a single dismissal, because there isn't any reasoning on record, just a bulk action applied to a bucket. Volume was never the enemy here. The absence of a documented decision is, and suppression manufactures that absence at scale.

Regulators no longer accept "we suppressed it" as an answer. They want the logic behind the dismissal, in writing, with evidence attached. One documented case at a major US financial services firm, operating under federal regulatory oversight, put the scale of the problem in stark terms: over 400 alerts per vulnerability once multiple scanning tools stack on top of each other. Every one of those results has to be triaged before it gets dismissed. Regulators require this as a matter of regulation.

Europe's version of this reckoning runs through the Cyber Resilience Act, which turns an uninvestigated backlog into a direct compliance liability instead of a housekeeping problem. A large European industrial conglomerate cut its vulnerability count by 62%, down from 53 million findings, and still only triaged 3% of what remained. Under CRA scrutiny, that posture fails. Cutting the pile in half means nothing if almost none of what's left has actually been looked at, and regulators are starting to say so directly.

"We suppressed it" "We suppressed it" describes an action. An auditor wants a documented chain for every finding that wasn't actively remediated, including intake, a relevance assessment, the reasoning behind the priority assigned, the disposition, and a sign-off. Building that chain requires trustworthy intake data in the first place, and that got a lot harder in April 2026.

NIST's April 2026 NVD restructuring and its effect on compliance team triage assumptions

On April 15, 2026, the standards agency formally moved its national vulnerability database to a risk-based triage model. The trigger, according to a Cloud Security Alliance AI Safety Initiative research note published April 19, 2026, was a 263% jump in CVE submissions between 2020 and 2025. Full enrichment, meaning CPE identifiers, CVSS scores, CWE classifications, now only happens for CVEs in the CISA KEV catalog, federal government software, and the critical software categories defined under EO 14028: an estimated 15% to 20% of projected CVE volume. The remaining 80% ships without CPE data, without a CVSS score, without a CWE tag.

Around 29,000 CVEs published before March 1, 2026 got swept into a "Not Scheduled" bucket, and they get no enrichment at all unless someone explicitly requests it. NIST will also stop generating its own CVSS score whenever the CNA that originated the CVE already supplied one, which quietly introduces scoring variance that most governance documentation won't catch.

None of this is new so much as an old crack splitting wider. VulnCheck's analysis of 2024 CVE data found NVD supplied CPE identifiers for only 41.35% of published vulnerabilities, against roughly 76.95% for VulnCheck's own enrichment pipeline over the same period. The April 2026 policy widens that gap instead of closing it. The real danger sits in what the gap hides: a CVE with no CPE data is invisible to most scanners, because the scanner reports nothing for the affected component, and neither the scanner nor the analyst gets any signal that something was missed. Call it a blank spot rather than a false negative. Nobody even knows to go check it.

Scoring gets messier too. VulnCheck found disagreement between NVD and CNA scores in more than roughly half of cases scored by both. A compliance team defaulting to CNA scores for that unenriched 80% is inheriting scoring variance it probably hasn't disclosed anywhere in its audit trail. That lands hardest on frameworks like FedRAMP, whose legacy continuous monitoring requirements reference NVD-sourced CVSSv3 scores for remediation timelines. Current guidance under RFC-0012 calls for contextual adjustment beyond the raw score, but plenty of documentation still cites "the NVD CVSS score" as though that phrase describes something universal. It now describes a data source that touches a small slice of new CVEs, and treating it as anything more is a mistake that becomes visible first in an audit.

Treating NVD as the single source of truth stopped being viable the day this policy took effect. Assembling a stack of sources, and doing it correctly, is the actual job now.

Building a multi-source signal stack: what compliance teams can query without developer access

Start with a widely used catalog of vulnerabilities confirmed under active exploitation. It's the most reliable free signal available for CVEs under active attack, published as machine-readable JSON at cisa.gov. A simple automated diff of the weekly file against the prior week's version, dropped into a shared channel, catches every new addition, and setting that up is straightforward by most practitioner accounts. Tenable, Qualys, and Rapid7 all run independent enrichment pipelines that surface KEV data, so a compliance team pulls this signal without asking engineering for anything. The catalog runs past 1,100 entries now. KEV status is a first cut, but it's the one signal that says this is being used against someone right now, not theoretically exploitable, actually weaponized.

Speed matters here in a way that's easy to state and hard to overstate. CVE-2026-63077, a CVSS 9.8 unauthenticated remote code execution flaw in JetBrains TeamCity On-Premises tied to CWE-502, landed on the KEV list on August 5, 2026, with a federal remediation deadline of August 8. Three days. A team that spots a KEV addition the day it posts is operating in a different world than a team that finds out during its next sprint review. That gap is the whole argument for automating the diff instead of checking the list by hand once a week.

CISA's Authorized Data Publisher program fills part of the gap NVD left behind. A CSA research note finds that it publishes Stakeholder-Specific Vulnerability Categorization decisions on most non-priority CVEs within days of release, and validates CVSS scores for federal-priority software. That gives compliance teams an auditable substitute for enrichment NVD no longer provides.

EPSS version 4, released in early 2025, adds a different kind of signal: a daily probability estimate of exploitation for essentially every CVE with a published identifier, including ones NVD never enriched. It draws on CNA data plus public exploit and proof-of-concept activity. The FIRST EPSS Special Interest Group maintains the model, and Empirical Security generates and publishes the scores. It's queryable without touching developer tooling, and it pairs cleanly with KEV: KEV confirms exploitation happened, while EPSS estimates the odds for everything that hasn't been confirmed yet.

Scanner vendors are part of the stack now, not just the pipe that delivers it. A CSA research note finds that Tenable, Qualys, Rapid7, and Wiz each run independent enrichment pipelines and vendor-advisory feeds that surface vulnerabilities NVD's CPE data never touches. Compliance teams should know exactly which supplemental sources their scanning platform draws from, and that list belongs in the governance documentation. The audit conversation has already moved past "what does NVD say" toward "what does your enrichment posture actually cover."

CISA's Binding Operational Directive 26-04, issued June 10, 2026, layers on top of all this. It throws out flat deadlines tied to KEV listing or to a standard severity score in favor of a four-variable model: is the asset exposed to the public internet, is the CVE listed in KEV, can exploitation be automated, and does successful exploitation yield total system control. Federal agencies are bound to it, but nothing stops a compliance team anywhere from adopting the same four variables as a scoring rubric. It's a regulator-built framework, which makes it defensible in front of an auditor in a way an internally invented scoring system never quite is.

What SBOMs and VEX records provide beyond scanner output

CISA, the NSA, and partner agencies across 14 countries released the joint 2026 Minimum Elements for a Software Bill of Materials, replacing NTIA's 2021 version. CISA and NSA, in collaboration with 19 international cybersecurity organizations, also released joint guidance on a shared global vision for SBOM in cybersecurity. SBOM adoption stopped being optional practice sometime in 2026. It's baseline now, the way a CVSS score used to be.

An SBOM gives a compliance team something scanner output can't: a static answer to which components, at which versions, are in which artifact, without ever asking a developer. During an event like the Log4j disclosure, having that record on hand means finding exposure in minutes instead of crawling manually through builds and container images.

Most SBOMs generated today are snapshots, taken at the end of a build, filed away, and never opened again. That's the deeper problem. A library that was clean when the build ran can carry a zero-day disclosed the following week, because transitive dependencies shift underneath a project without anyone noticing, and no one is alerted when that shift happens. An SBOM is only as useful as the workflow built around actually consulting it, and a filed-away snapshot from six months ago is worse than no SBOM at all, because it creates false confidence instead of an honest gap.

Three formats matter here. CycloneDX, an OWASP project, hit version 1.7 in October 2025 and became ECMA-424 2nd Edition that December. SPDX, out of the Linux Foundation, is at version 3.0.1, and the 3.0 release added a security profile that covers vulnerability and VEX data directly. Package URL, or PURL, became ECMA-427 in December 2025, giving compliance teams a stable, cross-format identifier for matching SBOM components against CVE advisories.

VEX, the Vulnerability Exploitability eXchange, is where SBOM data turns into an actual triage decision, and most teams underuse it badly. A VEX record lets a software producer state whether a given CVE affects their product as deployed, not whether the vulnerable code exists somewhere in a dependency tree, but whether that code path is even reachable in the way the product runs in practice. For a compliance team with no developer access, a VEX assertion from the vendor or product team becomes a documented, auditable basis for marking something "not affected." The burden of figuring out relevance moves upstream, to whoever sits closest to the code, which is exactly where that judgment belongs.

At the July 2025 S3C2 Secure Software Supply Chain Government Summit, practitioners from six US government agencies discussed SBOM, VEX, and compliance as one connected topic, and a recurring frustration surfaced: teams didn't know how to push this work forward without a mandate forcing the issue. The 2026 CISA guidance is that mandate now.

The input-derived hash deserves more attention than it usually gets. When environments build reproducibly and every build carries a hash derived from its inputs, a compliance team traces any deployed artifact back to its exact dependency set without asking anyone in engineering. A new CVE disclosure becomes a yes-or-no question answerable straight from the artifact record: does this hash include the affected component at the affected version? Hash-level blocking or patching follows directly, turning a CVE response into an artifact-level operation instead of a developer escalation. Deterministic SBOMs, generated from declarative environment manifests, carry the same trait. The manifest itself is the audit record, every dependency pinned, every version traceable back to its source.

The step-by-step triage workflow compliance teams can run on their own

Step 1: Intake and initial scoring. A CVE arrives, whether from scanner output, a vendor advisory, a KEV update, or an NVD feed. Record the identifier, the source, the date received, and whatever raw severity signal is attached: CVSS from the CNA or NVD if either exists, an EPSS score, KEV status. Flag it immediately if it's KEV-listed, since under BOD 26-04's model, KEV status combined with the other qualifying factors can compress a remediation deadline down to three days. Note the NVD enrichment status too. If the CVE has no CPE or CVSS data, write down which supplemental source supplied the severity signal instead, because that's a disclosure an auditor will now expect to see.

Step 2: Environmental relevance check against the SBOM. Query the SBOM for the affected component and version to check its presence in any artifact under the team's ownership. PURL or CPE identifiers correlate the CVE's affected-version range against the SBOM's component records. If the component isn't there, the disposition writes itself: "not present per SBOM dated [date], artifact hash [hash]," a fully auditable not-affected finding with zero developer involvement. If the component is present, move to step three. But check the SBOM's age first, because a stale SBOM can't support a reliable not-present conclusion, and treating it as though it can just moves the audit failure downstream instead of solving it.

Step 3: Exploitability and deployment-context assessment. Check for a VEX assertion from the vendor or product team first. Does it say "not affected," "affected," or "under investigation" for this specific product as deployed? If no VEX record exists, fall back to BOD 26-04's four variables by hand: is the asset exposed to the internet, is the CVE on the KEV list, can exploitation be automated, does a successful exploit produce full technical compromise. Answering those four questions one at a time, with the answer written down, is what turns a triage decision into something an auditor can actually follow, rather than a judgment call nobody can reconstruct six months later.

Step 4: Disposition and documentation. Write the actual decision down in a form that survives without whoever made it. "Not affected, per vendor VEX record dated [date]" is defensible. "Accepted risk, low severity" with no supporting reasoning is not, and it's the exact pattern that fails under regulatory and financial-oversight scrutiny alike. Every disposition needs a category (remediate, mitigate, accept, not affected), a named source for the reasoning, and a date. If the decision leans on an EPSS score or a BOD 26-04 variable instead of a CVSS number, write that down too, because a future auditor won't reconstruct the logic from the number alone.

Step 5: Sign-off and review cadence. Route every "accept" and "not affected" disposition through a named reviewer, even if that reviewer is one person wearing multiple hats on a small team. Set a re-check interval tied to SBOM freshness rather than a fixed calendar date, since a component ruled "not present" six months ago may not still be absent from the current build. The workflow closes the loop only when the record shows who accepted the risk, on what evidence, and when it's due for another look. That loop, run consistently, is what suppression never gave a compliance team.