Where should dependency scans run in a monorepo?

In a monorepo, run a fast scan on each pull request limited to the projects whose dependency files changed, and run a full scan of the whole repository on a schedule. Attribute each finding to a project and an owning team, so results are fixable and not just visible.

The monorepo problem

A monorepo can hold dozens of projects across several ecosystems, each with its own manifest and lock file, sometimes with a shared root lock file. A scan that treats the repository as one unit is slow, noisy and hard to assign. A scan that ignores structure misses nested projects.

Three design choices

1. Discovery. The scanner must find every dependency file in the tree, not just the one at the root. Test this by listing manifests and lock files with a simple file search, then checking that each appears in scan output.

2. Scope per pull request. Use path filters so a change in one project scans only that project, plus anything that depends on a shared file. If a shared root lock file changes, scan everything it covers.

3. Ownership. Map directories to teams. A finding in a directory with no owner is a finding no one fixes.

Split by stage

Watch the internal dependencies

In a monorepo, one project often consumes another through a workspace link. A vulnerable dependency in the shared library affects every consumer, but only shows up as a finding in the library. Your reporting should show the consumers, so priority reflects real exposure.

Steps to set it up

1. Enumerate dependency files and confirm the scanner sees them all.
2. Create a map from path to owning team and put it where tools can read it.
3. Configure pull request jobs to trigger only on changes to dependency files and shared roots.
4. Add a scheduled full scan and send findings to the mapped owner.
5. Generate per project SBOMs, not one for the whole repository, so releases can be traced.
6. Review the map every quarter, since monorepos reorganise.

Pitfalls

• Path filters that miss shared files. A change to a root level config can alter every project.
• One huge report. Nobody reads it. Split by owner.
• Duplicate findings. The same transitive package in twenty projects produces twenty alerts. Group by package and version.

Where Safeguard fits

Safeguard provides dependency scanning and SBOM generation, with policies and gates for pull requests and asset discovery to help map what exists. Try the free scan at gold.safeguard.sh/scan.

Quick check

Last reviewed: 19 October 2026.