## TL;DR
Usually no, but not always. A dev-only critical matters only if the vulnerable code runs somewhere an attacker can reach: your CI pipeline, your published package, or your developers machines. Check where it runs before you decide, and document the call either way.

```text
"critical CVE in a dev-only dependency" do you care
```

### Use this when
- A scanner flags a critical CVE in a test framework, linter, or build tool
- Someone on the team panics over a dev-only 9.8
- You are triaging a batch of dev-dependency alerts
- You need a defensible policy for dev-only findings

### Not for
- CVEs in runtime or production dependencies (patch those)
- Supply-chain attacks that target the build pipeline itself (different threat)
- Deciding whether to keep the dependency at all

### Steps

**1. Confirm it is really dev-only.**

Check that the package is in devDependencies or the equivalent, and that it is not bundled into your production artifact. Build the artifact and grep it for the package.

Expected: a yes, it never ships, with the bundle check as evidence.

**2. Ask where the vulnerable code executes.**

Dev tools run in three places: developer laptops, CI runners, and inside published packages. Laptop and CI execution is a much smaller blast radius than production, but it is not zero.

Expected: the execution context named for the vulnerable code path.

**3. Check the actual attack scenario.**

Read the advisory and ask: can an attacker reach this code? A test framework parsing untrusted input in CI is reachable. A linter rule with a regex flaw that only triggers on your own source files is not interesting to an attacker.

Expected: a realistic attack story, or the conclusion that none exists.

**4. Decide: patch on the normal cycle, or now.**

If no attacker-reachable path exists, schedule the upgrade with normal dependency maintenance. If CI or the pipeline is genuinely exposed, treat it like a production issue.

Expected: a decision with a date, not a shrug.

**5. Document the call.**

Note the CVE, the evidence it is dev-only, and the decision. When the alert resurfaces or an auditor asks, you have the answer ready.

Expected: a one-paragraph dismissal note anyone can re-verify.

### Variant phrasings

#### Should I patch a critical in devDependencies
Only if the vulnerable code runs somewhere attacker-reachable. Otherwise schedule it with normal maintenance and document why.

#### Dependabot critical alert on a test library
Same check: confirm dev-only, confirm no reachable path, dismiss with evidence or patch if CI is exposed.

#### Do dev dependency vulnerabilities matter
They matter less than production ones, but the build pipeline is still infrastructure. A critical that runs in CI deserves more respect than one that runs on a laptop.

### Why it happens
Scanners flag severity without context, so a critical in your test runner looks identical to a critical in your API server. But severity measures the flaws worst case, not your exposure. Dev-only code runs in lower-value, harder-to-reach environments, so the same score means less risk. The panic comes from reading the number without reading the context.

### Edge cases
- **Dev tool runs in CI on untrusted input:** a test runner or build script that processes PRs from strangers is attacker-reachable. Treat this as production-adjacent.
- **Dev dependency gets bundled by mistake:** misconfigured builds sometimes ship dev deps. The bundle grep in step 1 is what catches this.
- **The dev tool has postinstall scripts:** install-time code execution is a different threat from the CVE itself. If the package is compromised, the CVE score is irrelevant.
- **Policy says patch all criticals regardless:** some compliance regimes dont care about dev-only. If your policy says patch, patch, and use this skill to argue for changing the policy, not to dodge it.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_gM-XW8h7uxjCYnMcNfH5vg