how to audit transitive dependencies for vulns

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.

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.

npm supply chain: how to audit your lockfile

TL;DR

Your lockfile is the actual list of code you ship, so audit it, not just package.json. Run npm audit for known CVEs, read the lockfile diff on every dependency PR for unexpected packages and changed registry URLs, hunt for unfamiliar postinstall scripts (the classic malicious-package move), and enforce dependency review in CI so nobody merges a sketchy update unreviewed. Most supply-chain attacks arrive as boring-looking version bumps.

npm supply chain: how to audit your lockfile

Use this when

• npm audit reports vulnerabilities and you need to work through them
• A dependency update looks sketchy and you want to check it
• You are writing a dependency-review policy for a team
• A security report names a compromised npm package and you need to check exposure

Not for this skill when

• You need general npm help (install, scripts, publishing)
• Your supply chain is Python, Go, or another ecosystem (same ideas, different tools)
• You want to vet a package before first install (use the pre-install checks in the variants)

Steps

1. Run the audit and read it properly

npm audit

Expected: a table of vulnerabilities with severity, the affected package, and whether a fix is available. Remember what audit does not cover: it only knows about reported CVEs, not malicious packages that nobody has reported yet. A clean audit is not a clean bill of health.

2. Fix what is fixable, carefully

npm audit fix

Expected: the lockfile updates for non-breaking fixes. For breaking changes, review the audit output and update the direct dependency manually. Never run audit fix with force in CI unattended, it can upgrade you into breakage or into a compromised version just as easily as out of one.

3. Read the lockfile diff on every dependency PR

git diff package-lock.json | grep -E "^[+-].*(resolved|version)" | head -30

Expected: a short, reviewable list of changed versions and resolved URLs. Red flags: a resolved URL pointing anywhere other than the npm registry, a major version jump in a patch PR, or brand-new transitive dependencies you did not expect. This diff is where compromised-package updates are visible.

4. Hunt for unfamiliar install scripts

grep -o '"postinstall": "[^"]*"' package-lock.json | sort | uniq -c | sort -rn | head

Expected: a short list of postinstall scripts. Install scripts run arbitrary code at install time, which is exactly how malicious packages execute. If you do not recognize a script, look at the package: check its publish history, maintainers, and whether the script existed in the previous version.

5. Find out why a package is even there

npm ls [package-name]

Expected: the dependency chain showing which direct dependency pulled it in. A suspicious transitive package three levels deep under a dependency you barely use is a different conversation than a direct dependency you chose.

Variant: enforce review in CI

Add dependency review to your pull request workflow so PRs that introduce vulnerable or unexpected dependencies get flagged automatically before merge. Configure it to fail on high-severity findings and to require a human look at new packages.

Variant: vetting a package before first install

Check the package's publish history and maintainers for sudden changes, look at download counts and repository activity, and prefer well-maintained packages with multiple maintainers. A package that changed hands last week and immediately published a "patch" deserves a hard look.

Variant: npm audit signatures

Run npm audit signatures to verify that the packages in your node_modules carry valid registry signatures. It catches tampering between the registry and your machine, not a compromised maintainer, but it is cheap to run.

Why this happens

Modern apps have hundreds or thousands of transitive dependencies, and attackers know nobody reads them. The successful npm attacks of the last few years followed the same playbook: compromise a maintainer account or a popular package, publish a patch version with a malicious postinstall script, and wait for automated updates to do the rest. The lockfile diff is the cheapest place to catch it.

Edge cases and pitfalls

• npm audit is noisy about dev-only dependencies that never ship. Triage by what reaches production.
• False positives happen, especially with bundled or vendored copies. Confirm before burning a day.
• npm ci respects the lockfile exactly, npm install can update it. CI should always use npm ci.
• Private registries need audit configured against them or the audit silently covers nothing.
• Lockfile version matters. If the repo mixes lockfile versions across branches, diffs get unreadable. Standardize on one.
• A compromised package with no CVE will sail through npm audit. The diff review and script hunt are your backstop.

Tool notes: npm 9+ for current audit output. The dependency review action runs on GitHub Actions.

Provenance

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

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

Thread query: npm supply chain: how to audit your lockfile

TL;DR: Your lockfile is the actual list of code you ship, so audit it, not just package.json. Run npm audit for known CVEs, read the lockfile diff on every dependency PR for unexpected packages and changed registry URLs, hunt for unfamiliar postinstall scripts (the classic malicious-package move), and enforce dependency review in CI so nobody merges a sketchy update unreviewed. Most supply-chain attacks arrive as boring-looking version bumps.