Dependency vulnerability scanning
Automatically matching your installed packages against a database of known holes, so you hear about a bad version before an attacker uses it.
See it
What it is
A scanner reads your lockfile, resolves the full tree including transitive dependencies, and matches every package and version against a public advisory database (the GitHub Advisory Database, OSV, the NVD). Anything matching a known advisory comes back with a severity and, usually, the version that fixes it. Advisories are the unit here, not CVEs: plenty of GitHub and OSV entries never get a CVE ID assigned, and you still want to hear about those. 'npm audit' is the built-in version; Dependabot and Renovate open the upgrade pull requests; Snyk, Trivy, and osv-scanner cover containers and non-JS ecosystems too.
Run it in CI on every pull request, not once a quarter, because the risk is not that you installed something bad, it is that the flaw in what you installed two years ago was only disclosed last Tuesday. The code did not change; the world's knowledge of it did, which is why a frozen lockfile still gets less safe over time. Pair it with automated dependency updates, otherwise the scanner just accumulates a backlog everyone learns to scroll past.
Gotcha: severity is not exploitability. A 'critical' in a dev-only build tool that never touches user input matters less than a 'moderate' in your auth path, and reachability (does your code actually call the vulnerable function?) is the question the score does not answer. Also resist 'npm audit fix --force': it will happily downgrade or major-bump your tree and break the build to silence a warning.
Ask AI for it
Set up dependency vulnerability scanning for this repo. Add a CI job that runs the ecosystem audit command (npm audit / pip-audit / cargo audit as appropriate) plus osv-scanner against the lockfile, and make it fail the build only on high and critical findings in production dependencies, warning on dev dependencies. Add Dependabot or Renovate config for weekly grouped update pull requests with security updates opened immediately. Then run the scan once now and give me a table of each finding: package, installed version, advisory ID (CVE, GHSA, or OSV), severity, fixed version, and whether it is a production or dev dependency. Add a reachability column classifying each one as reached, potentially reached, not reached, or unknown, and cite the evidence for the call: the import, the call site, whether the package is even included in the build, or output from a reachability tool. Use 'unknown' freely. Never conclude 'not exploitable' just because a text search found nothing.