Developer Productivity
SBOMs & Supply Chain Security: A Practical npm Audit Workflow
Dependency trees grow faster than anyone audits them. Here is a concrete workflow for generating SBOMs, triaging npm audit output, and knowing which alerts are actionable.
The npm ecosystem installs fast because it installs everything. An innocent npm install react pulls in over a thousand packages. Every one of those packages is a vector.
Software Bill of Materials (SBOMs) emerged as the industry answer. An SBOM is a machine-readable inventory of every component in your application.
Generating an SBOM from npm
Run: npm sbom --sbom-format=cyclonedx > sbom.cyclonedx.json
This produces a CycloneDX document listing every direct and transitive dependency with version, license, and registry metadata.
The triage pipeline: turning alerts into decisions
Run npm audit --json and filter for high and critical severity. Then review each against three rules:
Rule 1: Is the vulnerable function reachable from your code? Rule 2: Is the vulnerability in a development dependency? Rule 3: Is there a known fix or a safe version range?
Most CVEs reported by npm audit are real vulnerabilities that your specific application cannot reach.
Automating SBOM generation in CI
Set up a GitHub Actions workflow that runs npm sbom on every push and uploads the result as an artifact. For extra confidence, upload to a dependency-analysis service like Dependency-Track.
The one thing that actually prevents supply chain attacks
Never use npm install in CI. Run npm ci with a committed lockfile. npm verifies every package against its stored integrity hash before extracting. If the tarball does not match, the install fails. This is the single most impactful security practice.
Takeaways
- Generate an SBOM every build.
- Triage audit output: focus on reachable, runtime, unpatched vulnerabilities.
- Automate SBOM generation in CI.
- Never run npm install in CI. Use npm ci with integrity verification.