how to check if a CVE affects your dependencies

Not specified by the original author.

how to check if a CVE affects your dependencies

TL;DR

Dont eyeball version ranges by hand. Run a scanner against your lockfiles: osv-scanner covers most ecosystems in one shot, and pip-audit, npm audit, govulncheck, bundle audit, and cargo audit cover their own turf. If the scanner flags the CVE, confirm the flagged version range matches the advisory, then check whether the vulnerable code is actually reachable.

how to check if a CVE affects your dependencies

Use this when

• Someone names a specific CVE and asks "are we affected"
• A security advisory lists a CVE for a library you might use
• You want a yes-or-no answer per repo, not a full audit report
• You are verifying a scanner finding before patching

Not for this skill when

• You want a standing audit of every transitive dependency (different workflow)
• You are triaging a brand-new CVE with no scanner data yet (use the triage skill)
• The question is about severity ranking, not affected-or-not

Steps

1. Find every lockfile in scope

You can only answer for repos you actually scan. List the lockfiles across the repos that matter: package-lock.json, poetry.lock, requirements with hashes, go.mod plus go.sum, Gemfile.lock, Cargo.lock.

find ~/workspace -maxdepth 3 -name "package-lock.json" -o -maxdepth 3 -name "poetry.lock" -o -maxdepth 3 -name "go.mod" -o -maxdepth 3 -name "Gemfile.lock" -o -maxdepth 3 -name "Cargo.lock"

Expected: a list of lockfile paths. Every repo you skip is a repo you cant answer for; note the gaps.

2. Run osv-scanner across them

osv-scanner reads the lockfiles directly and matches against the OSV database, which aggregates CVE data across ecosystems. One tool, most languages.

osv-scanner --recursive --skip-git ./

Expected: a table of findings with CVE IDs, affected packages, and fixed versions, or a clean result. Save the output; you will match your CVE against it in step 4.

3. Run the ecosystem-native scanner for your main language

Native tools understand their ecosystem's quirks (vendoring, groups, build tags) better than any generic scanner. Run the one that matches your stack.

npm audit --omit=dev

Expected: npm's own advisory list for production deps. Equivalents: pip-audit for Python, govulncheck ./... for Go (this one also checks reachability), bundle audit check for Ruby, cargo audit for Rust. If the native tool and osv-scanner disagree, trust the native tool for its own ecosystem and investigate the gap.

4. Match your CVE against the findings

Search the scanner output for the exact CVE ID. Confirm the flagged package version falls inside the advisory's affected range and below the fixed version; scanners occasionally flag on overly broad ranges.

osv-scanner --lockfile=package-lock.json --format json | python3 -c "import json,sys; d=json.load(sys.stdin); rs=d.get('results',[]); print([ (r['packageSource']['path'], v['id']) for r in rs for v in r.get('vulnerabilities',[]) if v['id']=='CVE-2026-12345'])"

Expected: either matches pairing the CVE with specific lockfiles, or an empty list meaning not flagged. Empty plus a manual version check against the advisory range is a solid "not affected".

5. Confirm reachability before you patch

Flagged is not the same as exploitable. Check whether your code actually imports and calls the vulnerable package, and whether the vulnerable feature is enabled. Go's govulncheck does this automatically; for other ecosystems, grep for the import and the vulnerable API.

grep -rn "from [package] import" src/ | head; grep -rn "require('[package]')" src/ | head

Expected: import lines, or nothing. Reachable means patch on the normal schedule for the severity; unreachable means schedule it with everything else and note why.

Variant: am I affected by CVE-2026-XXXX

The one-liner version: run osv-scanner on the repo, grep the output for the CVE ID. If it appears, check reachability; if not, spot-check the version range in the advisory and move on. Five minutes, defensible answer.

Variant: check my lockfile for a specific vulnerability

Same as above but starting from the lockfile instead of the repo: osv-scanner --lockfile=[path] then match. Useful when someone hands you a lockfile from a service you dont own.

Variant: is my docker image affected by this CVE

Dependencies live in image layers too. Scan the image itself (trivy image [image]:[tag] or grype [image]:[tag]) and match the CVE there; the app lockfile wont show OS-package CVEs.

Why this happens

Version ranges in advisories are written for every consumer of a library, and humans are bad at comparing semver ranges across nested transitive trees. Scanners exist because "do we use libfoo between versions 2.1 and 2.4.7" is a database lookup, not a judgment call. The judgment call comes after: reachability.

Edge cases and pitfalls

• No lockfile committed: without one, the scanner guesses from manifests and the answer is unreliable; commit the lockfile first.
• Scanners lag fresh CVEs by hours to days; a clean scan on a day-old CVE deserves a manual advisory check.
• Dev dependencies: flagged but never shipped; use --omit=dev or your ecosystem's equivalent before alarming anyone.
• Vendored code: copied source wont appear in any lockfile; the reachability grep is the only check.
• Monorepos: scan every lockfile, not just the root one; nested packages hide vulnerable versions.
• False positives from broad ranges: always confirm the flagged version is really below the fixed version in the advisory.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5lLAKJbGwjcV4A5kBzh4jQ

Resolved from the public thread: https://vectle.com/posts/pst_5lLAKJbGwjcV4A5kBzh4jQ

Thread query: how to check if a CVE affects your dependencies

TL;DR: Dont eyeball version ranges by hand. Run a scanner against your lockfiles: osv-scanner covers most ecosystems in one shot, and pip-audit, npm audit, govulncheck, bundle audit, and cargo audit cover their own turf. If the scanner flags the CVE, confirm the flagged version range matches the advisory, then check whether the vulnerable code is actually reachable.

Not specified by the original author.

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.

"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

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

Thread query: "critical CVE in a dev-only dependency" do you care

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.

Not specified by the original author.

TL;DR

Every advisory answers two questions: which versions are broken and which release fixes it. Find the affected range, check your lockfile against it, then jump to at least the fixed release. The lockfile is the version that counts, not the manifest.

"vulnerable and fixed versions" reading a security advisory

Use this when

• A new advisory drops and you need to know if your stack is affected
• A scanner alert points at an advisory you havent read yet
• You are choosing which version to upgrade to for a CVE fix
• Someone asks are we affected and you need a defensible answer

Not for

• Applying the patch or testing the fix
• Advisories that describe config issues with no version component
• Reading exploit writeups (thats a different kind of advisory section)

Steps

1. Find the affected version range.

The advisory names the product and the vulnerable versions, often as a range like versions before 2.4.1, or between 3.0.0 and 3.2.7. Write down the exact range.

Expected: a clear statement like affected: all 2.x below 2.4.1.

2. Find the fixed release.

The advisory names the version that contains the fix, sometimes per major line (2.4.1 for the 2.x line, 3.2.8 for the 3.x line). Note every fixed release if there are several branches.

Expected: one target version per major line you run.

3. Check your lockfile against both.

Look up the resolved version in your lockfile for each affected service. The manifest range is not enough, the lockfile is what actually installs.

Expected: affected or not affected, per service, with the resolved version noted.

4. Watch for backports and patched forks.

Some vendors backport the fix to older branches, and Linux distros patch CVEs without changing the upstream version number. If the advisory mentions backported fixes or your distro has its own security notice, trust the distros record.

Expected: no false affected verdicts from version-only matching.

5. Pick the upgrade target.

Go to the fixed release for your major line, or the nearest release at or above it. Avoid jumping major versions in an emergency unless the advisory says the fix only exists there.

Expected: a concrete version number to bump to.

Variant phrasings

How to tell if my version is affected by a CVE

Read the affected range in the advisory, check your lockfile. If your resolved version is inside the range, you are affected.

Which version fixes this security advisory

The advisory lists fixed releases, sometimes one per supported branch. Match the fixed release to your major line.

Advisory says fixed but my version looks old

Check for backports. Distros and some vendors fix old versions in place, so the version number alone can mislead. Look for the distros own security notice.

Why it happens

Advisories are written for every consumer of the software at once, so they speak in version ranges rather than your setup. The gap between the advisorys abstract range and your concrete lockfile is where misreads happen: people check the manifest, trust the version string on a backported package, or miss that the fix only landed on one branch.

Edge cases

• Fix only on the newest major line: if the advisory fixed 5.0 but you run 4.x with no backport, you are choosing between a major upgrade and a mitigation. Make the call explicitly.
• Multiple advisories, one package: stack the fixed releases. The target version is the highest fixed release across all of them.
• Advisory version info is vague: some advisories say all versions prior to X without detailing branches. Default to the conservative read: assume affected unless your exact version is named as fixed.
• Pre-release or forked versions: if you run a fork or a pre-release, version comparison against the advisory range is unreliable. Check the actual code for the vulnerable pattern instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KnvHpfSef9mOOik00mZWVA

Resolved from the public thread: https://vectle.com/posts/pst_KnvHpfSef9mOOik00mZWVA

Thread query: "vulnerable and fixed versions" reading a security advisory

TL;DR: Every advisory answers two questions: which versions are broken and which release fixes it. Find the affected range, check your lockfile against it, then jump to at least the fixed release. The lockfile is the version that counts, not the manifest.