Executive Summary
A Software Bill of Materials (SBOM) is defined as a machine-readable detailed description of the components (whether free software, proprietary software or commercial software) used in the software product development process. The concept of SBOM is often equated to the idea of “barcode” or recipe of the software. The idea behind SBOM is to bring transparency to the software supply chain by allowing organizations to visualize their software and to analyze any potential software risks. In theoretical perspective, the SBOM features a full list of all elements of the software (including the component title, version, manufacturer, supplier etc.) which provides a brief overview of the software components qualifications or features needed to address the software component’s risks, dangers, and implications.
SBOMs represent an essential element of software security and compliance. Concerning the requirement for using SBOMs, the governments’ initiatives (specifically, U.S. Executive Order 14028 and OMB memoranda) and the regulations demanding the creation of SBOMs (in this case, the European Union Cybersecurity Act) have become increasingly important. SBOMs assist in reducing software risks and in making the software secure.
In this resource, SBOM practices and the process of SBOM implementation are presented step by step. First, we explain what types of SBOM exist and what formats are available today. In addition, we will familiarize readers with the most important and mandatory data elements. Moreover, examples of the integration of SBOM generation into continuous integration and delivery (CI/CD) pipelines are given, and also the SBOM`s features are explained regarding vulnerability management including exploit data. In our guide, we provide information concerning policies and agreements on third-party risks, the most common problems faced while using SBOMs and how a company can overcome them, as well as the outlook for the future of SBOM due to AI/ML technologies implementation. The readers will be provided with concrete examples, tool commands, and the layout of a typical repository with the SBOM.
What Is an SBOM and Why It Matters
Definition: An SBOM is “a formal record containing the details and supply chain relationships of various components used in building software”. In other words, it is a list of every library, module, and package (and their relationships) that goes into a software product. Just as a manufacturing BOM lists parts of a hardware product, an SBOM lists software “ingredients.” This includes direct components and transitive dependencies (libraries pulled in by other libraries).
Use Cases: SBOMs provide multiple benefits:
- Vulnerability Assurance: Making sure the right action will be taken when a vulnerability incident (CVE) happens by searching for SBOMs in a portfolio is possible. This tends to replace the complex procedure of finding the fault in the code.
- License Compliance: A list of licenses which SBOMs provide ensures the compliance to the rules set by the law. At times breaking the law leads to serious consequences considering that legal compliance may turn out to be costly in the long run.
- Risk Management: Knowledge of software components helps to identify those ones that have reached end-of-life period and are now outdated. An SBOM can provide a chance to detect whether any old cryptography algorithm is being used in the software.
- Procurement Transparency: Clients often require for SBOMs in order to deal with the auditing of third-party software.
- Incident Response: An SBOM can ensure that the desired procedures will be implemented when a specific case of an incident incidence Response happens.
An SBOM is a foundation not a silver bullet. On its own, it doesn’t fix vulnerabilities or prevent attacks, but it gives visibility that is essential for secure software development and operations. In other words, you can’t protect what you can’t see. An SBOM program ties together development, security, legal, and operations to manage software risk holistically.
SBOM Formats (SPDX, CycloneDX, Others)
SBOMs should be machine-readable for automation. Common formats include:
- SPDX (Software Package Data Exchange): An open standard maintained by the Linux Foundation and ISO/IEC 5962:2021. SPDX has rich support for license and provenance metadata, making it ideal for license compliance and open-source inventory. It uses a detailed schema and supports “SPDX expressions” for licenses. (Official site: spdx.dev)
- CycloneDX: An open, lightweight BOM standard (ECMA-424) developed for software supply chain risk management. CycloneDX is JSON/XML-based and natively includes vulnerability data (VEX), component cryptographic hashes, and can cover hardware or SBOM types beyond traditional software. It is widely used in application security and DevSecOps. (cyclonedx.org)
- SWID Tags: ISO standard Software Identification tags. Originally for licensed software tracking (e.g. enterprise apps), they can represent installed software inventories. SBOM tools sometimes output SWID, though SPDX/CycloneDX are more common for open-source heavy environments.
- Other Formats: Some proprietary or legacy tools produce CSV or custom XML. These are not ideal for interoperability and should generally be avoided. The best practice is to use established standards so SBOMs can be shared and ingested across toolchains.
According to NTIA and CISA guidance, SBOM generators and consumers should support industry formats like SPDX and CycloneDX. When evaluating tools, ensure they can output (and validate) at least one of these. Many organizations support both to interoperate with partners; choose based on your ecosystem. For example, projects focused on license management may prefer SPDX, while security teams often use CycloneDX for its tight integration with vulnerability data.
Standard formats also allow the use of validators and processors. For CycloneDX, the OWASP CycloneDX CLI can generate and validate SBOMs. For SPDX, the SPDX command-line or libraries (e.g. spdx-sbom-generator) can build and check documents. Open tools like Syft (by Anchore) or Trivy can output SBOMs in these standards. The “CycloneDX Tool Center” catalogues many integrations (e.g. GitHub Actions, CI plugins) for generating CycloneDX SBOMs.
Types of SBOMs
SBOMs can be created at multiple stages of the software lifecycle, each serving different needs:
- Source SBOM: Generated from source code repositories or build manifests (e.g. package.json, pom.xml). It reflects declared dependencies in the code. Good as an early indicator, but may not capture all resolved versions (e.g. if a new patch is pulled) or artifacts embedded later.
- Build SBOM: Created during the build process after dependency resolution and compilation. It represents what actually went into the build artifact (binary, JAR, library bundle). This is more accurate than a source SBOM, as it shows concrete versions and any transitive packages pulled in by the build system.
- Container SBOM: Generated from a container image (Docker, OCI). It lists OS packages, language runtimes, application packages, and any files found in the image. Tools like Syft, Trivy, or Tern can inspect container layers to create this SBOM. Container SBOMs are crucial for cloud-native deployments.
- Deployed SBOM: An SBOM of what is running in production. For example, a configuration management system or runtime agent could collect inventories of deployed services and produce SBOMs. This accounts for any manual changes, hotfixes, or drift after deployment.
- Runtime SBOM: An advanced concept where only the components actually loaded or executed at runtime are included. This can reduce noise by excluding unused parts. For example, a dynamic analysis could trace imported libraries in Python/Java to see what’s truly used.
- Vendor SBOM: SBOMs received from third-party suppliers. For commercial or firmware products, vendors may publish or provide SBOMs of their releases. These should match the formats your tools ingest so you can automatically analyze them.
Each type answers a question. A source SBOM shows what developers intended to include, but a build SBOM shows what ended up in the deliverable. A deployed SBOM shows reality in production, possibly highlighting discrepancies. A mature organization might generate multiple SBOMs for the same product (source, build, container, deployed) to cover the full picture. For instance, differences between a build SBOM and a deployed SBOM can reveal unauthorized changes or missing updates.
For critical environments, you might even use all types. At minimum, build or container SBOMs should be produced for every release, and vendor SBOMs must be collected for third-party software.
SBOM Minimum Elements and Standards
The U.S. government’s NTIA and CISA have defined minimum elements for an SBOM so that it is usable for core tasks like vulnerability and inventory management. According to the 2021 NTIA guidance, an SBOM must include at least:
- Supplier: Who provided the component (vendor or project).
- Component Name: The name of the component.
- Component Version: Exact version or identifier.
- Unique Identifier: Such as a Package URL (purl) or CPE that uniquely identifies the component.
- Dependency Relationship: How components relate (e.g. library X version Y is used by project Z).
- SBOM Author: Who generated the SBOM.
- Timestamp: When the SBOM was created.
These fields are essential for basic SBOM utility. For example, without a version or unique ID, you can’t reliably map to a vulnerability database. NTIA emphasized that SBOMs are “foundational data” for transparency. CISA’s upcoming 2025 draft guidance (public comment) builds on this by adding elements like cryptographic hashes, license info, build metadata, SBOM tool version, and so on, reflecting advances in tooling (expanded provenance, authenticity).
In practice, you should treat the NTIA “minimum elements” as a baseline. A production SBOM will typically include more details. For example, an SBOM for a Java app might list each JAR’s SHA256 hash, license, and download URL. A CycloneDX SBOM might also include severity info or commit metadata. After all, many tools already capture these richer fields. The key is to use a consistent schema and validate that every SBOM from your pipelines meets your organization’s checklist.
Examples: In the FDA’s 2026 medical device guidance, an SBOM must include all software components (commercial, open-source, etc.), and be in a machine-readable format. The FDA even expects the SBOM to include upstream dependencies. Similarly, EU Cyber Resilience Act (CRA) mandates SBOMs in a common machine-readable format (SPDX or CycloneDX) covering at least top-level dependencies. These regulations rely on the NTIA elements as a foundation.
Governance, Policies, and Roles
An SBOM program needs clear governance. Organizations should define:
- Scope Policy: Which products require SBOMs? (e.g. all internet-facing apps, critical systems, regulated products, third-party purchases). Use risk criteria.
- Format/Standards Policy: Mandate accepted formats (e.g. SPDX 2.3 JSON or CycloneDX 1.4) and schemas. Define naming conventions (e.g. include version in file name).
- Frequency: When must SBOMs be generated or updated? (e.g. every release, significant patch, major config change). For example, FDA requires SBOMs in premarket submissions and updated with any software change.
- Access Control: SBOMs may reveal sensitive internal details (libraries used, architecture). Control who can see SBOMs. For vendor SBOMs, ensure confidentiality clauses if needed.
- Integrity Measures: Require signing of SBOMs or storing in immutable logs. If attackers can alter SBOMs, they can hide malicious code. Tools like Sigstore’s Cosign can sign SBOM attestation.
- Retention: How long to keep SBOM records? Regulations may dictate retention periods (e.g. EU CRA says ten years retention). Internal needs (incident response, audits) may require even longer.
- Exception Handling: Define processes for when SBOMs cannot be produced (e.g. legacy systems, black-box components). There should be an official risk acceptance for those cases.
- Ownership: Typically, Dev teams or build teams generate SBOMs. Security teams consume them. Procurement/legal teams enforce SBOM clauses with vendors. A centralized SBOM team or GRC (governance, risk, compliance) function may oversee quality and policy.
By policy and process, SBOM becomes part of the software development lifecycle, not a one-off report. For example, each development team’s Definition of Done might include “SBOM generated and checked”.
Third-Party Risk and Procurement
Managing third-party software (commercial or open-source) is one of the hardest SBOM use cases. Often you deploy an application or library without knowing its internals. SBOMs improve this by requiring transparency:
- Vendor Contracts: In RFPs and contracts, specify SBOM requirements. For example, require that suppliers provide SBOMs for delivered software in CycloneDX or SPDX format, updated with every patch, and including all components. Also ask for VEX notices for critical vulnerabilities. The contract can reference NTIA/CISA SBOM guidelines as standards.
- SBOM as Deliverable: Treat SBOMs like other deliverables (user docs, training). Vendors should publish SBOMs in a gated portal or as part of product packages. FDA now effectively requires SBOMs from medical device vendors in premarket submissions, showing this trend.
- Controlled Sharing: If vendors consider their dependency list confidential IP, use non-disclosure agreements. You can accept SBOMs under NDA or in a secure platform. The EU CRA, for example, says SBOMs need not be public but must be provided to regulators on request.
- Ingestion and Analysis: It’s not enough to collect vendor SBOMs; you must feed them into your SBOM inventory and scanners. Many companies fail by requesting SBOMs but lacking the tools to use them. Ensure your vulnerability management can parse third-party SBOMs just like internal ones.
- Compliance Leverage: Use SBOM clauses as a compliance checkbox in audits. For instance, in FedRAMP or NIST SP 800-53, you can point to “software supply chain transparency (SBOM) requirement in contracts.”
- Risk Prioritization: A third-party SBOM reveals if a vendor product uses a critical open-source component that your org must also patch. It creates upstream awareness and can influence vendor selection or monitoring frequency.
Overall, SBOM requirements in procurement shift some responsibility for security transparency onto vendors. But customers must follow through by ingesting the data.
Common Challenges & Mitigations
There are many hurdles to implementing SBOMs at scale. Some of the common challenges are:
- Lack of Complete Dependency Discovery: Some of the tools are unable to capture dynamically loaded libraries, native dependencies or binaries as well as those files that are not installed using the package managers. Suggested solution: You may need to use complementary tools. For instance, you can use a language-native SBOM generator (such as Maven CycloneDX Plugin) in combination with a file-system or container scanner.
- Transitive Dependencies: Modern apps can have hundreds of indirect dependencies. If your SBOM omits those, you miss risks. Ensure your tool captures the full dependency tree. For example, for npm/JavaScript, run SBOM on the node_modules; for .NET, on the built assembly with NuGet packages. Tools like Syft scan filesystem layers to catch transitive packages.
- Ambiguous Component IDs: The same library may be named differently in different ecosystems (e.g. “commons-io” vs. “commons-io-2.6”). Always use formal identifiers. SPDX and CycloneDX support Package URLs (purl) and CPE names that uniquely identify components. Enforce tools to include these (Syft does by default).
- SBOM Drift/Staleness: An SBOM reflects a specific build snapshot. If devs patch a lib manually or rebuild without updating SBOM, inventories get out-of-date. Solution: Always generate SBOM in automated CI for every build. Do not rely on manually maintained lists. Also regenerate SBOM after any hotfix or update.
- False Positives (Noise): Scanning SBOMs can flag many CVEs that aren’t really exploitable. Without context, developers get overwhelmed. Use VEX (see above) to mark not-affected issues. Also correlate with runtime context: e.g. if a vulnerability is in a library only used on a disabled feature, document that.Tuning your scanner, for example through advanced Nessus settings, and cross-checking results against your SBOM and VEX statements helps separate real risks from noise.
- Vendor Resistance: Some third parties may see SBOM as revealing trade secrets (list of components). Address this by limiting SBOM distribution to authorized personnel and contract NDAs. Many regulatory regimes balance transparency with IP (e.g. EU CRA says SBOMs are for regulators only).
- Tool Fragmentation: Early SBOM tools produced inconsistent outputs. Mitigation: Enforce validation. Use a schema validator or SBOM linting tool in your pipeline. For example, OWASP CycloneDX CLI has a validate command. The Linux Foundation published an SBOM Validator (and FOSSA offers an online validator) to check against NTIA spec.
- Seeing SBOM as Just a Checkbox: A popular anti-pattern is generating SBOMs only for the sake of performing an audit without using them for operational purposes. Proper ROI can be achieved when the SBOM becomes a part of your security workflows in the company.
Best Practices
From industry guidance and successful implementations, some best practices emerge:
- Start Small, Scale Fast: Begin with high-priority projects (internet-facing apps, regulated products). Build expertise and pipeline templates, then roll out broadly.
- Automate Everything: SBOM generation, validation, signing, storage – all automated in CI/CD. Manual steps will become bottlenecks and sources of error.
- Multi-Format Support: If possible, support both SPDX and CycloneDX. For example, you might generate CycloneDX for security analysis and SPDX for legal review. Many tools support output in multiple formats (e.g. syft -o SPDX).
- Include Transitive Deps: SBOM = all components. Don’t stop at top-level. (An attacker doesn’t care if a vulnerable library is indirect.)
- Attach SBOM to Artifact: Always bind the SBOM to the specific build (e.g. same version tag, image hash). Sign both the artifact and its SBOM.
- Central Repository & Search: Use a database or index. You should be able to query: “show me all products using OpenSSL 1.1.1g”. Without this, SBOMs sit unused.Feed your SBOM data into the tools your security operations center (SOC) already uses, so analysts can quickly answer the question “are we affected?”
- Integrate with SCA Tools: Although SBOM is the inventory, use Software Composition Analysis tools for deeper scanning (license checks, malware detection). But feed them SBOM outputs for consistency.
- Use VEX Strategically: Encourage vendors to use VEX in advisories. Internally, create VEX for known non-exploitable cases to save effort.
- Define Metrics: Track SBOM coverage (% of apps with SBOM), timeliness (time from release to SBOM availability), quality (no missing fields), and incident response metrics (MTTI, MTTR for vulnerabilities thanks to SBOM).
- Continuous Training: Educate devs and teams on SBOM use. Include SBOM steps in developer onboarding. Label components clearly (e.g. use conventional group IDs in Maven) so SBOM tools can categorize.
SBOM and Compliance
SBOM requirements are proliferating in regulation and guidance. Key areas include:
- U.S. Federal Policy: Executive Order 14028 (2021) spurred SBOMs for federal agencies. NTIA’s 2021 “Minimum Elements” report followed. OMB M-22-18 and M-23-16 mandated agencies to adopt secure practices including SBOMs. The latest OMB M-26-05 (Jan 2026) rescinded some older memos but still encourages agencies to inventory hardware/software and use contract clauses requiring SBOMs. NIST’s SSDF (SP 800-218) specifically calls for collecting and sharing SBOMs/provenance for software releases.
- Healthcare (FDA): FDA guidance (2026) for medical devices requires manufacturers to provide SBOMs in premarket submissions. It even suggests including upstream dependencies and to maintain the SBOM during the device lifecycle. In practice, since Oct 2023, the FDA can refuse a 510(k) submission lacking a comprehensive SBOM. FDA also expects documentation of vulnerability status (i.e. exploitability) for each CVE.
- Europe (EU Cyber Resilience Act): The CRA (Regulation 2024/2847) legally requires SBOMs as part of technical documentation for any product with “digital elements” sold in the EU. The SBOM must be machine-readable (e.g. SPDX or CycloneDX) and cover at least all top-level components. It must be maintained for 10 years after market release and updated when the product is patched. Notably, the CRA doesn’t force public disclosure but mandates providing the SBOM to authorities on request. This effectively makes an SBOM a condition of market access. Draft guidance suggests the CRA will further specify data fields and formats via delegated acts. Germany’s BSI has also published detailed guidelines (TR-03183-2) on SBOM content, which serve as de facto standards pending EU harmonization.
- Other Regions and Standards: While the U.S. and EU lead, other regions are following. For example, Japan’s Tokyo/Cyber for Startup funds SBOM tooling; ANSSI (France) and others have recommended SBOM use. The OECD and industry groups (OpenSSF) advocate for global SBOM standards. In finance and telecom sectors, regulators now expect SBOMs for critical software. For example, banking regulators in multiple countries reference SBOM guidance.
- Industry Standards: ISO/IEC 5962 (SPDX) is an international standard (2021), and ECMA-424 (CycloneDX) is ratified. NIST SP 800-218 (SSDF) and SP 800-161 (supply chain risk) include SBOM practices. The SWID tag standard (ISO/IEC 19770-2) can complement SBOM.
- Takeaway: Don’t treat SBOM as mere compliance paperwork. While regulations increasingly require SBOMs, the real value comes from operationalizing them. Use compliance deadlines as a forcing function, but build SBOM into security culture (DevSecOps, supplier management, incident response).
- Future Directions: SBOM concepts are extending beyond classic software components, with growing attention to areas such as hardware and firmware inventories and cryptographic bill of materials, as organizations seek greater transparency across every layer of their technology stack.
- Hardware and Firmware BOM: The term “HBOM” is used for hardware BOM, including embedded software and firmware versions in devices. IoT and embedded systems need SBOM-like inventory for all onboard software (bootloader, OS, apps). Some automotive and medical device standards are moving to require firmware SBOMs. The CRA and other IoT security frameworks hint at this.
- Cryptography BOM: With threats like quantum computing, organizations may start tracking cryptographic components (algorithms, key lengths, library versions) explicitly. A “Crypto Bill of Materials” would inventory where cryptography is used. This isn’t a formal standard yet, but some guidelines (e.g. BSI TR-03183-2) already recommend listing checksums and crypto libraries.
- Cloud/SaaS BOM: For cloud-native, you might treat consumed services (e.g. AWS Lambda layers, SaaS dependencies) as part of a “cloud BOM.” This is still an emerging area, often handled via asset inventory and runtime scanning.
- SBOM Evolution: Tools are adding more features: SBOM merging/differencing (for patch analysis), SBOM diff in pull requests, SBOM linting/policy engines, and SBOM attestation (e.g. in software supply chain security frameworks like Sigstore in-toto). Eventually, SBOMs could be auto-generated at package-release time (for public projects) by CI bots.
The overall trend is greater transparency. SBOM is just one piece; the long-term goal is a real-time picture of software component provenance and risk across the ecosystem. Standards bodies (ISO, CEN/CENELEC) are working on extending SBOM specifications for these new use-cases.
Recommended Open-Source SBOM Tools and Validators
There are many SBOM tools. Some widely used open-source options include:
- Syft (by Anchore): A CLI and library that generates SBOMs from container images, directories, and archives. It detects packages across many ecosystems (npm, Maven, PyPI, OS packages). It supports CycloneDX and SPDX output. (https://github.com/anchore/syft)
- Trivy (Aqua Security): Primarily a vulnerability scanner, Trivy also generates SBOMs for containers, file systems, and VMs. It outputs SPDX or CycloneDX. It’s CLI-based and popular in cloud-native stacks.
- Tern: A container image inspection tool that produces an SBOM by analyzing layers sequentially. It’s helpful for understanding image composition in detail.
- CycloneDX CLI: Official OWASP CLI that can generate SBOMs for various platforms (Maven, npm, .NET) and validate CycloneDX files. (https://github.com/CycloneDX/cyclonedx-cli)
- SPDX SBOM Generator: For example, spdx-sbom-generator (by SAP) creates SPDX SBOMs from projects. Also tools like SPDX-Builder or libraries support building SPDX docs.
- In-toto: Not an SBOM generator per se, but an open framework for attestation and supply chain security. It can be used to sign SBOMs in a software supply chain context.
- Dependency-Track: An application that ingests SBOMs (cyclonedx/spdx) and tracks vulnerabilities over time. While not a generator, it is open source and helps validate/monitor SBOMs.
- SBOM Validators: The Linux Foundation hosts an SBOM Validator to check conformance to the NTIA minimum elements (JSON report). CycloneDX CLI also validates BOM schema. Additionally, SBOM-Validate is a Python tool for this purpose.
This is not exhaustive, but these tools are battle-tested in many environments. They are recommended starting points for generating and verifying SBOMs. Always keep them updated, as the SBOM standards evolve.
Conclusion
A Software Bill of Materials (SBOM) is a very important part of software supply chain compliance and security. With the help of SBOMs, organizations can create their own inventory of the software components and as such, track vulnerabilities, manage licenses, and build confidence in third-party software solutions. It is for this reason that SBOMs are a requirement from the governments and regulatory bodies across the globe, such as the requirement from the US government on the use of the SBOMs for their federal software, as well as the EU Cyber Resilience Act, which makes it mandatory for organizations that sell digital products.
Nevertheless, SBOMs can only be effective when they are integrated into systems or processes. One of the most effective SBOM programs is the one that not only generates the SBOMs but also validates them in advance. It stores SBOMs in the system for reference and for further analysis. The SBOMs must include information on the relationships and context for the SBOMs to help the security teams differentiate between real and potential threats.
Implementation-wise, pick standard formats (SPDX, CycloneDX), use robust open-source tools (Syft, CycloneDX CLI, etc.), and write CI jobs that run SBOM generation after each build. For example, a GitHub Actions workflow can call Syft and Grype to produce a CycloneDX SBOM and scan it, as illustrated above. Track metrics like SBOM coverage and vulnerability response times to measure success.Looking ahead, SBOMs will broaden to cover machine learning components, hardware/firmware, and cryptography inventories. But the core message remains: without knowing what components are inside our software, defending against supply-chain attacks is guesswork. An SBOM program provides the indispensable ingredient list that underpins modern security and compliance.
FAQs
1. Is it obligatory for every organization to have an SBOM?
Not every organization is obliged to have an SBOM. Nevertheless, in several regulated sectors, such as US federal software supply chain, medical devices, and digital products within EU, an SBOM will be dictated.
2. How to differentiate SBOM from SCA?
SCA is used to identify the software dependencies, licenses and vulnerabilities and create an SBOM as an output
3. Must we choose either SPDX or CycloneDX?
Both SPDX and CycloneDX are used as SBOM formats. The decision as to which one to use will depend on the requirements of your business as well as the tools that you use.
4. In what way can SBOM help improve security with Docker containers?
An SBOM provides detailed information about each of the components being included in the container image as well as their respective applications and libraries.
5. How often should SBOMs be updated?
An SBOM should be updated whenever the software changes. This includes new releases, patches, dependency updates, container rebuilds, or deployments. In CI/CD pipelines, SBOM generation should be automated for every build.
