A scanner handles a monorepo well if it finds every project inside the repository, scans only what changed, and groups findings by owner instead of by repository. Ask for a demonstration on a repository that mixes languages and has dozens of manifests, not a toy example.
What goes wrong in a monorepo
A monorepo is one repository holding many projects, services or packages. Scanners built around "one repository equals one application" misbehave in three ways. They stop at the first manifest they find, they report one huge pile of findings with no owner, or they rescan everything on every commit and make builds slow.
The questions
| Area | Ask |
|---|---|
| Discovery | Does it find nested manifests and lockfiles automatically, at any depth? |
| Mixed languages | Can one scan cover several ecosystems side by side? |
| Scope | Can a scan run only on paths that changed in a pull request? |
| Ownership | Can findings be tagged by directory or by an ownership file? |
| Counting | If the same vulnerable package appears in 30 projects, is it one issue or 30? |
| Policy | Can different directories have different rules? |
| Speed | What is the scan time at our repository size? |
The counting question changes the numbers you report upward. See counting one vulnerability across many monorepo packages for why the answer matters.
Ownership is the real problem
Finding a vulnerability is half the work. Someone must fix it. In a monorepo the person who owns the affected directory is not always the person who set up the scanner. Look for a way to route findings using the same ownership data your code review already uses. The guide to CODEOWNERS for a monorepo shows how those files are structured.
Steps for a fair test
- Choose a branch of your largest monorepo.
- Count the manifests and lockfiles yourself with a simple file search.
- Run the scan and compare the number of projects it reports to your count.
- Open a pull request that touches one service and check that only relevant paths are scanned.
- Time both runs.
- Open the results and ask: could the owner of one service find only their findings in under a minute?
If step 3 shows missing projects, ask whether the cause is configuration or a limitation. Configuration can be fixed. A limitation is a decision factor.
Edge cases to raise
Vendored dependencies copied into a directory, generated lockfiles that are not committed, and workspaces defined by the package manager rather than the folder layout all trip up discovery. Bring one of each to the trial if you have them.
Try it yourself
Click through it at your own pace, or open it full screen.
Check how the inventory groups packages and ask how that grouping would look across fifty projects.
Quick check
Should each service in a monorepo be scanned separately?
Scan them in one run if the tool supports it, but report and route results per service so owners see only theirs.
Is scanning only changed paths safe?
It is fine for pull requests, as long as a full scheduled scan also runs, because new advisories affect unchanged code.
Safeguard offers SBOM and dependency scanning; test your repository with the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
