dependency-audit

原文涵盖的主题

• Dependency audit
• 1. See the whole tree, not the manifest
• 2. Run the scanners, then triage the output
• 3. Check licences before they become expensive
• 4. Assess maintenance, which no scanner does
• 5. Look for supply chain smells
• 6. Reduce the surface
• Report

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. Your manifest lists what you asked for. The lockfile lists what you got, and it is usually five to twenty times larger. 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. 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

这里只展示节选，请以完整原文和当前要求为准。