The ultimate guide to SBOMs

In March 2026, four supply chain attacks unfolded in 12 days, compromising tools trusted by millions of development teams, including a vulnerability scanner, an infrastructure security scanner, an AI model gateway, and one of the most widely used HTTP clients in the JavaScript ecosystem. In each case, the attack surface was the same: the dependencies flowing through CI/CD pipelines.

Most of those organizations were running security tools. What they couldn't see was what was inside the packages those tools depended on.

That visibility starts with a software bill of materials, or SBOM.

What is an SBOM?

An SBOM is a complete inventory of every library and component your software is built from. Without it, you can't know what you're running. With it, you can find vulnerabilities, manage risk, and respond when something in your dependency chain is compromised.

Common formats support interoperability across tools and teams, including CycloneDX, an Ecma International standard (ECMA-424), and SPDX, an ISO standard (ISO/IEC 5962:2021). GitLab generates SBOMs with CycloneDX; organizations requiring SPDX can convert between formats using open source tools like cyclonedx-cli.

Why SBOMs matter

Third-party code and open source code now account for 80% to 90% of modern applications, according to Sonatype's 2026 State of the Software Supply Chain report. Yet in 95% of cases where a vulnerable component is downloaded, a fixed version already exists. The gap is knowing what you're running, not available patches.

An SBOM gives teams a complete, auditable view of everything an organization's software is built from, down to the deeply nested transitive dependencies. When a component in your dependency chain is compromised, you can trace exposure across affected projects in minutes instead of hours.

In addition, AI has shortened the window between vulnerability discovery and active exploitation. Researchers and attackers can now surface zero-days in open source components in hours, not months. Without an SBOM, you have no reliable way of knowing which projects are exposed when a new advisory lands.

SBOM requirements are shifting but risk isn't

SBOMs have moved from recommended practice to regulatory expectation, and back again. In January 2026, the U.S. Office of Management and Budget (OMB) rescinded M-22-18, the Biden-era mandate requiring software vendors selling to the federal government to provide SBOM attestations. Its replacement, M-26-05, takes a risk-based approach that lets agencies define their own software assurance requirements.

SBOMs are no longer a blanket federal requirement, but they remain a recognized best practice and an enforcement tool agencies can still use. Frameworks like PCI DSS 4.0, U.S. Food and Drug Administration guidance, EO 14028, and U.S. Army directives already require them, and the EU's Cyber Resilience Act makes them a hard requirement for products sold in European markets.

GitLab SBOM support

An SBOM that isn't updated with every change is already out of date when a new vulnerability lands. GitLab generates SBOMs inside the pipeline. The inventory updates with every commit, vulnerability matches run automatically as new advisories are published, and findings surface where developers already work.

Scale SBOM generation and management

GitLab's SBOM-based dependency scanning analyzer, generally available in GitLab 19.0, supports 24+ package ecosystems. It parses lockfiles and dependency graphs directly rather than replicating each package manager's build toolchain, which makes scanning faster and extends language coverage without analyzer rebuilds.

Every scan produces a CycloneDX SBOM artifact. The dependency list is exportable in CycloneDX, JSON, or CSV formats directly from the UI, a specific pipeline, or via the GitLab API, so you can share SBOMs with customers, auditors, or downstream tooling. You can filter by component name and version, including multiple versions at once, to quickly surface which projects are running a specific dependency — critical when a compromised version needs to be identified and rotated across an organization.

Ingest and merge SBOMs

For projects with multiple components, a CI/CD job can merge multiple CycloneDX SBOMs into one consolidated file, with duplicate entries removed using implementation-specific metadata such as build and lock file locations. The merged SBOM is automatically augmented with license and vulnerability data for every component it contains.

Mitigate vulnerabilities faster to improve code security

Knowing which vulnerabilities matter and fixing them fast is where most teams struggle. GitLab addresses both.

For prioritization, vulnerability risk scoring incorporates EPSS (Exploit Prediction Scoring System), KEV (Known Exploited Vulnerabilities), and CVSS (Common Vulnerability Scoring System) data, so teams triage based on real-world exploitability rather than theoretical severity. Static reachability analysis for Java, JavaScript/TypeScript, and Python projects examines call graphs to identify which vulnerable dependencies are invoked at runtime. The dependency list shows whether each vulnerability sits in a direct or transitive dependency, with the full path showing how it entered the project.

Every confirmed finding comes with context: what it is, how it can be exploited, and how to fix it. Engineers can triage, assess, and guide remediation in natural language directly in chat, without switching to external dashboards or scripts. For confirmed SAST vulnerabilities, agentic remediation runs automatically — analyzing the finding, reasoning through the surrounding code, generating a fix, and opening a ready-to-merge request without manual intervention. Teams can also create and enforce policies based on newly detected vulnerabilities, so findings drive action instead of accumulating in a backlog.

Understand license compliance

SBOMs aren't only a security artifact. Legal, procurement, and compliance teams use them to understand the licensing terms of every component in a product and whether those terms align with corporate policy. GitLab surfaces license data alongside vulnerability findings in the dependency list, so non-security stakeholders can assess compliance exposure.

Enforce continuous dependency scanning

Most vulnerability scanners only run when code changes. GitLab Continuous Vulnerability Scanning runs independently of pipelines — when new CVEs are published to GitLab's Advisory Database, every project with dependency or container scanning enabled is automatically checked against the new advisory, with no commit or pipeline trigger required. This is particularly valuable for dormant or deprioritized repositories — projects where active development has stopped but the code remains in use.

The GitLab Security Dashboard consolidates findings across projects, groups, and business units into a single view, with charts for open vulnerabilities, remediation velocity, and risk score over time. A Vulnerabilities by Age chart surfaces how long issues have been open and unresolved, which makes it harder for findings to quietly age out of sight.

Every build artifact produced by GitLab ships with signed provenance, generated in-pipeline with no external signing service in the chain. This architecture enables SLSA Level 1 and Level 2 compliance, because the provenance is generated and signed by the same trusted builder that produced the artifact, with no third-party involvement that could introduce tampering risk. GitLab also supports SLSA Level 1 compliance through CI/CD components that use Sigstore Cosign to sign and verify artifact provenance, giving downstream consumers cryptographic proof of what was built, where, and how.

The future of GitLab's SBOM functionality

SBOMs are central to GitLab's software supply chain direction, and GitLab continues to improve its dependency scanning capabilities. We're working toward deeper integration of SBOM data across the software development lifecycle: expanding language coverage, strengthening agentic remediation, and surfacing SBOM-driven insights earlier in development, so teams can act on supply chain risk before it reaches production.

Get started with SBOMs

Under M-26-05, the federal government replaced its blanket SBOM mandate with an approach that lets agencies define their own software assurance requirements. Many will still require SBOMs from vendors. If you build SBOM capabilities into your workflows now, you'll be better positioned to respond when incidents occur and to satisfy whatever requirements agencies impose.

Start a free trial of GitLab Ultimate.

SBOM FAQ

What is an SBOM?

An SBOM is a complete, machine-readable inventory of every component inside an application, including open-source libraries, third-party dependencies, the versions you're running, and the licenses attached to each.

Why are SBOMs important?

SBOMs are crucial for several reasons. They provide:

• Insight into dependencies: Understanding what makes up your software helps identify and mitigate risks from third-party components.
• Enhanced security: With detailed visibility into application components, organizations can pinpoint vulnerabilities quickly and take steps to address them.
• Regulatory compliance: Regulations and best practices increasingly recommend or require an SBOM, particularly in the public sector.
• Streamlined development: Developers can use an SBOM to see which libraries and components are in use, saving time and reducing errors.

What standards are used for SBOM data exchange?

Two standards dominate:

• CycloneDX: Known for its user-friendly approach, CycloneDX simplifies complex relationships between software components and supports specialized use cases.
• SPDX: Another widely used framework for SBOM data exchange, providing detailed information about components within the software environment.

GitLab uses CycloneDX for SBOM generation because of its prescriptive nature and extensibility to future needs.

What is GitLab’s approach to SBOMs?

GitLab focuses on dynamic SBOMs that are:

• Automatically generated, so composition data stays current.
• Integrated with vulnerability scanning tools for risk assessment.
• Easy to manage, with support for ingesting and merging SBOMs.
• Continuously analyzed, offering ongoing scanning to surface newly published vulnerabilities.

How can I start implementing SBOMs in my organization?

Organizations can get started with SBOMs by generating them automatically as part of your existing CI/CD pipelines rather than treating them as a separate, manual exercise. GitLab Ultimate enables organizations to natively generate SBOMs as part of the standard DevSecOps workflow, and scan for vulnerabilities within the dependencies they identify. To get started, pick a critical application, produce an SBOM, and use it to determine which open-source components are in your builds and which vulnerabilities they contain. Generate an SBOM on every build so your inventory stays current, and feed the results into your vulnerability management and policy workflows so you can quickly trace a newly disclosed CVE to affected releases. Run this way, SBOMs meet emerging compliance and regulatory requirements, improve your security posture, and tighten your development practices.