How to Generate and Use SBOMs for Secure Supply Chains

In a world increasingly driven by software, from cloud-native applications to embedded firmware in critical infrastructure, transparency and traceability are no longer optional. As developers, we rely heavily on open-source packages, third-party libraries, and public registries. But do we really know what’s inside our software? That’s where the Software Bill of Materials (SBOM) becomes indispensable.

An SBOM is a formal, machine-readable inventory of all software components, their relationships, versioning, licensing, and origin. It’s like a nutrition label for your application, enabling security teams, compliance officers, and developers to understand what exactly is running in production. In today’s fast-paced, microservice-heavy environments, SBOMs are central to supply chain security, vulnerability management, and DevSecOps practices.

This blog takes a deep dive into how to generate and use SBOMs, how they improve software security, and why every development team, from startups to enterprise CI/CD workflows, should integrate them into their pipelines.

‍

Why Developers Should Care About Software Bill of Materials

Visibility into your software supply chain

Modern applications are no longer standalone monoliths. They're stitched together from hundreds of dependencies sourced from open-source registries like PyPI, NPM, Maven Central, or GitHub releases. As developers, we often install packages without knowing their full dependency tree. SBOMs make these invisible components visible.

By generating an SBOM during your build process, you gain full insight into:

• The primary and transitive dependencies
  
  
• The exact versions of each library or binary
  
  
• Their upstream maintainers or vendors
  
  
• Associated cryptographic hashes or checksums
  
  
• Licensing metadata and known vulnerabilities
  
  

With this insight, developers can trace where every line of code originated, making audits and incident response dramatically easier. It's the foundational element in achieving software supply chain transparency.

Faster and smarter vulnerability triage

Imagine this: A new critical vulnerability (CVE) is published affecting a commonly used open-source library like log4j. Without an SBOM, your team scrambles, manually grepping codebases, searching manifests, asking around in Slack, just to confirm if you’re affected. This wastes time and delays mitigation.

With an SBOM in place, your security tooling or even a simple script can answer that in seconds.

SBOMs enable:

• Immediate lookup for affected components
  
  
• Easy cross-referencing with CVE databases like NVD or GitHub Security Advisories
  
  
• Reduced time to identify impacted services
  
  
• Fewer false positives and targeted patching
  
  

This makes vulnerability management precise and proactive, no more “spray and pray” patching.

Simplified open-source license compliance

Many organizations operate in regulated industries, finance, healthcare, aerospace, where open-source licensing matters. A single incompatible license in your dependency tree can become a legal and business risk.

SBOMs help mitigate this by tracking:

• License declarations for each component (MIT, GPL, Apache 2.0, etc.)
  
  
• Conflicts between incompatible licenses
  
  
• Missing or unknown license data
  
  

Automating this with SBOMs reduces legal overhead and enables secure and compliant use of open-source at scale, crucial for both small developer teams and enterprise software vendors.

Integrates with CI/CD pipelines seamlessly

For developers invested in automation and velocity, SBOMs don’t need to be a separate workflow. Instead, they integrate naturally into your existing CI/CD pipelines, delivering security without slowing down releases.

Popular CI tools (like GitHub Actions, GitLab CI, Jenkins, and CircleCI) can run SBOM generation as part of build jobs using tools such as:

• Syft by Anchore
  
  
• CDXGen by OWASP
  
  
• SPDX tools
  
  
• Trivy
  
  
• bom
  
  

Once built, the SBOM can be exported in formats like SPDX or CycloneDX, archived with the build artifacts, and scanned by vulnerability databases.

This “shift-left” approach brings supply chain security directly into your DevOps lifecycle, rather than being a reactive step after release.

‍

Generating an SBOM: Step-by-Step for Developers

Step 1: Integrate SBOM tooling in your local or CI build

Start by selecting an SBOM tool compatible with your tech stack. Here are some examples:

• Syft supports Docker, Go, Python, JavaScript, Java, and more.
  
  
• CycloneDX CLI supports multiple ecosystems and integrates well with CI.
  
  
• CDXGen is fast and accurate, designed for high-volume pipelines.
  
  
• Trivy offers scanning plus SBOM generation in CycloneDX format.
  
  

These tools can be installed via package managers or Docker and are typically run in one line. For example:

syft dir:./my-app -o cyclonedx-json > sbom.json

‍

Step 2: Choose your SBOM format wisely

There are two widely adopted formats in the ecosystem:

• SPDX: Developed under the Linux Foundation, this format is comprehensive and standard across many ecosystems. It includes licensing, relationships, and cryptographic metadata.
  
  
• CycloneDX: Lightweight and designed specifically for application security use cases. It’s great for integrating into vulnerability management platforms.
  
  

Both formats are XML or JSON based and supported by major DevSecOps tools.

Step 3: Capture rich metadata

A well-structured SBOM includes more than just names and versions. It should list:

• Package name, version, and vendor
  
  
• Cryptographic hash (SHA256 or SHA512) for integrity
  
  
• Source URL or repository
  
  
• License information
  
  
• Dependency graph (e.g., A depends on B depends on C)
  
  
• File path or container layer data (for containerized apps)
  
  

Capturing this metadata helps ensure accurate vulnerability scans and supports tools that rely on strong matching (like Grype, Dependency-Track, or OWASP Dependency-Check).

Step 4: Automate SBOM generation during CI/CD workflows

Adding SBOM generation to your CI ensures every build has an up-to-date, accurate representation of its software contents. This avoids “drift” between dev and prod and simplifies future audits or incident responses.

Example GitHub Action step:

- name: Generate SBOM

  run: syft dir:. -o cyclonedx-json > sbom.json

‍

Store the SBOM as a build artifact, publish it with your release, or send it to a vulnerability scanner or SCA (software composition analysis) platform.

Step 5: Use SBOMs for proactive security

SBOMs aren’t just static reports. They are living artifacts that power automation across security, compliance, and DevOps.

With SBOMs, you can:

• Run scheduled CVE scans using tools like Grype, Trivy, or Snyk
  
  
• Upload to platforms like Dependency-Track, JFrog Xray, or Sonatype Nexus for real-time monitoring
  
  
• Alert teams when risky packages are detected
  
  
• Block deployments if high-severity CVEs are found
  
  

The real value comes when SBOMs are actively used, not just generated and archived.

‍

Real‑World Benefits of Using Software Bill of Materials

Enhanced supply chain visibility and resilience

SBOMs let you map the full software dependency graph. When a breach happens (e.g., Log4Shell, SolarWinds), you immediately know:

• Which apps use the affected library
  
  
• Which environments are vulnerable
  
  
• How deep the affected component is in the dependency tree
  
  
• Whether it was pulled from a compromised registry or mirror
  
  

This dramatically reduces incident response time, minimizes attack surface, and enables informed risk decisions.

Improved developer velocity with built-in guardrails

Developers often hesitate to add security checks fearing they’ll slow down velocity. But SBOMs are different. They add visibility without friction. When automated, SBOMs:

• Don’t require context switching or separate tools
  
  
• Add less than a second to build time
  
  
• Provide value to both developers and security teams
  
  
• Are easy to version and compare across releases
  
  

You can even use SBOM diffs to track dependency drift, spot risky changes, and roll back insecure versions faster.

Lightweight but powerful

Unlike heavy binary analysis or full SAST/DAST scans, SBOMs are small files (in JSON/XML), typically less than a few hundred kilobytes. This makes them ideal for:

• Microservices
  
  
• Containerized workloads
  
  
• Serverless deployments
  
  
• Embedded systems
  
  

Despite their small size, they offer deep visibility, making them a low-cost, high-impact addition to your security tooling.

Modern vs traditional software inventory

Before SBOMs, software composition was often managed manually, spreadsheets, wiki pages, compliance reports done once per quarter. These were:

• Outdated by the time they were reviewed
  
  
• Incomplete and prone to human error
  
  
• Unusable for incident response or audit readiness
  
  

With SBOMs, inventory becomes continuous, automated, and precise. They scale with your codebase and stay updated on every push or merge.

‍

Best Practices for SBOM Adoption

Regenerate SBOMs with every build

SBOMs should be treated as dynamic artifacts, not static documents. A single version change or new transitive dependency can introduce new vulnerabilities. Automate regeneration as part of every build.

Validate integrity and trust

Store SBOMs alongside signed build artifacts, and consider digitally signing SBOMs themselves. This prevents tampering and ensures trust across distributed teams.

Establish organizational policies around SBOM usage

For SBOMs to deliver full value, they must be integrated into organizational processes:

• Require SBOMs for third-party software and vendors
  
  
• Enforce SBOM submission before internal releases
  
  
• Gate deployments based on SBOM scan results
  
  

Educate developers and SREs

Make sure engineering teams understand the purpose and value of SBOMs. Provide onboarding material, internal tooling integrations, and make SBOM scanning a first-class experience.

‍

The Future of SBOMs: AI, ML, and Secure Software Factories

SBOMs are just the beginning. The ecosystem is rapidly expanding to include:

• AI-BOMs: Where ML models, data provenance, hyperparameters, and training libraries are tracked and published as SBOM-style metadata.
  
  
• Attestation & signing standards: SBOMs are being paired with digital attestations (via Sigstore, SLSA) to ensure provenance and immutability.
  
  
• Regulatory compliance: Government mandates like the U.S. Executive Order 14028 are pushing SBOM adoption in critical infrastructure, financial software, and cloud services.
  
  

Developers who integrate SBOMs today will be better equipped for the secure software standards of tomorrow.

‍

Final Developer Takeaways

• SBOMs improve transparency, compliance, and incident response.
  
  
• Integrate SBOMs into CI/CD pipelines using tools like Syft or CycloneDX.
  
  
• Choose SPDX or CycloneDX for interoperable, machine-readable outputs.
  
  
• Automate CVE and license checks using your SBOM as input.
  
  
• Don’t just generate SBOMs, use them to enforce secure builds.
  
  

The best software isn’t just fast and scalable, it’s traceable and secure. SBOMs offer a lightweight, future-ready way to bring visibility, control, and security to every build.