how to assess CVE reachability in your codebase

Not specified by the original author.

how to assess CVE reachability in your codebase

TL;DR

A CVE in a dependency you never call is not your emergency. Find where the vulnerable package is imported, trace whether the vulnerable function or code path is actually invoked, and check whether the vulnerable feature is enabled in your config. Reachable plus exposed equals urgent; anything else can be scheduled.

how to assess CVE reachability in your codebase

Use this when

• A scanner flags a CVE in a dependency and you need to judge real exploitability
• Leadership asks whether a headline CVE actually affects your product
• You are deciding patch-now versus schedule for a batch of findings
• A vendored or transitive dependency is flagged and the scanner gives no call path

Not for this skill when

• You are triaging the CVE itself (severity, advisory facts, exploitation signals)
• The CVE is in your own first-party code (fix it; reachability is not the question)
• You need automated reachability at scale across many repos (that is a platform project, these are the manual primitives)

Steps

1. Confirm the vulnerable package and version are really present

Trust the lockfile, not the manifest. Check the resolved version against the advisory's affected range.

npm ls [package-name]

Expected: the resolved version tree showing the package at a vulnerable version, or proof it is not there. Ecosystem equivalents: pip show [package-name], go list -m all | grep [module]. If the vulnerable version is not in the tree, stop here.

2. Find every import and call site

Search the codebase for imports of the package and calls to the vulnerable function named in the advisory.

grep -rn "[vulnerable-function-or-import]" src/ --include="*.py"

Expected: a concrete list of call sites, or zero hits. Zero hits in first-party code does not fully clear a framework-level dependency, but it strongly downgrades urgency; note it and move to step 3.

3. Trace the call path to an entry point

For each call site, follow the chain upward: is it reachable from a request handler, a CLI command, a cron job, or only from dead code and tests? A parser CVE in a function only your test suite calls is not reachable in production.

Expected: a short call chain per site ending at a real entry point, or chains that dead-end in unused code. Document the chain; "reachable" without the path written down gets re-litigated next quarter.

4. Check whether the vulnerable feature is enabled

Many CVEs live behind a config flag, an optional module, or a protocol you never serve. Check your config and your server setup.

Expected: either the feature is on and reachable (patch now) or off and unreachable (schedule). A CVE in TLS 1.0 handling on a server that only negotiates 1.2 and up is the classic downgrade.

5. Record the verdict with evidence

Write down the CVE ID, the call path or the reason it is unreachable, and the decision. Future you will thank present you.

Expected: one entry in the triage log with the evidence attached. Reachability analysis that is not written down gets repeated from scratch.

Variant: reachability in a monorepo with many services

Run the import search per service and map results to deployables. One vulnerable package can be reachable in the API service and dead code in the worker; the verdict is per service, not per repo.

Variant: using Semgrep for reachability at scale

Write a Semgrep rule matching the vulnerable call pattern and run it across repos in CI. It automates step 2; steps 3 and 4 still need a human for the interesting cases.

Why this happens

Scanners match package names and versions, which is a dependency-graph fact, not an execution fact. Reachability asks the execution question: does attacker-controlled input actually flow into the vulnerable code in your deployment? Most of the time the answer is no, which is why this analysis saves so many unnecessary emergency patches.

Edge cases and pitfalls

• Dynamic imports and plugin systems hide call sites from grep; check config-driven loading too.
• Transitive dependencies: the import may live in a library you depend on, not your code; check the intermediate package's usage.
• Feature flags can flip at runtime; verify the production flag state, not the default.
• Vendored code: copied source has no package metadata, so scanners miss it and grep is the only backstop.
• Native extensions: a CVE in a C extension may be reachable through a safe-looking wrapper; check what the wrapper actually calls.

Provenance

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

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

Thread query: how to assess CVE reachability in your codebase

TL;DR: A CVE in a dependency you never call is not your emergency. Find where the vulnerable package is imported, trace whether the vulnerable function or code path is actually invoked, and check whether the vulnerable feature is enabled in your config. Reachable plus exposed equals urgent; anything else can be scheduled.

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

Your direct dependencies are the tip of the tree. The real risk lives three layers down where libraries you never chose get pulled in silently. Resolve the full tree from the lockfile, scan every layer, and triage by whether the vulnerable code is reachable from your app.

how to audit transitive dependencies for vulns

Use this when

• Your direct dependencies are clean but the dependency tree is deep
• A CVE drops in a library you dont directly depend on
• Before a release, as a supply-chain sanity check
• You inherited a project and nobody knows what is really in the tree

Not for

• Auditing your own first-party code
• License compliance of the tree (related, different goal)
• Runtime behavior analysis of dependencies

Steps

1. Resolve the full tree from the lockfile.

Use your package managers tree command against the lockfile to list every transitive dependency with its resolved version. The lockfile is the truth, the manifest is a wish.

Expected: a complete flattened list of package plus version for the whole tree.

2. Scan the whole tree, not just the top layer.

Run your vulnerability scanner against the lockfile so it evaluates transitive packages too. Confirm the scanner is configured to include transitive deps, some default to direct-only.

Expected: findings that include packages you never directly added.

3. Map each finding to its root.

For every flagged transitive package, trace which direct dependency pulls it in. Fixing happens at the root, not at the leaf.

Expected: each alert annotated with the root package responsible for it.

4. Triage by reachability.

Check whether your app actually exercises the vulnerable code path. A vulnerable function in a transitive dep that your code never calls is low priority. One on your hot path is not.

Expected: findings split into reachable and unreachable, with evidence noted.

5. Fix at the root.

Upgrade the root dependency to a version that pulls the fixed transitive version, or add an explicit override or resolution forcing the patched version. Verify the tree resolves clean after.

Expected: the tree re-resolves with the vulnerable version gone.

6. Lock it in.

Commit the updated lockfile and add the scan to CI so the tree cant silently regress. Future dependency adds get scanned before merge.

Expected: CI fails on new vulnerable transitive deps.

Variant phrasings

How to find vulnerabilities in dependencies of dependencies

Resolve the full tree from the lockfile and scan it with transitive coverage enabled. Thats the whole technique.

Scanner only checks direct dependencies

Reconfigure it to read the lockfile. If your scanner cant do transitive, switch scanners, because direct-only is theater.

How to fix a CVE in a transitive dependency

Upgrade the root package that pulls it in, or force the patched version with an override. Never hand-edit the lockfile entry for the leaf alone.

Why it happens

Package managers resolve transitive dependencies automatically and silently, so your tree grows without anyone choosing those packages. Vulnerability databases track every package version, but scanners that only read your manifest never see the transitive layers. The gap between what you chose and what you ship is where these CVEs hide.

Edge cases

• Diamond dependencies with conflicting versions: two roots pull different versions of the same transitive package. The resolver picks one, and the losing version might be the vulnerable one. Check the resolved version, not the requested ones.
• No fixed version at the root: if no root upgrade pulls the fix, force the patched transitive version with an override and test. Overrides can break the root, so test the feature that uses it.
• Huge tree, hundreds of findings: triage reachable first, then batch the rest into root upgrades. Dont try to fix leaves one by one.
• Lockfile out of sync with the manifest: regenerate the lockfile before the audit. An audit against a stale lockfile audits a tree you dont actually ship.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstxtifKfMMl-St4aRmeBvUQ

Resolved from the public thread: https://vectle.com/posts/pstxtifKfMMl-St4aRmeBvUQ

Thread query: how to audit transitive dependencies for vulns

TL;DR: Your direct dependencies are the tip of the tree. The real risk lives three layers down where libraries you never chose get pulled in silently. Resolve the full tree from the lockfile, scan every layer, and triage by whether the vulnerable code is reachable from your app.