On this page
How to Generate an SBOM for Your Project
Generate an SBOM with Syft in one command, scan it with Grype for vulnerabilities, and add it to CI. A practical tutorial.
Quick answer
- Use Syft to generate an SBOM from your source or container image in one command.
- Use Grype to scan that SBOM against known vulnerabilities.
- Wire both into CI so every build produces an up-to-date inventory.
What you’ll build
A repeatable, automated SBOM for a Node.js project: generate the inventory with Syft, scan it for vulnerabilities with Grype, and add the step to your pipeline so it runs on every release.
Step 1 — Install the tools
# macOS (Homebrew)
brew install syft grype
# Or download binaries from the Anchore releasesHow to verify it worked: syft version and grype version both print a version.
Step 2 — Generate the SBOM
From your project root:
syft . -o cyclonedx-json > sbom.jsonThis inventories your source and dependencies into a CycloneDX SBOM. How to verify it worked: sbom.json exists and lists your direct and transitive dependencies with versions.
Step 3 — Scan for vulnerabilities
grype sbom:./sbom.jsonHow to verify it worked: Grype prints a table of findings — component, version, and the CVE or advisory ID — or reports “No vulnerabilities found.”
Step 4 — Add it to CI
Add a job to your GitHub Actions pipeline:
sbom:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: anchore/sbom-action@v0
with:
format: cyclonedx-json
- uses: anchore/scan-action@v5
with:
fail-build: true
severity-cutoff: highHow to verify it worked: a pull request introducing a high-severity vulnerable dependency fails the build.
Step 5 — Store and review
Commit or publish the SBOM with each release, and review it for unexpected components. An unfamiliar dependency in the inventory is itself a finding — the first sign of a supply chain attack.
Where this bites vibecoders
The SBOM’s value for a vibecoder is visibility into the transitive dependencies the assistant pulled in without showing you. Generating it is a one-liner, and the first run usually reveals surprises: components you didn’t ask for, sometimes with known vulnerabilities. Make it a release artifact, not a one-time curiosity.
Where AI coding assistants get this wrong
- Adding many transitive dependencies with no inventory.
- Never wiring SBOM or vulnerability scanning into the build.
- Suggesting a manual dependency review where an automated SBOM would do.
Checklist
- Generate the SBOM from source and from the built image.
- Output a standard format (CycloneDX or SPDX).
- Scan the SBOM for vulnerabilities and fail on high severity.
- Publish the SBOM with each release.
- Review for unexpected components and licenses.
FAQ
What is the difference between Syft and Grype?
Both come from Anchore. Syft generates the SBOM (the inventory); Grype scans that inventory against vulnerability databases to find known issues. They’re designed to work together.
Should I scan source or the container image?
Both. The source SBOM covers what you depend on; the image SBOM covers what actually ships, including system packages added in the container. An image scan catches things the source scan can’t.
What severity should fail the build?
Start by failing on high and critical, and report lower severities. Over-blocking produces alert fatigue; under-blocking defeats the purpose. Revisit the threshold once noise settles.