An advisory lands in the morning, and by lunch a scan has turned up every repository where the affected package appears, each one tagged with the same severity. The list is accurate and mostly useless, because it tells you where the package is, not where it matters.
Presence in a scan isn't exposure
A software composition scan reports every vulnerable package it finds in a dependency graph, and most of those hits don't matter the way the report implies. Plenty are development-only, pulled in three levels deep and never loaded at runtime. Others are declared in a manifest and forgotten. A handful are packages a request handler calls on every request, and a scanner that can't tell the difference reports all of them the same way, which is why someone ends up triaging the list by hand.
Three questions turn that list into an actual plan.
Which releases ship it? Exposure is a question about what's running. "Version 4.2 of the billing service" is an answer; "the billing repository" isn't, because code in a repository can easily be months away from a release. That's the case for generating a software bill of materials per release rather than per project: it's the one artefact that answers this question without reconstructing deployment history by hand.
Can first-party code actually reach it? A package that's imported and called is a different finding from one that's imported and never called, or never referenced outside a manifest. The companion tool behind Dependably Packages does package-level reachability for npm, NuGet and Python, and marks each vulnerability reachable, not observed, or unknown. "Not observed" means the analysis looked and found no reference. "Unknown" means it could not tell, so it never reads as safe.
How likely is exploitation? CVSS is a severity score, not a probability. The Exploit Prediction Scoring System estimates one. A listing on the CISA Known Exploited Vulnerabilities Catalog is neither a score nor an estimate. It means someone is already using this against real targets. Taken together, the three turn a flat severity number into something you can actually order work by.
What a rollup looks like
A finding with a CVSS score, an EPSS probability, a KEV flag, and, where the tooling supports it, a reachability verdict sorts into act on it now, attend to it this sprint, or track it until something about it changes. A VEX statement that the product is not affected moves it to suppressed. Rolled up across every project, that's the number a raw count of findings never gives you: which service to patch first, and which ones can wait for the next scheduled release.