AI
The CVE Noise Problem
Last year, roughly 29,000 CVEs were published. SCA scanners, container scanners, and API testers surface every one. A CVE attests to possible exploitation. Probability of being exploited is a separate question, and usually much lower. Most findings land in false-positive territory: your application doesn’t call the vulnerable function, or exploitation requires an input path that doesn’t exist in your code. Security teams spend the majority of their effort investigating vulnerabilities they were never exposed to.
EPSS Thresholds Beat Severity-Only Triage
CVSS scores measure severity. EPSS measures probability, expressed as a percentile ranking against all known CVEs. Filtering on CVSS 9.1+ captures 33% of your exposure for 15% of developer effort. Setting an EPSS threshold of 0.22 (2.2%) reaches 90% coverage at the same effort. The gap is in false negatives: vulnerabilities you skipped that could still exploit you. EPSS also changes over time. A CVE with a near-zero score today can jump to the 90th percentile the day a proof-of-concept drops.
Reachability Analysis: Useful Input, Not a Decision
Reachability analysis compares your call graphs, including transitive dependencies, against a database of vulnerable functions identified from fix commits. It tells you whether code calls a vulnerable symbol. It does not tell you whether that call is exploitable. A CVE requiring 256-character input to trigger is irrelevant in an application that never passes such input. An improper-input-validation CVE is not a risk if the application accepts no user-provided input. Reachability speeds up VEX attestation work but does not replace it.
VEX Statuses, CPEs, and PURLs
VEX has four statuses: affected, not affected, under investigation, and fixed. “Not affected” requires a justification. CISA publishes pre-approved options including inline mitigation and the vulnerable function not being called. “Fixed” applies only if you were previously affected and took remediation action. “Under investigation” should reflect actual developer resources assigned, not a default state. For package identification, use PURLs. CPEs are created only when a vulnerability is assigned, so tooling invents them preemptively. When MITRE formalizes the CPE, naming often diverges and lookups return nothing.
The Five-Step VEX Workflow
Step one: component analysis. Use SCA tooling, ingest a provided SBOM, or both. Step two: triage with the SSVC decision tree (respond immediately, backlog, or watch). Step three: impact assessment across packages. For jackson-databind at version 2.9.7 carrying 21 CVEs, a single jump to 2.9.10.5 remediates four at once instead of chasing each individually. Step four: assign VEX status with justification. Step five: publish and re-trigger the cycle when EPSS scores shift or CVE metadata changes.
Publishing, Consuming, and Staying Current
Frazier recommends publishing VEX as a standalone OpenVEX or CSAF document rather than embedding it in the SBOM. SBOM attributes (package name, PURL, supplier) rarely change. Vulnerability status changes daily. Separating them avoids regenerating the full SBOM on every status update. Two triggers warrant a new VEX cycle: new CVE information (including EPSS score changes) and status transitions after investigation. Red Hat and Confluent currently publish VEX statements. Teams hesitant to share SBOMs out of fear that attackers will exploit the data are more likely reflecting weak layered controls than real risk.
Q&A
Are VEX statements available for open source dependencies today? Most open source maintainers are not yet publishing VEX; Red Hat and Confluent lead in transparency, and Frazier suggested adding SBOM and VEX presence as a negative signal in the OpenSSF scorecard to accelerate adoption. ▶ Watch (41:02)
Can sharing vulnerability information create legal liability? The bigger legal exposure is failing to meet contractual SLAs for vulnerability remediation; proactively publishing SBOMs does the opposite, giving suppliers a verifiable record of compliance. ▶ Watch (43:41)
Is there tooling to ingest VEX alongside SBOMs? Dependency-track handles CycloneDX imports with VEX support; the main unsolved challenge is normalizing data across Linux distributions where the same library name maps to different packages per distro. ▶ Watch (45:27)
Notable Quotes
a reachability determination in of itself is not an exploitability determination Cortez Frazier Jr. · ▶ Watch (14:01)
I make it no secret that I absolutely despise cpes I think it’s the worst possible unique identifier that’s ever existed Cortez Frazier Jr. · ▶ Watch (19:39)
often times people will assume that all vulnerabilities are under investigation because they don’t want to communicate that they’re actually affected by those Cortez Frazier Jr. · ▶ Watch (20:29)
Key Takeaways
- A 2.2% EPSS threshold achieves 90% vulnerability coverage at the same developer effort as critical-only CVSS filtering.
- VEX “not affected” status requires a documented justification; “fixed” applies only after a confirmed prior affected state.
- PURLs uniquely identify packages across ecosystems; CPEs produce false-negative lookups when tooling and MITRE naming conventions diverge.
About the Speaker(s)
Cortez Frazier Jr. leads product for FOSSA’s SaaS and on-premises enterprise applications. FOSSA is a software composition analysis tool for managing open source license compliance and security vulnerabilities. Before FOSSA, Frazier served as a senior cybersecurity architect at GE Power, where a three-person team covered 1,800 developers and roughly 600 applications.