Dependency Vulnerabilities

Step 1 — Automated scan (needs network)

python3 scripts/osv_scan.py <project_root>

Stdlib-only Python; parses lockfiles → queries the OSV.dev batch API → prints per-finding: advisory ID, aliases (CVEs), severity, and fixed versions. Read the script's header for supported manifests.

Interpretation rules:

• A finding is CRITICAL if the advisory lists a fix AND the vulnerable code path is plausibly reachable from the app's usage (check require/import sites), or if it's on the CISA KEV list.
• Unreachable-but-present → HIGH (upgrades are cheap insurance).
• No fixed version available → note "no fix released yet; mitigation required" and check for vendor workarounds.

Reachability (turn "present" into "used" or "dormant") — the severity multiplier for every finding above:

rg -n "require\(['\"]<pkg>|from ['\"]<pkg>|import <pkg>" -g '!*.lock'          # who imports it
rg -ln "require\(['\"]<pkg>" | rg "(routes|controllers|api|handlers|server|app)"  # do ROUTES reach it?

A vulnerable dep imported only by a build script is DORMANT (note + upgrade); imported from a request path is LIVE (severity stands). When node_modules/ is present, confirm the RESOLVED version matches the lockfile (cat node_modules/<pkg>/package.json | grep version) — vendored drift is common.

Step 2 — Manifest hygiene (no network needed)

Check and report:

rg --files -g 'package.json' -g 'pyproject.toml' -g 'Cargo.toml' -g 'go.mod' \
   -g 'Gemfile' -g 'composer.json' -g 'pom.xml' | head

• No lockfile for an existing manifest (e.g. package.json without package-lock.json) → HIGH: builds are non-reproducible, a malicious/patched transitive dep can slip in silently.
• latest / * / caret-wide ranges in prod manifests → MEDIUM: pin via lockfile at minimum.
• Direct git URLs / tarball URLs instead of registry versions → HIGH (unpinned supply chain).
• Install scripts risk: postinstall hooks in npm projects — list which deps have them if package.json shows lifecycle scripts.
• Deprecated/archived packages: request, node-uuid, colors/faker (history of compromise), querystring, mkdirp@0, moment (maintenance mode). Check against current knowledge; see ../cve-research/SKILL.md for live checks.

Step 2.5 — Supply-chain hygiene (A08: confusion & typosquats)

• Dependency confusion: internal/scoped package names (@corp/..., corp-*) that resolve on PUBLIC registries → an attacker publishes that name and CI installs theirs. Check each internal-looking name:

rg -o '"@?[\w.-]+/[\w.-]+"|"[\w.-]+"' package.json | sort -u   # candidate names
npm view <name> versions --json 2>/dev/null || echo "not on public registry (good)"

With network: a npm view that SUCCEEDS for an internal name = CRITICAL (register a namespace/proxy instead). Without network: list internal-looking names for manual verification. Same check for pip (pip index versions) and Go private modules (GOPRIVATE vs proxy.golang.org reachable names).

• Typosquat heuristics: dependency names at edit-distance 1 from popular packages (reqeusts, lodash2, expresss, colors-2, -js suffixed clones of core names) → HIGH until verified legitimate. Notable real-world families: event-stream, ua-parser-js, node-ipc, coa, rc hijacks — names matter less than the SHAPE: unpopular package, recently published, exact-near-famous-name.
• Provenance & lockfile INTEGRITY (Trail of Bits 25-package-manager test, 2026-10-14: blog.trailofbits.com/2026/10/14/package-managers-have-an-integrity-problem/): lockfile PRESENCE ≠ integrity — per-PM verification matrix vs a malicious registry/package mirror:
  • Verified by default: Go (sumdb), vcpkg — nothing to flag.
  • Verified IFF lockfile present: npm, pnpm, yarn, Bun, Cargo, Poetry, uv, Bundler, SwiftPM → the no-lockfile row above IS the integrity finding for these.
  • Lockfile + EXTRA steps: pip, NuGet, Conda, Gradle, Pub — pip needs --require-hashes (or pip-compile --generate-hashes):

    rg -n -- "--require-hashes" requirements*.txt   # no hit + pip ecosystem → MEDIUM: integrity not enforced

  • NOT verified even with lockfile: Composer, Maven, Gem, Conan, CocoaPods, R → informational note: content integrity rests on registry TLS + review alone; prefer private verified mirrors / sigstore-style signing where available.
• Registry-signature verification: only Go verifies by default; npm/Bundler/Maven/NuGet/Gradle support it with configuration — absence of verify config in CI install steps → MEDIUM note (same ToB matrix).

Step 2.7 — Beyond CVEs: dead, dangerous, and vendored packages

Advisory databases are silent on four classes that hit "clean main code, compromised system" — run the full pack in references/dangerous-packages.md:

1. Discontinued/unfixable (vm2, request, …): flagged by PRESENCE, not advisory — any version is a finding when usage is security-relevant
2. Compromised-release history (event-stream 3.3.6, ua-parser-js 0.7.29/0.8.1/1.0.12, eslint-scope 3.7.2, coa/rc 2021, node-ipc 11.x, cross-env 7.0.x): exact-version greps, zero network needed; a match means postinstall RAN — rotate credentials
3. Dangerous usage of safe packages (lodash.merge(req.body), qs allowPrototypes, compile(userInput)): call-site risk, version is irrelevant
4. Vendored/bundled copies (old jQuery/moment/AngularJS committed under public//vendor/dist): invisible to every manifest scanner — read the version banners

Reachability verdicts from Step 1 apply here too: vm2 present AND new VM() reachable from a route is a different finding than vm2 in devDependencies.

Step 3 — Runtime EOL check (live, free — endoflife.date)

For each runtime/framework/DB the project pins (from Phase 0 recon), check end-of-life status:

curl -s https://endoflife.date/api/nodejs.json | jq -r '.[] | "\(.cycle)  eol=\(.eol)  latest=\(.latest)"' | head -5

Common products: python, nodejs, php, ruby, go, laravel, django, rails, ubuntu, debian, alpine, postgresql, mysql, redis, mongodb, nginx, kubernetes. Compare the installed major/minor prefix against eol dates:

• Installed version past EOL → HIGH: no security fixes will ever arrive — upgrade path only
• Within 6 months of EOL → MEDIUM (plan the upgrade)
• Note latest in the report so the user sees the gap concretely

Step 4 — Prioritize output

Group findings: (a) fix available + reachable → do now; (b) fix available → next patch window; (c) no fix → mitigation notes (config workaround, feature flag off, WAF rule, virtual patching).

For each finding give: package@installed_version, advisory ID + CVE aliases, severity, fixed-in version, and the exact upgrade command for the package manager in use (npm install x@^y, pip install -U x==y, etc.).

Notes

• If there's no network, skip Step 1, do Steps 2–3, and say so in the report.
• If OSV returns errors for one ecosystem, continue with the others — don't abort the whole scan.
• Optional bridge: if osv-scanner/npm audit/pip-audit is installed (probe: ../security-audit/scripts/probe_tools.sh), run it and merge results with the OSV API output — dedupe on package@version + advisory ID.
• Language-version vulnerabilities (e.g. outdated Python/OpenSSL) are out of scope here; note runtime versions in the report's Stack section if obviously EOL.