Scope the scan by what ships to users or runs in production. Test fixtures, sample apps and throwaway scripts usually do not. Vendored third party code and internal libraries usually do. Write the exclusions down, review them every quarter, and never exclude a folder just because it is noisy.
Why scope matters
A monorepo scan finds every manifest it can reach. Many of those belong to things that never ship: a fixture with a deliberately old package.json, an examples folder with its own lockfile, a docs site, a benchmark harness.
If they are in scope, the report fills with findings nobody can or should fix. People learn to ignore the report, and then they ignore the real ones.
A decision table
| Folder type | Ships to production? | Default |
|---|---|---|
| Services and applications | Yes | In scope |
| Internal libraries used by shipped code | Yes | In scope |
| Vendored third party code | Yes, if used | In scope |
| Test fixtures with intentionally old packages | No | Exclude, with a comment |
| Examples and samples | No, unless copied by users | Decide per folder |
| Build and CI tooling | Runs in your pipeline | Separate, lower priority |
| Docs site | Public, but separate | Own scope |
| Archived or dead code | No | Delete or exclude |
Build tooling deserves care. A compromised build dependency can affect everything you ship, so do not treat it as irrelevant. Give it its own scope and its own policy. See do dev dependencies matter.
Rules for exclusions
- Exclude by path in a file in the repo. Reviews then show the change.
- One comment per exclusion saying why, and who approved it.
- Never exclude by finding. Exclude a folder, or accept a risk with an expiry. Hidden findings are invisible risks.
- Review on a schedule. A fixture folder can quietly become a real service.
- Count excluded manifests and report the number, so growth is visible.
The same logic applies to code scanning. See SAST exclusions for tests, generated and vendored code.
Watch for sneaky cases
An examples folder that people copy into real projects is a supply chain path of its own. A test fixture that is also used as a base image in production is not a fixture. A folder named legacy that still runs in one region is still running.
If you cannot say whether something ships, find out before excluding it. Ask the owner, or check the deployment configuration.
Tune with evidence
Run a scan with everything in scope, group findings by folder, and look at the biggest groups. If one folder produces most of the findings, check whether it ships. That is a better method than guessing.
Safeguard scans dependencies and generates SBOMs per project, so you can choose scope per project. Try the free scan at https://gold.safeguard.sh/scan.
Try it yourself
Open the inventory demo and notice how each component sits under a source. Ask which of your sources would not ship.
Click through it at your own pace, or open it full screen.
Quick check
Should vendored code be scanned?
Yes, if it ships or runs in production. It is your risk even though someone else wrote it.
Is it fine to hide a noisy finding?
No. Exclude a folder with a reason, or accept the risk with an expiry date, so it stays visible.
Last reviewed: 19 October 2026.
