From Zero to SBOM Hero

The Quality Problem

Most SBOM generation tools produce incomplete SBOMs that:

• Miss critical metadata (supplier info, licenses, contact details)
• Lack unique identifiers (PURLs, CPEs) needed for vulnerability matching
• Don’t capture transitive dependencies properly
• Fail to meet compliance requirements

Why Quality Matters

• Vulnerability insights: Without proper identifiers, you can’t match components to CVE databases
• EOL detection: Can’t identify end-of-life components without enriched metadata
• License compliance: Missing license data means legal blind spots
• Compliance failures: NTIA minimum elements, CISA requirements, and EU CRA all set quality bars that raw generation tools don’t meet

The sbomify Difference

The sbomify action is fully open source and the only tool that produces compliance-ready SBOMs out of the box by automatically:

• Augmenting with supplier/author/manufacturer metadata
  • Data comes from your sbomify profile or a sbomify.json file in your repo
• Enriching from 11 data sources including:
  • Pre-computed databases (LicenseDB, Lifecycle Database for EOL dates)
  • Native registries (PyPI, crates.io, pub.dev, Debian)
  • Aggregators (deps.dev, ecosyste.ms)
  • Fallback sources (ClearlyDefined, Repology)
• Adding proper identifiers for vulnerability matching
• Meeting NTIA minimum elements without manual intervention

See Integrations for the full list of enrichment sources.

Runs Anywhere - No Vendor Lock-in

• GitHub Actions - Native integration
• Any CI/CD - GitLab CI, Bitbucket Pipelines, Jenkins, CircleCI, etc.
• Python package - pip install sbomify-action for standalone use
• Docker - sbomifyhub/sbomify-action runs anywhere

Deployment Flexibility

• Hosted by sbomify - SaaS, we manage everything
• Self-hosted - Run on your own infrastructure for full control, keep your SBOMs in-house, and avoid dependency on any external vendor

Your SBOMs, your infrastructure, your choice. Use the action standalone or with the sbomify platform.

Step-by-Step Guide

Step 1: Understand the Basics

A Software Bill of Materials (SBOM) is like the ingredients list on a food package - but for software. It documents every component, library, and dependency in your application.

Key takeaway: SBOMs catalog all your dependencies, but quality matters. A low-quality SBOM is like an incomplete ingredients list - worse than useless because it gives false confidence.

What is an SBOM? →

Step 2: Choose Your Stack

sbomify supports all major ecosystems:

View all guides →

Step 3: Generate a Compliance-Ready SBOM

Choose the option that fits your environment:

GitHub Actions (quickest)

- name: Generate SBOM
  uses: sbomify/github-action@master
  env:
    LOCK_FILE: 'requirements.txt'
    AUGMENT: true
    ENRICH: true

Other CI/CD environments - We have ready-to-use templates for GitLab CI, Bitbucket Pipelines, and a Docker image for any environment.

View all CI/CD integrations →

All options handle generation + augmentation + enrichment automatically. The Docker image comes bundled with all SBOM generation tools - no need to install cdxgen, syft, or other tools separately.

Step 4: Sign in CI/CD

If an SBOM isn’t signed at generation time, can you trust it?

SBOMs generated outside CI/CD (or without signing) could be altered post-generation. No cryptographic proof means no way to verify authenticity or integrity.

Signing in CI/CD creates an unbroken chain of trust from build to distribution:

• Customers receiving your SBOM can verify it hasn’t been tampered with
• Reduces reliance on trusting the distribution platform
• Aligns with supply chain security best practices

The sbomify action supports attestation via GitHub Actions (Sigstore) and other signing mechanisms.

Learn about SBOM attestation →

Step 5: Understand the Full Lifecycle (Optional)

For those who want to understand what’s happening under the hood:

The sbomify action automates the entire authoring flow: Generation → Augmentation → Enrichment → Signing

SBOM Lifecycle Deep Dive →

Step 6: Manage and Share at Scale

When you’re generating one SBOM, management is easy. When you have dozens or hundreds across multiple products, services, and release cycles, you need:

• Logical grouping - Organize SBOMs by product, team, or release
• SBOM Hierarchy - Link related SBOMs (e.g., backend + frontend + container = product SBOM)
• Version tracking - Keep historical SBOMs for audit trails
• Automated distribution - Share with customers/regulators without manual work

Learn about SBOM Hierarchy →

Trust Center: Turn Transparency into Competitive Advantage

The Trust Center is where “hero” status really shines. It’s not just about generating SBOMs - it’s about sharing them professionally with stakeholders.

• Your domain - Host on your own domain (e.g., trust.yourcompany.com)
• Branded portal - Your logo, your colors, professional presentation
• Automated publishing - Syncs with CI/CD, always up-to-date
• Flexible access - Public for transparency or private for invited stakeholders
• More than SBOMs - Share SOC 2, ISO 27001, pentest reports, compliance attestations in one place
• Self-service - Customers get what they need 24/7, no email chains

Explore Trust Center →

The Litmus Test

SBOMs are becoming the litmus test for whether you actually know what goes into your software.

Regulators and buyers are no longer asking “do you have security?” - they’re asking “prove it.” SBOMs are the proof.

Already Required

• EU Cyber Resilience Act (CRA) - SBOMs mandatory for products with digital elements sold in EU
• PCI DSS 4.0 - Software component inventories required for payment card security (Req 6.3.2)

More Regulation is Coming

• FDA medical device guidance recommends SBOMs
• CISA minimum elements expanding requirements
• UK Software Security Code of Practice references software composition

The message: If you can’t produce a quality SBOM on demand, you’re signaling that you don’t know what’s in your software. That’s increasingly a dealbreaker for enterprise buyers and regulators alike.