This is the first in our series on SBOMs, where we’ll dive into: 

1. Who should be generating SBOMs and why
2. How to generate SBOMs at scale
3. How to ingest and manage SBOMs as part of your regular app development process
4. Understanding external SBOM references to improve automation

Much of this series will focus on high level processes and ideal practices, and less so on the actual implementation details, so if you’re looking for those check out the last post in the series here.

If you need a refresher on what an SBOM is, check out our post SBOM 101: What is an SBOM and Why Are They Important

At a high level, SBOM stands for software bill of materials and it’s a list of all of the individual components used in a software application, like a list of ingredients in a recipe. SBOMS are useful for a variety of reasons, including to more easily manage and make updates to software inventory. They are also mandated under several cybersecurity and privacy standards for industries like financial technology (FinTech) and medical devices that handle sensitive data.

Who Should Generate SBOMs?

So, who actually needs to generate SBOMs now, who should start to think about generating SBOMs, and who might not care? Spoiler: everyone developing, building, or deploying software should care!

At a high level anyone producing software should understand what an SBOM is and should understand how to consume one. There are many indications that governments and industries are moving toward requiring SBOMs and certain regulations are likely to require SBOMs soon and in some cases already require them. SBOMs might not be perfect but they have come a long way, especially with the newer versions of the two most common SBOM specifications, CycloneDX and SPDX.

So who…?

Commercial Software Developers and Vendors

Software developers and vendors building and providing software products have the best visibility into the components, libraries, and dependencies used in their software. Because of this they can usually generate the most accurate SBOMs. By providing SBOMs they ensure that they meet their own compliance and regulatory requirements as well as those that their consumers might need to satisfy. Even without any hard regulatory requirements, providing SBOMs builds trust by demonstrating transparency and attention to security.

Open-Source Project Maintainers

Most software today (including commercial software) relies heavily on open-source components. Open-source project maintainers should provide SBOMs to ensure consumers of the open-source software understand the project’s components and can utilize the open-source software’s SBOM for their own insight and requirements.

SOOS offers a free Community Edition for open-source project maintainers which allows them to manage their projects and provide public SBOMs, including any attestations they might make, as part of the SOOS public SBOM database which now includes 97+ million SBOMs.

DevOps, DevSecOps, and CI/CD Teams

Automatically generating SBOMs as part of a CI/CD pipeline is a simple and effective way to have SBOMs available which can then be included with a software release. Generating SBOMs during the build or deployment process ensures accuracy by assuring what is built/deployed is what the SBOM is actually based on, and of course doing this automatically reduces manual effort.

Selecting the correct tool is very important and there are a number of considerations. First, selecting a tool which supports the programming language(s) in use is essential. Without this support most results are usually just based on the file name and file properties, which is pretty useless. Second, having a tool which can inspect the full dependency tree is a big benefit as it ensures all the components that are referenced are included in the SBOM. Finally, selecting the correct type of SBOM (source, build, etc. – see below) can impact the tool that is selected.

Third-Party Software Integrators

Companies which integrate third-party software into their own products should leverage SBOMs. I say leverage here, because they should be doing more than just generating SBOMs. As a third-party integrator (and to some extent commercial software developers too), the software being integrated may come in a form which makes it difficult to generate an SBOM (such as binaries). Instead the software should be (and increasingly is) provided with an SBOM from the original software producer. In these circumstances, the Third-Party Software Integrators should be including and referencing these external SBOMs into their own SBOM when it’s created for their software product. We’ll dive into this more in a later post when we discuss External SBOM References. Suffice it to say, creating these composite SBOMs, should be the main output of Third-Party Software Integrators. Additionally, the SBOMs that the integrator receives should be continually monitored by them so that they are aware of any issues being introduced, be it security vulnerabilities or other risks.

Procurement or Supply Chain Managers

Similar to Third-Party Software Integrators, Procurement or Supply Chain Managers should be requesting and preparing to receive (as well as manage) SBOMs from the vendors providing the software they are procuring. Unlike Third-Party Software Integrators however, the goal of the procurement process is generally not to produce composite SBOMs, but instead to monitor the incoming SBOMs for issues, which of course might include security vulnerabilities, license issues, or other company specific requirements. The ability to automatically ingest and manage a large set of SBOMs across multiple versions and products, and then to continually monitor for risks, is critical to the success of the procurement process.

Why Should We Generate SBOMs (Benefits)?

We’ve already touched on much of this above, but we can expand on the specific benefits and what they mean for an organization.

• Transparency/Insights
  • By listing all components, dependencies, and libraries (and also listing any components that may be unknown), consumers can be assured that they have the full picture of what goes into a piece of software.
• Security Risks
  • There is some debate as to whether vulnerabilities should be in SBOMs or should just accompany SBOMs as VEX documents (both CycloneDX and SPDX support vulnerability details to some degree). Either way, if the consumer has a list of all components they can determine the potential vulnerabilities and address these risks as they see fit. Personally, I feel that having the vulnerability details (or at least the vulnerability identifiers) is even better because then the consumer can cross reference their own findings with what was reported!
• N-Day Response
  • In cases of critical N-Day security disclosures (like Log4Shell or the recent zLib vulnerability), SBOMs (especially if properly managed in a centralized, queryable tool), can provide an almost instantaneous way to identify impacted software and systems.
• Compliance
  • Many regulatory requirements (such as the U.S. Executive Order 14028, FDA medical device guidance, etc.) are starting to mandate SBOMs for transparency and risk management. In cases where they are not mandated now, it’s likely that SBOMs will be required soon, or that they will satisfy the requirement even if an SBOM is not explicitly called out.
• Enable Better Software Maintenance
  • SBOMs can be a means to track outdated or unsupported components (if the data is available), helping to ensure timely updates and reduce technical debt.
• Open-Source Software Governance
  • Open-source software licensing is an often overlooked area of software compliance, however these legal requirements are incredibly important and can get companies in a lot of trouble if they are not aware of them. Just like having an inventory to query for vulnerabilities, having an inventory of licenses to query is a simple way to ensure compliance. Adding a governance layer on top which automatically ensures compliance is even better.

Types of SBOMs

Not all SBOMs are created from the same source or for the same purpose, they have different input and include different information based on when and how they are generated. The types of SBOMs more or less fit with the Software Development Life Cycle (SDLC).

Design SBOM – An SBOM representing the initial proposed design of the software, including planned components, libraries, and dependencies. Occurs during the planning, requirements analysis, and/or design phases of the SDLC.

Source SBOM – An SBOM generated from the source code of a specific piece of software. It typically includes an inventory of components, dependencies, and libraries specified in the source code, or installed by package managers. Occurs during the coding (implementation) stage of the SDLC.

Build SBOM – An SBOM generated during the software build process. It typically includes the components, dependencies, and configurations used in the assembly of the final software artifact. Straddles the coding (implementation), and testing phases of the SDLC.

Analyzed SBOM – An SBOM which has undergone additional analysis beyond just listing components, dependencies, versions, and metadata. Typically this includes enriching the SBOM with additional security, license or other organizational risks. The original un-analyzed SBOM typically starts as one of the other SBOM types. This usually occurs during or after the generation of a source or build SBOM, so may occur during the coding (implementation), or testing phases of the SDLC.

Deployed SBOM – An SBOM which reflects the actual components and dependencies in a deployed, running software system. It typically includes a snapshot of the software components, including any updates, configurations or post build changes. Occurs as part of the deployment SDLC stage.

Runtime SBOM – A dynamic SBOM generated from analyzing software as it is running in a deployed system. It typically includes components and libraries that are loaded or executing, but not the broader system components as is the case with a Deployed SBOM. Begins directly after the deployment stage of the SDLC and continues for the duration of the maintenance stage of the SDLC, until the application is no longer running.

A Quick Overview of SBOM Regulations

The requirements around SBOMs are a moving target, so be sure to do your own research for your industry, but at a high level here are some requirements to be aware of.

U.S. Federal Regulations

Executive Order 14028 (Improving the Nation’s Cybersecurity) – Issued by President Biden in May 2021, this requires that federal agencies and their software suppliers must provide SBOMs to help enhance software supply chain security.

European Union (EU)

Cyber Resilience Act (CRA) – Adopted in October 2024, this imposes cybersecurity requirements on products with digital elements. Although SBOMs are not explicitly named, SBOM-like documentation is expected as part of transparency requirements for software supply chains and of course SBOMs are a great way to provide this documentation.

U.S. State-Level Regulations

California IoT Security Law – Effective as of January 2020, it requires device manufacturers to implement reasonable security features. While it does not explicitly call out SBOMs, SBOMs help provide transparency.

Standards Encouraging SBOMs

ISO/IEC 27001 and ISO/IEC 27002 – SBOMs can be used as part of the software asset management and supply chain mitigation requirements.

NIST Secure Software Development Framework (SSDF) – SBOMs are part of recommended practices for identifying and managing vulnerabilities in software components.

CISA SBOM Initiatives – Cybersecurity and Infrastructure Security Agency (CISA) is actively promoting SBOM adoption to improve software transparency and supply chain security.

Industry-Specific Regulations

Healthcare (U.S.) – SBOMs can be used to identify and address vulnerabilities according to the FDA’s cybersecurity guidance for medical devices.

Energy Sector – SBOMs can be used to provide transparency in software supply chains for critical infrastructure according to The North American Electric Reliability Corporation (NERC) and other regulatory bodies.

Wrap-up

As we’ve discussed, anyone involved in developing, integrating, or procuring software systems should understand and be prepared to generate and ingest SBOMs. Some vendors and industries are already encountering this requirement sooner than others.

Putting a system in place sooner rather than later which can handle not only SBOM generation, but also SBOM ingestion, ongoing monitoring, governance, and SBOM organization at scale will be critical for many companies. If you would like to learn how SOOS can provide all these capabilities and more, drop us a line, we’d be happy to give you a demo, sign up for our free fully functional trial, or just try out our demo app.
Stay tuned for our next post Managing SBOMs at Scale: Generating SBOMs.