Count it as one issue with 40 occurrences. Group findings by advisory and library version, then attach the list of affected packages. Reports that count every occurrence inflate the backlog, and reports that count only unique advisories hide how widely a problem spreads. Show both numbers.
Why the numbers blow up
A monorepo often shares versions. A shared lockfile, a central version file or a common constraints file means one vulnerable release of one library reaches many packages. A scanner that reports per package then lists the same advisory forty times.
Executives see a thousand findings. Engineers see one upgrade. Both are right, which is the problem.
Three counting units
| Unit | What it counts | Use it for |
|---|---|---|
| Occurrence | Advisory times affected package | Blast radius, who is exposed |
| Root cause | Advisory times library version | Work planning |
| Fix action | Distinct changes needed to clear them | Effort and sprint planning |
The third is the most useful for planning. Raising one version in a shared file can clear forty occurrences in one pull request. Conversely, one occurrence in a package with a pinned override may need its own change.
How to compute it
- Normalise each finding to advisory identifier, library name, resolved version and manifest path.
- Group by the first three fields. That gives root causes.
- For each group, list the manifest paths. That gives occurrences.
- For each group, find where the version is set: shared file, package file or transitive. That gives fix actions.
If your tool exports JSON, this is a short script. If it does not, ask why it does not.
Report it honestly
Put the root cause count first, then the occurrence count, then the fix action count. For example, say there are twelve root causes, spread across 190 occurrences, fixable with seven changes. That reads as a plan.
Avoid mixing units across weeks. If you switch from occurrences to root causes, say so, or the trend line will lie.
Beware of duplicates from layers
Container images and source scans can report the same library twice, once from the lockfile and once from the image. Deduplicate by library and version when you merge sources, and keep a note of the source so owners know where to fix it. See SCA monorepo and container coverage checks.
Do not hide the spread
Some teams collapse everything to unique advisories and lose sight of exposure. A single vulnerable library in forty services may carry more risk than five in one internal tool. Keep the occurrence list available, and use exploitability and reachability to rank.
Where Safeguard fits
Safeguard applies reachability analysis, which helps rank which occurrences are actually exercised by your code, and can open fix pull requests when autonomous remediation is turned on. It is off by default, with every category set to Manual. Try the free scan at https://gold.safeguard.sh/scan.
Try it yourself
Click through the reachability demo and compare the raw finding count with the count after reachability is applied.
Click through it at your own pace, or open it full screen.
Quick check
Is one library in 40 packages 40 vulnerabilities?
It is one root cause with 40 occurrences. Report both, plus the number of fixes needed.
Which count suits sprint planning?
The number of distinct fix actions, since one shared change can clear many occurrences.
Last reviewed: 19 October 2026.
