SBOM: Generate a Software Bill of Materials

By Khimananda Oli | Last reviewed: August 2026

Supply chain attacks now target dependencies as aggressively as application code, making visibility into every component non-negotiable for secure deployments. When you need to SBOM: Generate a Software Bill of Materials, you are creating a machine-readable inventory that maps libraries, versions, licenses, and known vulnerabilities across your entire stack. This guide walks through generating standards-compliant SBOMs using open-source tooling integrated directly into modern CI workflows, ensuring audit readiness without slowing delivery.

What is an SBOM and why must you generate one?

An SBOM (Software Bill of Materials) is effectively a nutritional label for software. It lists every direct and transitive dependency, including metadata like version hashes, supplier information, and licensing data. In 2026, regulatory frameworks like the U.S. Executive Order 14028 and EU CRA have moved from voluntary guidelines to mandatory enforcement for many sectors. For teams pursuing SOC 2 Type II or ISO 27001 certification, having an up-to-date SBOM is often the primary evidence artifact requested during vendor risk assessments.

Beyond compliance, the operational value is immediate. When a zero-day vulnerability like Log4Shell hits, querying an SBOM database takes seconds compared to days of manual grep searches across repositories. If you are already practicing Infrastructure as Code with Terraform, treating your dependency inventory as code follows the same immutable, version-controlled philosophy. You cannot secure what you cannot see, and the SBOM provides that foundational visibility layer.

How do you generate an SBOM with Syft?

Syft has emerged as the industry-standard open-source generator due to its broad ecosystem support and accuracy. Unlike older tools that relied solely on package manager manifests, Syft performs deep inspection of container layers, filesystems, and binary artifacts to identify embedded dependencies that manifests miss. This is critical when you containerize applications where multi-stage builds might obscure runtime dependencies.

Installation and basic scanning

Install Syft via the official install script or package manager. Avoid downloading random binaries; verify checksums against the GitHub release page to maintain supply chain integrity for the tool itself.

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

# Generate SBOM from a Docker image in SPDX format
syft packages docker.io/library/nginx:1.25-alpine -o spdx-json=nginx.spdx.json

# Scan a local directory (e.g., Laravel project root)
syft dir:/var/www/html -o cyclonedx-json=app.cdx.json

Choosing between SPDX and CycloneDX

Both formats are NTIA-approved minimum elements compliant. SPDX (Linux Foundation) excels at license compliance and detailed provenance, making it preferred for legal-heavy industries. CycloneDX (OWASP) was designed specifically for security use cases, with native fields for vulnerability exploitation data and service definitions. In practice, I recommend generating both if storage allows, but default to CycloneDX for DevSecOps pipelines focused on risk reduction.

How does SBOM integrate into CI/CD pipelines?

Generating an SBOM locally is useful for debugging, but value comes from automation. Every build should produce a fresh SBOM attached to the artifact. This aligns with the principles discussed in CI/CD pipeline guides: shift left, fail fast, and treat metadata as a first-class deliverable. The SBOM should be signed (using Sigstore/cosign) and stored alongside the container image in your registry or artifact store.

1. Build Phase: After building the container image, run Syft immediately before pushing. Do not scan the pushed image; scan the local build to catch issues before they reach the registry.
2. Attestation: Sign the SBOM with cosign. This proves the SBOM was generated by your authorized pipeline at a specific time, preventing tampering.
3. Storage: Attach the SBOM as an OCI referrer or upload to a dedicated SBOM manager like Dependency-Track. Avoid committing large JSON files to Git.
4. Policy Gate: Use Grype or Open Policy Agent (OPA) to evaluate the SBOM against security policies before deployment approval.

# Example GitLab CI job snippet
generate-sbom:
  stage: test
  image: anchore/syft:v1.0.0
  script:
    - syft oci:${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHA} -o cyclonedx-json=sbom.cdx.json
    - cosign attest --predicate sbom.cdx.json --type cyclonedx ${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHA}
  artifacts:
    paths:
      - sbom.cdx.json
    expire_in: 90 days

Which SBOM tools compare best for production use?

The tooling landscape has consolidated around a few high-quality options. Choosing depends on whether your priority is pure generation speed, vulnerability correlation, or enterprise platform integration. Below is a comparison based on real-world usage in 2026 across cloud-native environments.

A common mistake is relying solely on Trivy because it is popular. While excellent, Syft often identifies 10–15% more packages in complex multi-language containers due to specialized catalogers for Go binaries, Python wheels, and Java archives. For compliance-critical workloads, I frequently run both and merge results to maximize coverage.

How do you validate and monitor SBOMs continuously?

Generating an SBOM is a point-in-time activity; security requires continuous validation. An SBOM created at build time becomes stale the moment a new CVE is published. This is where the distinction between generation and monitoring matters. Tools like Dependency-Track ingest SBOMs and automatically correlate them against NVD, OSV, and commercial vulnerability databases daily.

Validation also means verifying the SBOM itself. Use sbom-utility or cyclonedx-cli to validate schema conformance before ingestion. Invalid SBOMs silently fail in monitoring platforms, creating false confidence. Additionally, implement VEX (Vulnerability Exploitability eXchange) documents alongside your SBOM. A VEX statement clarifies whether a vulnerable component is actually exploitable in your specific context, reducing alert fatigue by 60–80% in mature organizations.

Next Steps for Secure Supply Chains

Implementing SBOM: Generate a Software Bill of Materials is no longer optional for teams handling sensitive data or operating in regulated markets. Start by integrating Syft into your existing CI pipeline today, even if initially just for visibility. Once baseline inventories exist, add Grype for policy enforcement and Dependency-Track for continuous monitoring. Remember that the SBOM is a living artifact; its value compounds only when kept current and actionable. If your team needs help designing a compliant supply chain strategy or preparing for SOC 2 audits with proper SBOM evidence, reach out to discuss your infrastructure security posture.