SBOM Generation and Scanning with Syft and Grype [2026]

In 2026, the software supply chain is under constant scrutiny, making Software Bill of Materials (SBOM) generation a non-negotiable requirement for enterprise security compliance. As regulatory frameworks like Executive Order 14028 mature, developers need lightweight, high-performance tools that don't bottleneck the deployment cycle. Enter Syft and Grype—the industry-leading duo for identifying every component in your stack and instantly surface-mapping known vulnerabilities. This tutorial breaks down how to weaponize these tools within your CI/CD pipeline for maximum security ROI.

Prerequisites

Before initiating the automation sequence, ensure your environment meets the following baseline requirements:

• Docker or Podman installed and running (for containerized workloads).
• A functional Go environment (optional, if building from source).
• Access to a CI/CD platform (e.g., GitHub Actions, GitLab CI, or Jenkins).
• Basic familiarity with JSON and YAML syntax.

Step 1: Generating SBOMs with Syft

Syft is an CLI tool and library for generating a Software Bill of Materials from container images and filesystems. It excels at cataloging packages from major ecosystems including npm, PyPI, RubyGems, and Go modules.

Installing Syft

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

Generating Your First SBOM

To generate an SBOM for a standard Node.js container image in the industry-standard CycloneDX format, execute:

syft node:latest -o cyclonedx-json > node-sbom.json

This command performs a deep scan of the image layers, identifies the base OS (e.g., Debian or Alpine), and catalogs every installed library. When handling sensitive security reports, similar to using a Data Masking Tool to protect internal PII, ensure your generated SBOMs are stored in secure, encrypted storage if they contain proprietary component metadata.

Step 2: Vulnerability Scanning with Grype

Once you have a valid sbom.json, Grype takes over. Unlike traditional scanners that re-scan the entire image, Grype consumes the SBOM directly, matching it against its locally cached vulnerability database.

Installing Grype

curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

Running the Scan

Point Grype to your Syft-generated SBOM to find CVEs:

grype node-sbom.json --fail-on high

The --fail-on high flag is critical for automation; it ensures the process exits with a non-zero code if any High or Critical vulnerabilities are detected, effectively stopping a compromised build in its tracks.

Step 3: CI/CD Pipeline Integration

The true power of these tools lies in automation. Below is a production-ready GitHub Actions workflow that automates the entire process whenever a new Docker image is built.

name: Security Audit
on: [push]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Build Local Image
        run: docker build -t my-app:local .

      - name: Generate SBOM (Syft)
        uses: anchore/sbom-action@v0
        with:
          image: my-app:local
          format: cyclonedx-json
          output-file: ./sbom.json

      - name: Scan SBOM (Grype)
        uses: anchore/scan-action@v3
        with:
          sbom: ./sbom.json
          fail-build: true
          severity-cutoff: high

Verification & Expected Output

Successful execution should yield a clean bill of health. In your CI logs, you should see a structured table similar to the following:

• NAME: The package name (e.g., libssl1.1).
• INSTALLED: The version found in your image (e.g., 1.1.1n-0+deb11u3).
• VULNERABILITY: The CVE ID (e.g., CVE-2026-12345).
• SEVERITY: The impact level (Critical, High, Medium, Low).

Troubleshooting Top-3 Issues

1. Database Update Failures: If Grype fails to start, it’s often due to a stale vulnerability database. Run grype db update to force a refresh. Ensure your CI runner has outbound HTTPS access to toolbox-data.anchore.io.
2. False Positives in Distroless: Minimal images like Google Distroless can sometimes confuse scanners. Ensure you are using the latest version of Syft (v1.2+) which has enhanced heuristics for symbol-table scanning in binary-only environments.
3. SBOM Format Mismatches: If Grype reports an "unsupported format," verify that Syft is outputting cyclonedx-json or spdx-json. Avoid the legacy text format for automation purposes.

What's Next: VEX and Attestations

Generating an SBOM is just the beginning. To reach SLSA Level 3 compliance, you should explore:

• Cosign: Sign your SBOMs and container images to ensure integrity.
• VEX (Vulnerability Exploitability eXchange): Use VEX documents to suppress false positives or vulnerabilities that are not exploitable in your specific configuration.
• Dependency Track: Feed your Syft SBOMs into a central management server to track component sprawl across your entire organization.