dependency-audit

Dependency audit

Most of the code shipping in a typical application was written by strangers. An audit answers three questions about that code: is it dangerous, is it legal, and is it maintained.

Scanners answer the first well. The second and third need judgement, and they are where the expensive surprises live — a licence discovered at acquisition, a critical library abandoned three years ago.

1. See the whole tree, not the manifest

Your manifest lists what you asked for. The lockfile lists what you got, and it is usually five to twenty times larger.

npm ls --all | wc -l          # or: pip list, go list -m all, cargo tree

Transitive dependencies are where most risk sits, because nobody chose them. Note the depth and the total count — a project with 1,400 packages has a different risk profile from one with 40, whatever the direct list looks like.

Done when: you are working from the resolved tree, not the manifest.

2. Run the scanners, then triage the output

npm audit --json          # pip-audit, govulncheck, cargo audit, osv-scanner

Scanner output is not a finding list; it is a starting list. Triage each:

• Is the vulnerable code path reachable from your usage? A deserialization CVE in a library you only use for formatting is not exploitable. govulncheck does this analysis properly; most tools do not.
• Is it a dev dependency? A vulnerability in a build tool is real but has a different threat model than one in the server.
• Severity is not priority. A critical in an unreachable path ranks below a medium in your request-handling path.

Report reachability explicitly. A list of 200 unreviewed advisories teaches people to ignore the scanner, which is worse than not running it.

Done when: each advisory is triaged for reachability, not just listed.

3. Check licences before they become expensive

Licence problems surface at the worst moments — an acquisition, an enterprise sale, a distribution change, and are costly to fix retroactively.