It depends on how the analysis is scoped. A path that exists only from test code or a build tool does not run in production, so most teams rank it lower. But it can still matter for your CI environment and your developers' machines. Scope reachability by where the code runs, not by one global switch.
Three places code can run
| Where | Examples | Who is exposed |
|---|---|---|
| Production runtime | The service handling customer traffic | Customers and your data |
| Build and CI | Compilers, bundlers, test runners | Your pipeline and its secrets |
| Developer machines | Linters, local servers, editors | Individual workstations |
A vulnerable function reachable only from a unit test sits in the second or third row. Its blast radius is different, not zero.
Why scope matters for noise
Dev dependencies are often the largest part of a modern project tree. If a reachability report mixes test-only paths with production paths, the "reachable" count inflates and trust drops. If it drops them entirely, you may miss a build tool vulnerability that can steal CI tokens.
The better design is to tag each finding with its scope and let policy decide.
How to set it up
- Separate the entry points. Production entry points are the main program, request handlers and job runners. Test entry points are test files and fixtures.
- Run analysis per scope, or ask the tool to label which entry point started each path.
- Set different thresholds. For example, block a release on production reachable findings of a given severity, and open a lower priority ticket for CI scope findings.
- Review CI scope by privilege. A build tool that sees deployment credentials deserves more attention than one that only formats code.
- Revisit when scope changes. A test helper copied into production code changes the answer.
Common mistakes
- Treating "dev dependency" as "harmless". Some run install scripts or process untrusted input, such as parsers used on downloaded files.
- Counting everything as production because the lockfile does not label scope.
- Ignoring test code that is deployed, such as a mock server left enabled in a staging environment that holds real data.
Reading the result for a decision
When someone says "not reachable", ask "from which entry points?". An answer such as "not from production entry points, reachable from the test runner" is a precise, useful statement, and it leads to a sensible priority rather than a blanket dismissal.
Safeguard includes reachability analysis alongside SBOM and dependency scanning, and you can run a free scan at gold.safeguard.sh/scan to see the output on your own repository.
Quick check
Should I hide dev dependency findings?
Do not hide them. Label them by scope and give them a lower priority unless the tool touches secrets or untrusted input.
Can test code ever matter for production reachability?
Yes, if test code is packaged into the deployed artifact or reused by production modules. Check what actually ships.
Last reviewed: 19 October 2026.
