A Practical Guide to Accelerating Compliance and Security CI with SBOMs

In this piece, we'll cover the lifecycle and usage of a Software Bill of Materials (SBOM), which can help you stay audit-ready, continuously improve your security posture, avert costly breaches and licensing violations, and simplify your compliance process.

What are SBOMs?

Modern software applications rely on a vast software supply chain of third-party dependencies, transitive dependencies, artifacts, build tools, and more. This complexity makes it impractical for engineers to manually track all components involved in their code.

An SBOM is a detailed inventory of your software components, including versions, release timestamps, direct & transitive dependencies, checksums or other digital signatures, known vulnerabilities, supplier metadata, and license types. SBOMs simplify compliance with intellectual property laws, and they are required under certain regulatory frameworks.

Although SBOMs are only one small piece of an effective shift-left security strategy, they are an integral asset for helping improve security at every stage of the software development pipeline, from supply chain and CI/CD to pre and post-deployment vulnerability remediation. 

SBOMs aren’t useful for much besides audits if they’re just sitting around; it’s how you use them that matters. SBOMs can be used by vulnerability scanners and policy enforcement tools to add extra layers of automated safety checks to your pipeline, which we’ll touch on later.

Compliance requirements

SBOMs make it faster to audit your application's compliance with security and licensing requirements. They are also becoming mandatory for commercial software applications in many countries and sectors.

Selling software in regulated U.S. fields

FIPS compliance is required to sell to U.S. government customers, and is often required or advised in healthcare, finance, and other sensitive sectors. SBOMs help you prove that you are using FIPS-compliant cryptographic modules, also known as CVMPs. 

IntelliGRC used Buoyant’s FIPS-compliant modules to expedite its FedRAMP Moderate implementation, resulting in 4x revenue growth. See our guide on FIPS compliance for Kubernetes engineers, and how BEL makes it simpler to secure your data in transit. 

Licensing

OpenSSF’s 2025 SBOM study reported that modern software applications contain 70-90% open-source software (OSS) by code volume, resulting in diverse licensing requirements for software organizations to navigate. The 2026 OSSRA report states that only 2% of audited codebases contained no OSS components at all, making OSS licensing a nearly universal concern for commercial software.

SBOMs can be run through automated policy checkers or audited by legal teams, making it easier to automatically identify licensing conflicts and risks that might incur costly legal consequences. Tools such as Grant by Anchore can scan licenses, categorize them by risk level, and enforce automated license policies that help prevent improperly licensed code from entering your supply chain.

European commercial software security requirements

For companies with commercial activity within the EU, the EU’s Cyber Resilience Act (CRA) defines commercial software requirements for data confidentiality and integrity, security, vulnerability identification and response, and ongoing security management, including SBOM maintenance. Companies who violate CRA requirements may be fined €15 million or more, and banned from commercial activity within the EU.

Generating an SBOM

Formats

The two most common structured SBOM formats are:

• SPDX (maintained by the Linux Foundation), a format with more detailed licensing metadata. More optimized for open-source distribution and licensing audits.
• CycloneDX (maintained by OWASP), a format with more native support for dependency and vulnerability mapping. More optimized for security assessment.
  
  • CycloneDX supports Vulnerability Exploitability eXchange (VEX), an NTIA sub-format that describes CVE metadata, such as their estimated severity on a scale of 0.0 to 10.

Tamper-proofing your SBOM with attestations & build provenance

An SBOM by itself is simply a description of your components, with no guarantee of its correctness. It’s industry-standard practice to sign SBOMs at the time they were created, and to cryptographically verify them at time of use to ensure that your build hasn’t been tampered with.

Attestations

Attestations are a form of cryptographic proof which can be used to verify that the contents of a build artifact have not changed since it was created. This makes it possible to detect whether an attacker has compromised your build artifact since it left the build pipeline. For a more detailed introduction to this concept, see Github’s introduction to attestations and when to use them.

Sigstore is an industry-standard OpenSSF-backed project that includes tools such as Cosign for signing and verifying SBOM attestations, and Github Actions to quickly integrate verification into your CI workflow.

Provenance

Provenance is a description of how and when an artifact was built. This additional information is useful because an application codebase is only one part of your software system; the entire system building and running the code is also inherently vulnerable. If your builds need to be auditable or if you use automated policy enforcers such as OPA Gatekeeper, you need provenance attestation.

SLSA is an industry-standard security framework with provenance guidelines, and BEL provides SLSA provenance attestations with all container images.

Common SBOM generation tools

SBOMs are industry-standard in modern applications, so a wide variety of SBOM generation tools exist for different languages, stack setups, and deployment use cases. Your choice will depend heavily on your stack, but here are a few examples if you haven’t already gotten started with SBOMs.

• Some ecosystems have their own SBOM generators; for example, Node.js has the npm-sbom tool.
• CycloneDX produces language-specific SBOM tools for common languages, including Java, Python, and Golang.
• Github offers SPDX SBOM exports.
• Multi-language tools exist, such as Syft by Anchore, which generates SBOMs for containerized applications.

You have an SBOM; now what?

Vulnerability scanners for dependencies

Automated security scanners can detect a variety of security breaches in software, such as exposed authentication secrets, unsafe configurations, and unsafe dependencies. 

In particular, SBOMs can be scanned to quickly detect the presence of known vulnerabilities, or CVEs; standardized entries with unique IDs that help provide a common reference point for security engineers and researchers to track vulnerable code. Vulnerability scanners typically tag affected component versions with their severity level and which version you should use to resolve the vulnerability, if known. 

Some common vulnerability scanners include:

• OWASP Dependency-Track, a free and open-source platform for vulnerability detection and policy enforcement.
• Grype by Anchore, a vulnerability scanner for container images and filesystems.
• Snyk Open Source, an SCA tool that scans your dependencies for vulnerabilities and license issues. Snyk provides a suite of several other developer security tools.

Teams often configure security policies to prioritize the most critical CVEs first; for example, they may always block releases with a vulnerability score that exceeds a certain threshold, and gradually decrease that threshold over time as they make progress on their remediation backlog.

It's important to note that vulnerability scanners are not infallible, and they are inherently only able to detect previously documented vulnerabilities with CVE identifiers, not zero-day attacks.

Rescanning SBOMs after deployment

CVE scanners are only one small piece of a more complete security pipeline, but when tightly integrated into your CI/CD pipeline and policy checkers, they serve as a powerful automated tool to help you rapidly identify and address critical vulnerabilities.

Security doesn't end at the build step; live production systems have additional vulnerabilities and are harder to secure than development environments. OpenSSF considers SBOM rescans a valuable yet underutilized step to cut down on post-deployment CVEs. 

CVEs are constantly being discovered in existing packages, making it worthwhile to continuously re-scan deployed artifacts for newly published CVEs. CVE.org recorded 48,244 new CVEs in 2025, with clear exponential growth patterns across years. OpenCVE currently reports that hundreds to thousands of new CVEs are discovered every 24 hours.

Retaining SBOMs with each build artifact means that you only need to incur the cost of cataloguing its dependencies once, which lowers the cost of frequently re-scanning your artifacts for new CVEs. In addition, provenance is definitionally only possible to analyze at build time, so it’s important to retain it for an accurate inventory of your build components.

Incident response

Vulnerability remediation may be straightforward or complex depending on the situation. If patches are already documented for your affected components, you can simply update to the patched versions. If you’re unlucky, an unpatched vulnerability may be deep within your dependency tree in a core package that many of your top-level dependencies rely on; for example, at the network or operating system level.

Regardless of your situation, an auditable SBOM trail lets security engineers quickly pinpoint exactly when new dependencies entered the system, identify components and releases that have potentially been affected, triage vulnerabilities by severity level, and check for patches.

Putting it all together

To quickly summarize some important steps in the lifecycle of a productive SBOM:

• Each build triggers automated generation of a signed SBOM, including provenance attestation. License policies and vulnerability policies are automatically enforced at the CI/CD step, rejecting builds that violate licenses or contain CVEs above a defined vulnerability threshold.
• Once the build passes and is deployed, its signed SBOM is continuously scanned for new CVEs as long as the build artifact is deployed. Security tickets with priority levels are automatically created for new CVEs discovered in a build.
• When an incident occurs, SBOMs are scanned to help identify and triage affected components more quickly.

A faster road to compliance with Buoyant

Every public release of BEL is accompanied by downloadable SBOMs and SLSA provenance documentation, making it faster to programmatically verify your components and maintain your security posture. Buoyant Enterprise for Linkerd (BEL) provides signed container artifacts, helping you inventory your system at the container level, not just the application code.

Check out our docs for more tips on verifying your BEL artifacts and enforcing SBOM verification policies at runtime, or get started with BEL in just 5 minutes and try it today.

FAQ

What is an SBOM and why does it matter for compliance?

An SBOM is a detailed inventory of your software components, including versions, dependencies, checksums, and license types. SBOMs help you prove compliance with requirements like FIPS and the EU's Cyber Resilience Act. 

What's the difference between SPDX and CycloneDX?

SPDX, maintained by the Linux Foundation, focuses on detailed licensing metadata for open-source audits. CycloneDX, maintained by OWASP, has stronger native support for dependency and vulnerability mapping, including VEX.  

How do you verify an SBOM hasn't been tampered with?

You sign SBOMs at creation and verify them cryptographically at time of use. Sigstore's Cosign is an industry-standard tool for signing and verifying SBOM attestations, and it integrates with GitHub Actions for CI verification.  

Why should you rescan SBOMs after deployment?

New CVEs are discovered constantly. CVE.org recorded 48,244 new CVEs in 2025 alone. Rescanning deployed SBOMs catches newly published vulnerabilities in components you already shipped, without recataloging dependencies from scratch.  

Does Buoyant Enterprise for Linkerd (BEL) provide SBOMs?

Yes. Every public release of BEL includes downloadable SBOMs and SLSA provenance documentation, plus signed container artifacts, so you can inventory your system at the container level, not just the application code.