SBOM: What’s Inside, Formats, Standards, and Best Practices

SBOMs have become a foundational part of modern software supply chain security because organizations need a reliable way to understand what they are building, shipping, buying, and running. They improve software transparency, help teams manage open-source and third-party risk, and support security, compliance, procurement, and engineering workflows.

At a high level, SBOMs help organizations:

• Identify components affected by newly disclosed vulnerabilities
• Understand dependency relationships across applications and releases
• Track open-source license obligations and legal risk
• Improve software transparency for customers, auditors, and regulators

Why Is It Important to Have an SBOM?

As software grows more complex and increasingly depends on open-source packages, containers, third-party components, and cloud-native build pipelines, it becomes harder for organizations to maintain a clear picture of what is actually inside their applications. An SBOM gives AppSec, engineering, compliance, and procurement teams a shared source of truth for software composition.

An SBOM is important because it helps organizations:

• Improve security visibility across first-party and third-party software
• Respond faster when new vulnerabilities or supply chain incidents emerge
• Meet compliance, procurement, and customer transparency requirements
• Support software maintenance, upgrades, and lifecycle governance

Unlike a basic dependency list, an SBOM can become an operational asset when it is generated consistently, versioned over time, and connected to vulnerability management and policy workflows.

For example, in case of vulnerabilities like Log4j or XZ Utils, an SBOM allows teams to determine if the exploitable packages exist in the enterprise codebase.

• Compliance – Beyond security, software often needs to comply with various licensing agreements and regulatory standards, such as the executive order mentioned above. An SBOM helps in ensuring that all components meet the necessary compliance requirements, avoiding legal issues and penalties.
• Engineering – From a product point of view, an SBOM simplifies the process of managing and updating software components. With a detailed inventory, development teams can make informed decisions about upgrading components or replacing those that are no longer supported or secure. This proactive approach to software management helps maintain the longevity and integrity of applications.
• Customers – Finally, an SBOM provides transparency for customers and users into the software they are using or purchasing, building trust in the software provider and allowing them to use the SBOM for securing their application environment, now that the software they are sold will be running in their environment.

What Are the Key Elements of an SBOM?

Component Name, Version, and Supplier

An SBOM should clearly identify every software component included in the application. This includes the component name, exact version number, and the supplier or maintainer responsible for it. Accurate version data is critical because vulnerabilities often affect only specific releases of a package.

Supplier information helps organizations trace where a component originated from, whether it came from an open-source project, a commercial vendor, or an internal development team. This improves accountability and simplifies risk assessments. It also helps security teams determine whether the component comes from a trusted source and whether the supplier has a history of maintaining and patching vulnerabilities in a timely manner.

License Information

Each component in an SBOM should include its associated software license. Open-source components often come with licensing obligations that may restrict commercial usage, redistribution, modification, or sublicensing.

Tracking licenses helps legal and compliance teams ensure the application does not violate licensing terms. It also reduces the risk of introducing incompatible licenses into enterprise software products. For example, some copyleft licenses may require organizations to disclose source code if certain conditions are met.

Dependency Relationships

Improve software supply chain visibility early

Generate SBOMs automatically with Checkmarx

See how Checkmarx helps teams build accurate SBOMs from modern development workflows

Explore Checkmarx SCA → See Checkmarx SBOM in Action

A Gartner® Magic Quadrant Leader™

A Forrester Wave Leader™

SOC 2 Type II Certified

Modern applications rely heavily on transitive dependencies, where one package depends on many others. An SBOM should document these relationships so teams can understand how components are connected throughout the software stack.

Dependency mapping is important during vulnerability response. A vulnerable library may not be directly included by developers but may still exist deep in the dependency tree. Understanding these relationships helps teams prioritize remediation efforts and assess potential impact more accurately.

Unique Identifiers (CPE, purl, SWID)

SBOMs often include standardized identifiers that uniquely reference software components across security and asset management systems. These identifiers make it easier to correlate software packages with vulnerability databases, security scanners, and inventory platforms.

Common identifiers include:

• CPE (Common Platform Enumeration): Used in vulnerability databases such as the National Vulnerability Database (NVD).
• purl (Package URL): A universal identifier for software packages across ecosystems like npm, Maven, PyPI, Go, and others.
• SWID (Software Identification) tags: ISO-standard identifiers commonly used for software inventory and enterprise asset management.

Using standardized identifiers improves interoperability between tools and reduces ambiguity when matching components to known vulnerabilities. Different packages may share similar names, but identifiers provide a consistent and machine-readable way to reference the exact software component and version in question.

Author, Timestamp, and Other Metadata

An SBOM should contain metadata about when and how it was generated. This includes the SBOM author, creation timestamp, tool used to generate the document, and the software product associated with it.

Metadata improves traceability and auditability. Teams can verify whether the SBOM reflects the current application state and determine if it was generated as part of a trusted build pipeline or release process. This is important because software components frequently change as applications are updated and rebuilt.

Additional metadata may include build environment details, package hashes, organizational ownership, or references to related security documents. These details help organizations maintain stronger software supply chain visibility and support internal governance requirements.

Vulnerabilities

Some SBOMs include known vulnerability information associated with listed components. This may reference publicly disclosed vulnerabilities such as CVEs (Common Vulnerabilities and Exposures) or advisories from vendors and security databases.

Including vulnerability data helps organizations quickly identify whether an application contains components affected by known security issues. Security teams can prioritize remediation efforts based on severity, exploitability, and business impact.

Vulnerability information is often linked through standardized identifiers such as CPEs or purl values. This allows automated security tools to continuously monitor SBOM components against vulnerability databases and generate alerts when new issues are discovered.

Security and Compliance Attestations

SBOMs may include attestations that provide evidence about how the software was built, tested, and secured. These attestations help organizations verify that development and release processes follow defined security and compliance requirements.

SBOM security attestations can include information about code signing, build pipeline integrity, security scanning results, provenance data, or compliance with frameworks such as SLSA (Supply-chain Levels for Software Artifacts). This helps establish trust in the software supply chain and supports secure software development practices.

Compliance attestations may document adherence to internal policies, regulatory requirements, or industry standards. Examples include export control validation, open-source license compliance checks, or proof that security testing was completed before release.

These attestations are increasingly important in regulated industries and government procurement processes. Organizations often need verifiable evidence that software was developed using secure and compliant processes, not just a list of included components.

Cryptographic Signatures

Cryptographic signatures help verify the authenticity and integrity of an SBOM. A digitally signed SBOM allows recipients to confirm that the document was produced by a trusted source and has not been modified after generation.

Signatures are typically created using public key cryptography. The SBOM producer signs the document with a private key, and consumers validate the signature using the corresponding public key. If the SBOM contents are altered, the signature verification fails.

Signed SBOMs reduce the risk of tampering within the software supply chain. Attackers may attempt to modify dependency information, hide malicious components, or replace legitimate packages with compromised versions. Cryptographic verification helps detect these changes.

Signatures also support stronger auditability and non-repudiation. Organizations can trace who generated the SBOM and verify that it came from an approved build or release process. This is particularly important in automated CI/CD pipelines and software distribution environments.

SBOM Formats and Standards: SPDX, CycloneDX, and SWID 

SBOM Formats at a Glance

The following table summarizes the key differences between the SBOM formats. We explore each format in more detail below.

1. SPDX

SPDX (Software Package Data Exchange) is one of the most widely adopted SBOM standards. It was created by the Linux Foundation to provide a standardized format for sharing software component, license, copyright, and security information across organizations and tools.

Key aspects of SPDX:

• Format Flexibility – Supports both human-readable and machine-readable formats, including JSON, YAML, RDF, and tag-value documents. This flexibility allows it to integrate into a range of software development, compliance, and security workflows.
• License Management – It includes a standardized license identifier system that helps organizations consistently track and validate open-source licensing obligations. Because of this, SPDX is commonly used by legal, compliance, and governance teams in addition to security teams.
• Use Cases – SPDX can also represent complex dependency relationships, file-level details, cryptographic hashes, and package metadata. It is widely supported across open-source ecosystems and has become an international standard under ISO/IEC 5962:2021.

2. CycloneDX

CycloneDX is an SBOM standard designed specifically for application security and software supply chain risk management. It was originally developed by the OWASP Foundation and has become widely adopted in modern DevSecOps environments. CycloneDX focuses heavily on security use cases, including vulnerability management, dependency analysis, cryptographic integrity, and risk assessment. 

Key aspects of CycloneDX:

• Fast Operations – The format is lightweight and efficient, making it suitable for automated CI/CD pipelines and real-time software inventory tracking.
• Formats Supported – The standard supports JSON and XML formats and can describe applications, containers, firmware, operating systems, and hardware components. 
• Security Focus – In addition to listing software packages, CycloneDX can include security-related information such as known vulnerabilities, component hashes, external references, and exploitability data.
• Ecosystem Support – Many SCA (software composition analysis), container security, and vulnerability management platforms natively generate and consume CycloneDX SBOMs.

3. SWID tags

SWID (Software Identification) tags are a standardized method for identifying and tracking software assets. They were developed by ISO as part of the ISO/IEC 19770-2 standard and are commonly used in enterprise asset management and compliance environments. Unlike SPDX and CycloneDX, which focus on software supply chain transparency and dependency tracking, SWID tags are often used for software inventory management on deployed systems. 

Key aspects of SWID tags: 

• Metadata Focus – They provide detailed metadata about installed software, including product name, version, publisher, installation details, and patch information.
• Tracking and Management – SWID tags help organizations maintain accurate software inventories across large enterprise environments. This is useful for asset management, regulatory compliance, vulnerability tracking, and license auditing.
• Interoperability – Because SWID tags are machine-readable and standardized, they enable interoperability between security tools, endpoint management platforms, and asset inventory systems. Government agencies and highly regulated industries often use SWID tags as part of broader cybersecurity and software governance programs.

SBOM Examples: Source, Build, and Deployed SBOMs 

Source SBOM

A source SBOM is generated from the development environment before the software is built. It captures source files, direct and transitive dependencies, libraries, and development metadata. This type of SBOM helps teams identify vulnerable components and license issues early in the SDLC, before they become part of a released artifact. However, it may not fully represent the final software because some components are added, changed, or bundled during the build process.

Example:

• Product: HealthConnect Patient Portal
• SBOM type: Source SBOM
• Generated from: Git repository healthconnect/patient-portal
• Generated on: 2026-03-14
• Components: Angular 18.0.1, NestJS 11.0.0, RxJS 7.8.1, TypeORM 0.3.21
• Development metadata: Node.js 22.3.0, npm 10.8.0, Ubuntu development environment
• License data: MIT, Apache-2.0
• Dependency relationships: patient-portal depends on NestJS; NestJS depends on several framework modules and packages.

Build SBOM

A build SBOM is created during the software build process and reflects the components that contribute to the final product artifact. It includes built executables, packaged libraries, intermediate build files, dependency versions, and integration details. Because it is generated during the build, it provides a more accurate record of what will be delivered than a Source SBOM. It also supports auditability by documenting each build in a traceable and verifiable way.

Example:

• Product: FleetTrack Logistics Platform
• SBOM type: Build SBOM
• Build ID: fleettrack-release-2026.03.14
• Generated by: CI/CD pipeline production-release
• Final artifact: fleettrack-service-5.2.1.war
• Components: Spring Boot 3.3.1, Hibernate ORM 6.5.0, Apache Kafka Client 3.8.0, PostgreSQL JDBC Driver 42.7.3
• Intermediate files: Compiled application classes, packaged service modules, container build artifacts
• Hashes: SHA-256 values for application packages and dependencies
• Build environment: OpenJDK 21, Maven 3.9.8, Linux container runner

Deployed SBOM

A deployed SBOM captures the software components actually present in a running environment after deployment. It includes installed components, runtime dependencies, system configuration details, and dynamically loaded software. This type of SBOM is useful for operational security because it shows what is active in production, not just what was planned during development or build. It supports vulnerability response, patching, compliance checks, and incident investigation.

Example:

• Product: RetailInsight Analytics Platform
• SBOM type: Deployed SBOM
• Environment: Production Kubernetes cluster analytics-prod
• Generated on: 2026-03-15
• Running image: registry.company.local/retailinsight-analytics:7.1.0
• Installed components: Python 3.12, FastAPI 0.115.0, Pandas 2.3.0, PostgreSQL Client 16.3
• Runtime dependencies: NGINX ingress controller, OpenTelemetry collector, Redis 7.4 client libraries 
• Configuration data: TLS enabled, audit logging enabled, API authentication enforced
• Operational use: Supports runtime vulnerability monitoring, patch validation, and incident response activities.

SBOM vs. SCA: What’s the Difference?

SBOM and SCA are closely related, but they are not the same thing. An SBOM is a document or inventory that lists the software components included in an application, while SCA (Software Composition Analysis) is the process and tooling used to identify, analyze, and manage those components.

An SBOM answers the question: “What is inside this software?”

SCA answers questions such as: “Are these components vulnerable, outdated, risky, or non-compliant?”

SCA tools scan source code, build environments, package managers, containers, and binaries to discover dependencies and identify issues. During this process, many SCA platforms generate SBOMs automatically as an output artifact. The SBOM then becomes a standardized record that can be shared across teams, customers, auditors, or security systems.

For example, an SBOM may show that an application contains Log4j version 2.14.1. An SCA tool would detect that this version is vulnerable to Log4Shell (CVE-2021-44228) and alert the organization to update or remediate it.

Top SBOM Use Cases

Organizations use SBOMs for much more than software inventory tracking. SBOMs support security operations, compliance initiatives, software governance, and supply chain transparency across the entire software lifecycle.

Some of the most common SBOM use cases include:

• Vulnerability management – Security teams use SBOMs to quickly identify whether vulnerable components exist within applications. When new CVEs or zero-day vulnerabilities are disclosed, teams can search SBOMs to determine exposure and prioritize remediation efforts faster.
• Incident response: During security incidents, SBOMs help responders understand which systems, applications, and dependencies may be affected. This reduces investigation time and improves the speed and accuracy of containment efforts.
• Software supply chain security (SSCS) – SBOMs provide visibility into third-party and open-source dependencies that may introduce risk into the software supply chain. Organizations can better evaluate supplier trust, dependency hygiene, and component provenance.
• License and open-source governance – Legal and compliance teams use SBOMs to track open-source licenses and identify components with restrictive or incompatible licensing terms. This helps organizations avoid legal and operational risks.
• Asset inventory and software visibility – SBOMs provide a centralized inventory of software components across applications and environments. This improves software governance and helps organizations maintain accurate records of deployed technologies.
• Patch and Upgrade Planning – Development and engineering teams use SBOMs to understand dependency relationships before upgrading packages or applying patches. This reduces the likelihood of breaking changes and operational instability.
• Third-Party Risk Management – Organizations increasingly request SBOMs from software vendors to evaluate the security posture of purchased software products. This transparency helps customers assess risk before deploying software into production environments.
• Mergers, Acquisitions, and Due Diligence – During acquisitions or technology assessments, SBOMs help organizations evaluate inherited software risks, unsupported components, and potential compliance issues within acquired applications.
• Continuous Monitoring and Automation – Modern security platforms integrate SBOMs into automated workflows for vulnerability scanning, policy enforcement, and risk monitoring. This enables continuous visibility into software risk as applications evolve over time.

AI BOM (AIBOM): Extending SBOM to AI Systems

As organizations increasingly adopt AI and machine learning systems, traditional SBOMs are no longer sufficient to fully describe modern software supply chains. AI applications introduce additional components beyond standard software dependencies, including models, datasets, training pipelines, prompts, and external AI services. This has led to the emergence of the AI BOM (AIBOM).

An AIBOM extends the concept of an SBOM to cover the full lifecycle and supply chain of AI systems. It provides visibility into the assets, dependencies, and processes used to build, train, deploy, and operate AI models. The goal is to improve transparency, security, governance, and compliance for AI-powered applications.

An AIBOM typically includes:

• AI Models – Information about the models used within the application, including model names, versions, providers, architectures, and model hashes. This may include open-source models, proprietary foundation models, fine-tuned models, or internally trained models.
• Training and Fine-Tuning Data – Metadata about datasets used to train or fine-tune models. This includes dataset sources, versions, licensing terms, and data lineage information. Tracking training data is important for regulatory compliance, intellectual property management, and identifying risks such as biased or poisoned datasets.
• Frameworks and ML Dependencies – AI systems often rely on specialized frameworks such as TensorFlow, PyTorch, ONNX, CUDA, Hugging Face Transformers, or vector databases. An AIBOM tracks these dependencies similarly to traditional SBOM components.
• Model Provenance and Lineage – Information about how a model was created, modified, or fine-tuned over time. This includes training environments, hyperparameters, checkpoints, contributors, and inherited upstream models. Provenance tracking improves reproducibility and trust.
• External AI Services and APIs – Many applications rely on third-party AI APIs or hosted inference providers. An AIBOM can document these external dependencies, including service providers, API versions, and model endpoints used in production systems.
• Prompts and System Instructions – In generative AI systems, prompts and system instructions can significantly influence model behavior. Some organizations include prompt templates and prompt management metadata as part of AI governance and risk management processes.
• Security and Safety Metadata – AI systems introduce risks beyond traditional software vulnerabilities. An AIBOM may include information related to model security testing, adversarial robustness, bias assessments, toxicity evaluations, or compliance with AI governance frameworks.

AIBOMs are becoming increasingly important due to emerging AI regulations and security concerns. Governments and industry groups are beginning to require greater transparency around AI systems, especially in regulated sectors such as healthcare, finance, defense, and critical infrastructure.

Benefits of an SBOM

The benefits of an SBOM extend across security, compliance, engineering, and software governance. While the exact value depends on how the SBOM is generated and operationalized, organizations typically benefit in four main ways:

• Stronger security visibility: Teams can quickly identify affected applications when new component vulnerabilities are disclosed.
• Better compliance and governance: SBOMs support licensing reviews, software transparency requirements, and supplier due diligence.
• Improved software maintenance: Engineering teams can make better decisions about upgrades, replacements, and dependency hygiene.
• Greater customer and stakeholder trust: Sharing SBOMs improves transparency for buyers, auditors, and regulated customers.

How SBOMs Support Vulnerability Management

SBOMs play an increasingly important role in vulnerability management because they give security teams a current inventory of the software components inside each application. 

When a new CVE or zero-day vulnerability is disclosed, teams can use SBOM data to quickly determine whether affected packages exist in their environment instead of manually searching repositories, images, or build artifacts.

This becomes especially valuable during high-profile incidents. 

For example, when vulnerabilities such as Log4Shell or XZ Utils are disclosed, teams need to answer three questions quickly: 

• Are we affected? 
• Which applications contain the vulnerable component? 
• How do we prioritize remediation?

 An SBOM helps answer the first two questions by showing exactly which packages, versions, and dependency relationships exist in each application.

SBOMs are even more useful when combined with Software Composition Analysis (SCA).

The SBOM provides the inventory, while SCA adds vulnerability intelligence, license analysis, policy checks, and remediation guidance. Together, they help organizations move from static documentation to operational vulnerability management.

Used this way, SBOMs support:

• Faster exposure analysis when new vulnerabilities are disclosed
• Better prioritization across affected applications and environments
• More accurate impact assessments during incident response
• Stronger coordination between AppSec, engineering, and operations teams
• Continuous monitoring as software dependencies change over time

In practice, SBOMs are most valuable when they are generated automatically, versioned with each release, and connected to broader vulnerability management workflows rather than stored as one-time compliance documents.

Challenges of Implementing an SBOM

Despite the benefits of an SBOM, generating and maintain an SBOM comes with its own set of challenges:

• Complexity and Scale – Modern software applications often consist of numerous components and dependencies, making it challenging to create, track and maintain a comprehensive SBOM.
• Dynamic Nature of Software – Software is constantly evolving, with frequent updates, patches and new releases. Keeping SBOMs up-to-date requires continuous monitoring and documentation of changes in software components, which can be resource-intensive and time-consuming.
• Lack of Standardization – Currently, there is no universally accepted standard format for SBOMs. This lack of standardization leads to variability in how organizations create, store and share SBOMs in SBOM tools. This makes it difficult to exchange information effectively across different stakeholders in the software supply chain.
• Limited Visibility into Supply Chains – Organizations often have limited visibility into third-party and open-source components. Obtaining SBOMs from upstream suppliers can be challenging, particularly for proprietary or closed-source software.
• Security and Privacy Concerns – SBOMs contain sensitive information about software components and their dependencies, raising security and privacy concerns. It is important to protect SBOM data from unauthorized access, tampering, or exploitation to prevent potential security breaches or intellectual property theft.
• Resource Constraints – Small and medium-sized organizations may lack the resources, expertise, or infrastructure needed to implement and maintain SBOMs effectively. 
• SBOM Operationalization – Ensuring the enterprise can use the SBOM to its full extent. This includes visibility into where all SBOMs, the ability to find SBOMs quickly in case of a zero-day disclosure, knowing how to look for vulnerable packages, finding running applications with vulnerabilities, and more.

SBOM Regulations and Compliance Requirements

Governments, regulators, and enterprise customers are increasingly requiring organizations to maintain visibility into their software supply chains. As software attacks continue to grow, SBOMs have become an important mechanism for improving transparency, vulnerability management, and software governance.

SBOM requirements now appear in cybersecurity regulations, procurement frameworks, industry standards, and vendor security assessments across multiple sectors.

Executive Order 14028 (United States)

Executive Order 14028, Improving the Nation’s Cybersecurity, was issued by President Biden in May 2021 and became one of the most influential U.S. cybersecurity directives for software supply chain security. Although it was directed at federal agencies and government procurement, its impact extended far beyond the public sector. The order accelerated industry adoption of Software Bills of Materials by making software transparency, secure development practices, and supplier accountability central expectations for organizations selling software to the U.S. government and to security-conscious enterprise customers.

EO 14028 helped establish SBOMs as a practical compliance and risk-management tool. It directed federal agencies and standards bodies to advance software supply chain security guidance, and it defined an SBOM as a formal record of the components used to build software. The order also contributed to the development of downstream guidance from NIST, NTIA, CISA, and OMB, including secure software development expectations and SBOM minimum-element guidance.

Under the Trump administration, the federal approach has changed. The administration has rolled back or revised several Biden-era cybersecurity implementation requirements, including rescinding OMB memoranda that had required standardized secure software development attestations from federal software suppliers. This does not erase the broader market effect of EO 14028: SBOMs remain embedded in software supply chain security programs, vendor assessments, procurement conversations, and emerging regulatory frameworks. However, U.S. federal software security policy is now moving toward a more agency-led, risk-based approach rather than a single centralized attestation model.

NTIA Minimum Elements for an SBOM

Following the executive order, the National Telecommunications and Information Administration (NTIA) published guidance defining the minimum elements required in an SBOM.

The NTIA guidance focuses on three main categories:

Data Fields

An SBOM should contain core information about software components, including:

• Supplier name
• Component name
• Version information
• Dependency relationships
• Unique identifiers such as CPE or purl

These fields ensure organizations can accurately identify software packages and correlate them with vulnerability databases.

Automation Support

The SBOM should be machine-readable and generated in standardized formats such as:

• SPDX
• CycloneDX
• SWID

Automation is critical because manually maintaining software inventories is not scalable in modern development environments.

Practices and Processes

The NTIA guidance also emphasizes operational considerations, including:

• Frequency of SBOM updates
• Access control and sharing
• Distribution methods
• Data integrity and authenticity

These practices help ensure SBOMs remain useful throughout the software lifecycle.

NIST Secure Software Development Framework (SSDF)

The National Institute of Standards and Technology (NIST) introduced the Secure Software Development Framework (SSDF), documented in NIST SP 800-218.

The SSDF provides a set of secure development practices designed to reduce vulnerabilities throughout the software development lifecycle.

While the framework does not mandate SBOM usage directly, SBOMs strongly support many SSDF objectives, including:

• Tracking third-party dependencies
• Managing software supply chain risks
• Monitoring vulnerabilities
• Maintaining software integrity
• Improving incident response capabilities

Organizations adopting SSDF practices often integrate SBOM generation into CI/CD pipelines to automate software inventory management and vulnerability tracking.

Cyber Resilience Act (European Union)

The European Union Cyber Resilience Act (CRA) introduces cybersecurity requirements for products containing digital components.

The regulation aims to improve the security of software and connected devices sold within the EU market. Manufacturers are expected to:

• Identify and manage vulnerabilities
• Maintain secure development processes
• Provide ongoing security updates
• Improve software transparency

SBOMs help organizations meet many of these requirements by documenting software components and dependencies used within products.

The CRA is especially important for:

• IoT manufacturers
• Industrial systems vendors
• Cloud and software providers
• Consumer technology companies

As enforcement increases, SBOMs are expected to become a common requirement for demonstrating software supply chain visibility and vulnerability management.

European Union AI Act

The EU AI Act, Regulation (EU) 2024/1689, is one of the most important emerging compliance frameworks for AI governance and software supply chain transparency. For high-risk AI systems, the Act requires providers to prepare and maintain technical documentation before placing the system on the EU market or putting it into service. This documentation must show that the system complies with the Act and must give regulators enough information to assess the system’s design, development, testing, data governance, and risk management. 

In practice, this creates a strong need for structured inventories of AI components, including models, datasets, software dependencies, validation methods, intended use, and system limitations. As a result, the EU AI Act is likely to accelerate adoption of AI-BOM-style practices. Organizations building or deploying AI systems in the EU will increasingly need structured records of model provenance, training data sources, datasets, software components, third-party dependencies, evaluation results, security controls, and downstream usage information. 

For companies already maintaining SBOMs, an AI-BOM can be seen as a natural extension of software supply chain governance into AI systems and machine learning models.

Best Practices for Integrating Your SBOM Into the SDLC

Automate SBOM Generation in CI/CD

Manually generating SBOMs is difficult to maintain in modern software environments where applications are updated continuously. Development teams often release code multiple times per day, and dependencies can change frequently due to package updates, infrastructure modifications, or automated build processes. Automating SBOM generation inside CI/CD pipelines ensures that every build produces an accurate and current inventory of software components without requiring additional manual effort.

Organizations typically integrate SBOM generation into build stages such as dependency installation, container image creation, artifact packaging, or release workflows. This allows the SBOM to become part of the standard software delivery process rather than a separate compliance task. Many modern security and DevOps tools can generate SBOMs automatically in formats such as SPDX or CycloneDX, making it easier to integrate with downstream vulnerability management and governance systems.

Automation also improves consistency and scalability across engineering teams. When SBOM generation is standardized through CI/CD, organizations can enforce common policies, maintain uniform data quality, and reduce the risk of missing dependencies. Automated generation additionally supports faster security reviews because the SBOM is always available alongside the released software artifact.

Regenerate at Every Build

An SBOM should reflect the exact state of the software at a specific point in time. Because software dependencies change frequently, organizations should regenerate SBOMs during every build or release process rather than relying on older inventories. Even small changes to package versions, container layers, or build environments can introduce new vulnerabilities, licensing issues, or operational risks.

Modern development environments often use automated dependency management tools that pull updated packages dynamically during builds. In many cases, developers may not directly modify dependencies, but transitive packages can still change underneath the application. Similarly, rebuilding containers may introduce updated operating system libraries or runtime components that alter the software inventory. Regenerating the SBOM ensures these changes are captured accurately.

Frequent SBOM regeneration also improves incident response and vulnerability management. When a new zero-day vulnerability is disclosed, security teams can rely on recent SBOMs to quickly determine whether affected components are present in production systems. This reduces investigation time and helps organizations prioritize remediation efforts more effectively.

Validate Completeness and Accuracy

An incomplete SBOM can create a false sense of security. Organizations should validate that SBOMs accurately reflect all software components included in the application.

Validation should cover:

• Direct dependencies
• Transitive dependencies
• Operating system packages
• Container layers
• Runtime libraries
• Embedded software components

Teams should also verify:

• Correct package versions
• Proper dependency relationships
• Valid identifiers such as purl or CPE
• Accurate licensing information

Some tools may miss dependencies depending on programming language, build process, or packaging method. Regular validation helps identify gaps in SBOM coverage.

Organizations should also test SBOM interoperability across security tools to ensure formats are parsed correctly and vulnerability matching works reliably.

Store and Version SBOMs Centrally

SBOMs should be stored in a centralized location where they can be securely accessed and managed throughout the software lifecycle. Centralized storage improves visibility across engineering, security, compliance, and operations teams while making it easier to maintain consistent governance practices. Without centralized SBOM management, organizations may struggle to locate historical SBOMs during audits or security investigations.

Versioning is equally important because software inventories change over time. Each software release should have a corresponding SBOM that reflects the exact dependencies and components included in that version. Maintaining historical SBOM records allows organizations to track how software evolved, identify when vulnerable packages were introduced, and support rollback or forensic analysis efforts after security incidents.

Organizations commonly store SBOMs in artifact repositories, container registries, asset inventory systems, or dedicated governance platforms. Access controls should also be implemented because SBOMs may expose sensitive information about internal software architecture and dependencies. Proper storage and versioning practices help transform SBOMs into long-term operational assets rather than temporary compliance documents.

Continuously Monitor for New Vulnerabilities

Generating an SBOM provides visibility into software components, but its value increases significantly when combined with continuous vulnerability monitoring. New vulnerabilities are discovered constantly, and components that were considered safe during deployment may later become high-risk due to newly published CVEs or exploit disclosures. Continuous monitoring allows organizations to identify these risks quickly and respond before they are exploited.

Security platforms can automatically correlate SBOM data against vulnerability databases, threat intelligence feeds, and vendor advisories. When a vulnerable package is identified, teams can determine which applications and environments are affected without manually searching codebases or infrastructure. This significantly reduces the time required to assess exposure during security incidents.

Continuous monitoring also supports proactive risk management and operational resilience. Organizations can prioritize remediation efforts based on exploitability, business impact, or dependency criticality while maintaining ongoing visibility into software supply chain risks. Integrating SBOM monitoring into broader vulnerability management workflows helps organizations maintain stronger security posture as applications and threat landscapes evolve over time.

Create and Maintain and SBOM with Checkmarx SCA

Comply with SBOM Executive Order

Generate SBOMs Automatically

With Checkmarx™ SCA, or software composition analysis, we can automatically generate SBOMs on your behalf, saving you time and headache in ensuring you have an up-to-date inventory of 3rd party packages being used within your software projects.

Discover Checkmarx SBOM

How to Choose SBOM Tools and SBOM Software

Choosing the right SBOM software depends on how well it fits into your existing software development, security, and compliance workflows. A strong solution should not only generate SBOMs, but also help teams analyze, manage, and act on them over time.

Considerations when choosing SBOM tools:

• Supported SBOM formats – Look for support for widely used standards such as SPDX and CycloneDX to ensure interoperability across security, compliance, and procurement workflows.
• Automated SBOM generation – The tool should generate SBOMs automatically during builds, scans, or releases rather than relying on manual documentation.
• Dependency visibility – Prioritize tools that identify both direct and transitive dependencies across open-source, third-party, private, and containerized components.
• Vulnerability analysis – Choose a solution that can map SBOM components to known vulnerabilities and provide actionable risk context.
• License risk detection – The tool should help identify open-source license obligations, restrictions, and potential compliance issues.
• CI/CD integration – SBOM generation and analysis should integrate into development pipelines so teams can detect issues before software reaches production.
• Historical SBOM access – Look for the ability to store, version, and retrieve SBOMs from previous builds or releases for audits, investigations, and compliance reviews.
• Policy enforcement – Strong tools allow teams to define rules around vulnerabilities, licenses, package risk, or compliance requirements.
• Remediation guidance – Beyond identifying risk, the tool should help developers understand how to fix issues through upgrades, patches, or safer alternatives.
• Scalability and governance – The solution should support multiple teams, applications, repositories, and reporting needs across the organization.

Generate and Operationalize SBOMs with Checkmarx

Checkmarx helps organizations generate, manage, and operationalize SBOMs as part of broader software composition and supply chain security workflows. Instead of treating the SBOM as a one-time compliance artifact, Checkmarx helps teams continuously understand what is inside their software, what risks those components introduce, and what actions to take next.

With Checkmarx SBOM, teams can:

• Generate SBOMs automatically as part of software composition analysis workflows
• Export SBOMs in standard formats such as SPDX and CycloneDX for sharing, procurement, and compliance use cases
• Improve open-source and third-party visibility across applications, dependencies, and releases
• Enrich SBOMs with vulnerability and license intelligence so teams can assess security and compliance risk more effectively
• Apply policy controls to identify risky components, outdated packages, and non-compliant dependencies
• Support developer-friendly remediation by helping teams understand what to upgrade, replace, or investigate next
• Consume third-party SBOMs and add additional security context to software acquired from vendors or partners
• Maintain historical SBOM access for audits, investigations, and point-in-time software inventory review

This approach helps organizations move beyond simple component inventory and turn SBOMs into a practical part of vulnerability management, software supply chain security, and continuous governance.

Choose an SCA solution that provides SBOM functionality, analyzes SBOMs from other application providers, and analyzes SBOM data to identify and prioritize risks and provide remediation recommendations.

Checkmarx SCA allows you to easily generate an SBOM of all your software components to understand your open-source risk. Learn more by requesting a demo.