Handle vulnerabilities

Scan the complete release

Check application dependencies, container packages, build tools, workflow components, and released artifacts without confusing scan coverage with proof of safety.

One package-manager audit sees one part of the supply chain. The shipped artifact may contain much more.

Here is the trap. A package-manager audit reports no findings, but the deployed container includes a vulnerable system library and an old workflow action. Each scanner sees only the ecosystem it understands, so “the scan is green” quietly means “the part we scanned is green”.

Layer the scanners

Start with the npm graph:

npm audit
# found 0 vulnerabilities

This checks your lockfile against the npm advisory database. Add osv-scanner, which queries the cross-ecosystem OSV database and often knows advisories npm does not:

osv-scanner --lockfile=package-lock.json

Its output is a table: one row per finding, with the OSV ID, package, installed version, and the lockfile that introduced it.

Neither tool sees the operating-system packages in your container. For the final image, use trivy:

trivy image ghcr.io/acme/api:1.4.2
# libcrypto3 (CVE-2024-…) HIGH  installed: 3.1.4-r5  fixed: 3.1.4-r6

That fixed: column tells you a base image rebuild resolves it. Finally, remember workflow components: outdated GitHub Actions are dependencies too, and Dependabot can watch them.

State the coverage boundary

Keep advisory data current — a scanner with a stale database gives stale answers. Use multiple signals where the risk warrants it, and record which ecosystems and artifact types the scan does not cover. A coverage table with five rows (source dependencies, build tools, workflow components, container packages, final artifact) makes the missing signal visible instead of assumed.

More scanners also create duplicate and false-positive work. The same CVE will appear from npm audit, osv-scanner, and trivy at once. Triage one finding once, and route each class of finding to one owning tool.

A clean scan is not proof of safety. It means no known advisory matched the components the scanner could see, today.

Create a coverage table for source dependencies, build tools, workflow components, container packages, and the final artifact. Save one scan result for each covered class and name every uncovered class. Add a known safe test fixture or outdated disposable package and prove the expected scanner detects it without treating detection as proof of exploitability.

Lesson completed

Take this course offline

Get every free book, course edition, and software download.

Get the download library →