In a monorepo, test whether the tool detects each project inside it, scans only what a pull request touches, splits results by directory owner, and handles several languages in one run. Run these eight checks on your real repository, because a sample project hides every problem a monorepo creates.
Why monorepos break assumptions
Many tools assume one repository equals one application. A monorepo may hold dozens of services, shared libraries, scripts and generated code, in several languages, with different owners. If the tool treats it as one blob, you get one giant result list that nobody owns.
The eight checks
1. Project detection. Does the tool find each service on its own, or do you configure each one by hand? Count the setup steps for ten services.
2. Scan scope. On a pull request that touches one service, does it scan one service or the whole tree? The difference is minutes against hours.
3. Language mix. If the repository holds several languages, confirm each is analysed in the same run. OWASP lists language support as the prerequisite criterion for choosing a tool, so check each language and its frameworks, not just the headline list.
4. Build requirements. Some tools need the code to compile. In a monorepo with a shared build system, ask whether the tool understands it or needs a separate compile per project.
5. Ownership routing. Can findings be assigned by directory or by the repository's code owners file? Without this, the security team becomes the triage desk for everyone.
6. Result separation. Can you view, filter and report per service? Leaders will ask for a number per team.
7. Shared code. If a library is used by many services, a flaw there matters more than a flaw in a leaf service. Does the tool show which consumers are affected?
8. Limits and timeouts. Ask about maximum repository size, file count and result count. Check whether the tool uploads results in a format with its own limits. GitHub's documentation, for example, lists size and result caps for SARIF uploads, so a large run may be truncated if you ignore them.
What to do with generated and vendored code
Monorepos often hold generated code and copied third party sources. Scanning them creates noise for code nobody will edit by hand. Confirm you can exclude paths, and that exclusions are written in a file under version control rather than clicked in a dashboard.
A simple test plan
Pick three services in different languages, plus one shared library. Run a full scan, then a pull request scan with a change in the shared library. Record time, result counts by directory, and whether the right owner gets each finding. Repeat on the second candidate.
If one tool needs ten manual configurations and another detects projects automatically, that gap will grow every time you add a service.
Try it yourself
Click through it at your own pace, or open it full screen. Note how results are grouped and what context each one carries.
Quick check
Do I need a separate scan job per service?
Not necessarily. Prefer a tool that detects projects and scopes pull request scans to changed paths. Separate jobs are a fallback.
Who should receive findings in a monorepo?
The owners of the directory where the finding sits, using your code owners file where possible.
Safeguard's CLI has guidance for scanning large repositories without timeouts, and SBOM and dependency scanning is generally available. A free check is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
