auditing-supply-chain

Auditing Supply Chain

Your build pipeline runs more untrusted code than your application does. A single unpinned action, a postinstall script, or a workflow with a writable token is a path from a stranger's commit to your production artifacts and your signing keys.

When to Use

• Assessing risk from third-party dependencies in an application
• Reviewing CI/CD pipelines, GitHub Actions, and release automation
• Investigating a suspicious or malicious package
• Producing or reviewing an SBOM
• Hardening build provenance and artifact signing
• Responding to a disclosed upstream compromise

When NOT to Use

• Vulnerabilities in first-party code — use auditing-code-for-vulnerabilities
• Model and dataset provenance — use securing-ai-systems
• Cloud infrastructure posture generally — use exploiting-cloud-platforms for offensive assessment
• An in-progress compromise — use responding-to-incidents
• Prioritizing which of many dependency CVEs to fix first — use managing-vulnerabilities; reachability analysis here feeds its ranking

Two Different Risks

Keep them separate; they need different responses.

	Known-vulnerable dependency	Malicious dependency
Detection	CVE databases, npm audit, osv-scanner	Behavioural review, install scripts, publisher anomalies
Signal	Loud and well-tooled	Quiet; scanners usually miss it
Response	Patch, or justify the risk	Incident — assume credentials on the build host are burned
Time pressure	Days to weeks	Hours

Most programs handle the first and are blind to the second. Give the second explicit attention.

Dependency Review

# Known vulnerabilities, ecosystem-agnostic
osv-scanner --lockfile=package-lock.json --lockfile=go.sum --lockfile=Cargo.lock
trivy fs --scanners vuln,secret,misconfig .
grype dir:.

# Ecosystem-native
npm audit --omit=dev && npm ls --all --depth=99 | wc -l   # count transitives
pip-audit -r requirements.txt
cargo audit
govulncheck ./...    # reachability-aware: only reports vulns you actually call
mvn dependency-check:check