Sometimes, but usually a lighter record is enough. A vulnerability in a dev-only dependency does not ship to production, yet it can still run on developer laptops and in CI with access to secrets and build output. Treat it by what it can touch, then document the decision briefly.
The mistake runs both ways. Some teams demand a full exception for every test-framework finding. Others wave "it is only dev" at everything, including build tools that sign release artifacts.
First, confirm it really is dev-only
Check three things before you downgrade anything.
- The package is in a development or test section of the manifest, and a production install does not pull it in.
- No production image, bundle, or artifact contains it. Inspect the built output, not just the manifest.
- It is not also a transitive dependency of something that does ship.
A component can be dev-only in one service and runtime in another, so check per repository.
Then ask what it can reach
| Where it runs | What it can reach | Treatment |
|---|---|---|
| Local tests only, no network | Source code | Light record |
| CI with deploy credentials | Secrets, registry, cloud roles | Treat as a runtime risk |
| Build step that produces release artifacts | The shipped product | Fix, or full exception |
| Developer tooling that parses untrusted input | Laptops | Judge by exploit path |
A vulnerability that needs hostile input to a test helper is a different thing from one in a bundler that processes third-party packages during every build. Build tools sit in the supply chain, and attackers know it.
The light record
For low-reach cases, a short note in the ticket is fine. Include the component and version, the repository, why it is dev-only, and a review date, usually the next quarterly dependency pass. No separate approval meeting is needed, but someone other than the author should see it, which a pull request review covers.
When to escalate
Escalate to a full exception when the dependency touches signing, publishing, or deploy steps, when a known exploit exists and your CI exposes tokens, or when the fix is blocked by an incompatible upgrade. Use the KEV catalog as a quick check: if the CVE is listed as known exploited, do not treat it as routine just because the package is dev-only.
Make the call repeatable
Write the rule once in your policy: "Findings in dev-only components follow a 90 day window unless the component runs in CI with credentials or touches release artifacts." Then reviewers apply the rule instead of debating each case.
Where Safeguard fits
Safeguard's SBOM and dependency scanning separate direct and transitive components, and reachability analysis helps show whether vulnerable code is used at all, which feeds the dev-only judgment.
Try it yourself
Click through it at your own pace, or open it full screen. Switch between direct and transitive components and notice how one package can appear in more than one place.
Quick check
Is a dev-only vulnerability ever critical?
Yes, if the tool runs in CI with secrets or builds what you ship. Rate it by reach, not by section of the manifest.
Do auditors care about dev dependencies?
They care that your policy says how you treat them and that you follow it. A written rule beats ad hoc answers.
Sources
Last reviewed: 19 October 2026.
