Read a monorepo SCA report per project, not as one list. Split findings by the folder or workspace that owns each lockfile, collapse shared libraries into one issue with a list of affected projects, and assign owners by directory. Otherwise a single library upgrade appears as dozens of unrelated findings.
What makes monorepos different
A monorepo holds many services or packages in one repository. Each often has its own manifest and lockfile, plus shared code. A report run at the root can produce the same finding many times, once per project that includes the library. It can also hide projects entirely if the scan only read the root.
Step one: confirm each project appears
List the projects in the repository and check each has its own entry in the report with a package count. A workspace based layout may use one lockfile at the root for many projects, while another layout has a lockfile per project. Know which you have. The npm documentation notes that a lockfile is required by default for an audit and that bypassing it can make results differ on every run, so for lockfile based projects confirm the right file was read.
Step two: group by library
Pivot the report so the library and version come first and the affected projects follow.
| Library and version | Finding | Projects affected |
|---|---|---|
| Library A 2.1.0 | One vulnerability | Service one, two, five |
| Library B 4.0.2 | One vulnerability | Shared package only |
The first row is one upgrade done three times, or once if the projects share a version declaration. The second is a single change in one place that every dependent project picks up.
Step three: separate shared code from services
Findings in shared internal packages have a wide blast radius, since every consumer inherits them. Fix those first, since one change helps many services. Findings in a single service are local.
Step four: assign owners by path
Use directory ownership. Route findings in a service folder to that team, and findings in shared folders to the platform or library team. A CODEOWNERS style file is a natural source of truth if you have one.
Step five: pin versions together where you can
Different projects pinning different versions of the same library multiplies findings and upgrade work. Aligning versions across the repository cuts both. Do it deliberately, with tests, since a shared bump touches every consumer.
What to report upward
Give two numbers per month: unique vulnerable library versions across the repository, and number of projects affected by the top five. The first shows exposure, the second shows where one change pays off most.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how packages are grouped so you can see which components are shared.
Where Safeguard fits
Safeguard's SBOM and dependency scanning cover repositories with multiple projects, and reachability analysis helps decide which shared library findings are exposed.
Quick check
Why do I see the same finding many times in a monorepo?
Each project that includes the vulnerable library is reported separately. Group by library to see the real number of changes.
Who owns a finding in shared code?
The team that owns the shared package, since the fix there flows to every consumer.
Sources
Last reviewed: 19 October 2026.
