Most gates should fail on runtime dependencies and warn on development ones, because test and build tools do not ship to production. The exception is build tooling that touches secrets or produces your artifacts, where a flaw can still hurt you.
What counts as runtime and dev
A runtime dependency is code that runs in the shipped product. A development dependency is used to build, test or lint. Package managers label them differently, but the idea is the same.
The GitHub dependency review action has a scope setting. Its fail-on-scopes option selects which scopes can fail the check: runtime, development or unknown, and the default is runtime. The npm audit command supports omitting dev dependencies, and its docs say omitted types are left out of the submitted payload, so their vulnerabilities are not reported.
Decision table
| Dependency role | Gate behaviour | Reason |
|---|---|---|
| Runtime, shipped | Block per threshold | Reaches users |
| Dev, test only | Warn | Never leaves CI |
| Build tool that signs or publishes | Treat like runtime | Compromise affects artifacts |
| CI plugin with access to secrets | Treat like runtime | Runs where credentials live |
| Unknown scope | Review manually | Do not guess |
Why dev dependencies are not harmless
A test framework with a code execution bug is a risk if your CI runs untrusted pull request code. A build plugin runs with the permissions of the build. If the runner holds deploy credentials, a flaw in a dev package can expose them. This is why "dev" is a poor proxy for "safe".
Steps to set scope sensibly
- Start with runtime scope for the blocking gate.
- Run a non blocking report for dev scope and read it monthly.
- Promote any build or publish tooling into the blocking set by name.
- Handle the unknown scope: find out why the tool cannot classify it.
- Document the decision in your gate policy.
Watch the unknown bucket
Both the options above acknowledge an unknown scope. Lockfile formats vary, and some ecosystems do not label scope well. If a large share of your dependencies are unknown, your gate is blind to them. Fix classification first.
Quick check
Is a dev only vulnerability ever urgent?
Yes, if it runs in a context with secrets or untrusted input, or if it is known to be exploited.
Will omitting dev dependencies hide them from audits?
From that report, yes. Keep a separate dev scan so the record is complete.
Safeguard's dependency scanning separates findings by dependency and supports policies you set per scope. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
