Exclude a folder from scanning when nothing in it ships or runs in production, such as test fixtures or sample projects. Suppress an individual finding when the code ships but a specific advisory does not apply. Exclusion changes what you scan. Suppression records a decision about one risk.
Two tools, two jobs
| Path exclusion | Finding suppression | |
|---|---|---|
| Question it answers | Should this code be scanned at all? | Does this issue matter here? |
| Scope | A directory or file pattern | One advisory in one place |
| Needs evidence | That the code does not ship | That the issue does not apply |
| End date | Review when the folder changes | Required |
Mixing them causes trouble. A broad path rule used to quiet a noisy finding in shipping code is a silent hole.
When exclusion is right
- Test fixtures that include old vulnerable manifests on purpose, for example to test a parser.
- Sample applications in documentation folders that no one deploys.
- Generated output or build caches that duplicate real sources.
- Third party copies you scan elsewhere under their own name.
Check the claim. "It is only a test" is not proof. Look at what the build packages, and at whether CI deploys anything from that folder.
When exclusion goes wrong
- A test folder holds a helper that production code imports.
- A samples folder is copied into a container image by a loose copy rule.
- A new service is created inside an excluded folder and nobody notices.
- A pattern like a wildcard matches more than intended.
How to exclude safely
- List what the exclusion covers by running the pattern and reading the matched paths.
- Confirm the build and container steps never include them. Search copy commands and packaging rules.
- Write the pattern, the reason and the owner next to the exclusion.
- Review the matched paths again each quarter, or when the repository layout changes.
- Keep fixtures that intentionally contain vulnerable packages in one clearly named folder so the rule stays tight.
When suppression is right
Use suppression for shipping code. Name the advisory, the package, the version and the project, give the reason and evidence, and set an end date. See scope guidance.
A middle path for dev only code
Some ecosystems let you mark dependencies as development only. Scanning them is still useful, since build tools run in CI where secrets live. If you lower the priority rather than hide them, you keep visibility. Our post on dev dependencies explains why.
A quick audit
Once a quarter, list every exclusion pattern and print the files it matches. If the list is longer than you expected, or includes a directory that holds shipped code, tighten the pattern the same day. Exclusions grow quietly, so give them the same review as suppressions.
Quick check
Can I exclude a test directory without review?
Make it reviewed once, with a note that nothing from it ships. After that, review quarterly.
Does exclusion remove the findings from my SBOM?
It removes the excluded components from what the scan sees, so state the exclusion wherever you share the SBOM.
Last reviewed: 19 October 2026.
