Exclude generated code and copied third party sources, usually keep tests in scope at lower priority, and never exclude whole directories just to make a number look better. Store exclusions in a version controlled file with a reason for each, and check that your tool supports that.
Why exclusions matter in an evaluation
A first scan often shows a lot of results in code nobody will edit by hand. Generated clients, protocol buffers output, bundled libraries copied into the repository. Reporting on them wastes triage time. But careless exclusions create blind spots, and attackers do not care whether a file was generated.
So ask how a tool lets you control scope, and test it during the pilot.
Categories and a default view
Generated code. Usually exclude, since the fix belongs in the generator or its input. Do scan the generator's templates if you maintain them.
Vendored dependencies. Code copied from other projects into your tree. Exclude from first party analysis, but make sure a dependency scanner knows about it. Copied code is a classic gap: it is not in the manifest, so dependency tools miss it unless they match on content.
Tests and fixtures. Test code can contain real flaws, hardcoded credentials and unsafe helpers that leak into production. Usually keep it in scope. Many teams lower the severity or switch off a few rules there, such as those about missing input validation in a unit test.
Build scripts and infrastructure files. These are code too. Keep them in scope, and check whether the tool covers the formats you use.
Minified and bundled output. Exclude, but scan the source it came from.
Examples and documentation snippets. Decide case by case. Snippets often get copied into real projects.
How the tool should handle exclusions
- Can paths be set in a configuration file that lives in the repository and goes through review?
- Can you exclude by path pattern, by rule, or by rule within a path?
- Are exclusions visible in reports, so an auditor sees what was not scanned?
- Can exclusions have an expiry or an owner?
- Does the tool warn when a large share of files is excluded?
Dashboard only exclusions are fragile. They are invisible in code review and disappear if you switch tools.
A test in your pilot
Run the first scan with no exclusions, and count results by directory. Likely, a small number of directories produce most of the noise. Decide what to exclude, write it down, and rescan. Record the before and after counts, and separately, whether any real finding disappeared. Check the labelled real findings from the first run against the second. If one vanished, the exclusion was too wide.
Document the decision
For each exclusion, write the path, the reason, the owner and the review date. A short table in the repository is enough. When an auditor asks what is not scanned, you will have an answer.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how copied or nested components show up in an inventory.
Quick check
Should test code be scanned?
Usually yes, with lower priority. Tests can hold real credentials and unsafe helpers that reach production.
Is it fine to exclude a noisy directory?
Only after checking that it holds no real findings and that the code is truly generated or not yours. Record the reason.
Safeguard's SBOM and dependency scanning is generally available, and the free scan at gold.safeguard.sh/scan is a quick way to see what is in your dependency tree.
Last reviewed: 19 October 2026.
