Development dependency findings usually matter less than runtime findings, because the package does not ship to production. They are not zero risk, since build tools and test runners execute on developer machines and in CI. Fix runtime findings first, then handle development ones on a slower schedule.
What scope means in a report
Most package managers separate dependencies the application needs to run from those needed only to build or test it. In npm these are dependencies and devDependencies. SCA reports usually carry that distinction as a scope or type label so you can filter on it.
GitHub's Dependabot documentation shows the same idea. You can filter alerts with a development scope filter, and alerts for development-scoped dependencies carry a Development label. The documentation says this can help you prioritize alerts that affect production dependencies first.
Why development findings are lower, not absent
| Question | Runtime finding | Development finding |
|---|---|---|
| Ships in the deployed artifact? | Yes | Usually no |
| Reachable by outside input? | Possibly | Rarely |
| Runs with access to secrets? | In production | In CI and on laptops |
| Fix urgency | High if reachable | Lower, but track it |
The caution is that build and CI environments often hold credentials and write access. A malicious or compromised development package can run code there. So the risk is different, not nonexistent. It is more about supply chain compromise than about a runtime flaw that outside users trigger.
How to read scope correctly
- Check the label, then check the build. A package labeled development may still be bundled into the output by your bundler. Confirm with your build tooling.
- Check for mislabeled packages. A library listed as development that your code imports at runtime will fail in production, so these are usually caught early, but the reverse is common: runtime dependencies that should be development only.
- Look at how the command treats scope. The npm audit documentation explains that when omit options are used, such as the production shorthand, packages are omitted from the submitted payload accordingly. The npm audit fix command can also skip updating devDependencies with the prod option. So the output you see depends on the flags used.
# Audit production dependencies only
npm audit --omit=dev
That command is a good way to see what a production-only report looks like for an npm project.
A simple policy
- Runtime, reachable or known exploited: fix on the fastest track.
- Runtime, not reachable: fix on the normal upgrade schedule.
- Development only: fix in routine maintenance, and move faster if the package is in a compromised or malicious package advisory.
Write the policy down so reviewers do not relitigate it for every finding.
Where Safeguard fits
Safeguard's policies and gates can treat runtime and development findings differently, and reachability analysis adds context for runtime ones. You can run a free scan at gold.safeguard.sh/scan to see how your findings split.
Quick check
Can I ignore development dependencies completely?
No. They run in CI and on developer machines, which can hold credentials. Give them a lower priority, not none.
How do I see production-only results in npm?
Run the audit with the omit option set to dev, which omits development packages from the submitted payload.
Sources
Last reviewed: 19 October 2026.
