This is the second post in our series on managing SBOMs at scale, where we’ll dive into defining goals around SBOM generation in order to determine which type of SBOM to generate, when and how to generate and where you might store SBOMs. If you haven’t read it yet, check out our first post “DevSecOps Roadmap: Do I Really Need SBOMs?”.

Problems & Goals

Before generating an SBOM, it’s crucial to define its purpose and the problems it will address. Setting clear goals upfront helps determine the type of SBOM to generate, the necessary data to include, and when, how often, and where to store it.

As we discussed in the first post, there are many benefits that come with generating SBOMs, these can be loosely mapped to some common goals (of course you may have others besides these).

Compliance

Compliance is becoming a major driver for SBOM adoption. This includes not only external regulations but also internal compliance requirements. SBOMs can support various compliance efforts, such as:

Regulatory Compliance
SBOMs can help meet external regulations that explicitly require them or may simply assist in achieving compliance goals.

Reporting and Auditing
SBOMs serve as technical reports or documentation for internal or external auditors. Since they typically list all components an application uses, they can help identify specific components during security incidents or N-day vulnerabilities. When generated regularly and stored centrally, SBOMs also provide valuable snapshots of component versions over time.

License Compliance
Legal teams often require license compliance to mitigate risks associated with software licensing requirements. SBOMs, which usually include licensing details for all components, can directly support a company’s license compliance processes.

Incident Response

SBOMs play a significant role in incident response, particularly when generated regularly (such as for each deployment) and stored in a centrally managed, queryable location (more on this in the next post).

Incident Investigation

While SBOMs may not immediately offer an easy way to query components across multiple applications, they provide crucial component and version data snapshots. These snapshots are essential during incident response activities. Generating SBOMs for each published version or deployment captures the necessary context to support investigations. In multi-application systems, these snapshots help identify which parts of the system are impacted by N-day vulnerabilities.

Postmortem Evidence

SBOMs are valuable for postmortem reports, documenting the components and versions present—or absent—during an incident. This is especially important when incidents involve previous application versions with different component references than what might be currently deployed. Without SBOMs this data is typically hard to track down.

Increase Transparency

If the goal is to increase transparency in your software, SBOMs offer the necessary data. They provide visibility into the supply chain by listing identifiers, versions, dependencies, and other key information. Providing SBOMs to customers builds trust and demonstrates a company’s commitment to reliability and security.

Vendor/Customer Requirements

Due to compliance requirements and the growing need for transparency into lower-level software components, customers are increasingly requesting or requiring SBOMs. These requests often support their compliance efforts or security processes for software verification and monitoring. Creating SBOMs—especially for customer-facing applications—ensures you’re prepared to share them when needed. Additionally, SBOMs promote interoperability between organizations and tools, as formats like SPDX and CycloneDX are becoming widely recognized and supported.

Support Strategic and Business Goals

We’ve explored various business and strategic goals that SBOM generation can support, including those mentioned and any others SBOMs may help address. The true value lies not just in the SBOM itself—though it’s explicitly required in some regulatory contexts—but in the process of regularly gathering this information and storing it in a centralized, accessible location. 

Which Type of SBOM Do I Generate?

In our first post, we previously discussed different types of SBOMs, such as source and build SBOMs. Now that we’ve defined several goals, let’s explore which SBOM types best support each objective.

Compliance
Except for design SBOMs, most SBOM types can address compliance requirements, depending on the data needed. For legal compliance, source, build, or deploy SBOMs are typically suitable. For regulations requiring vulnerability and mitigation data, an analyzed SBOM or an SBOM paired with a VEX document containing vulnerability and attestation data is generally necessary. We’ll cover attestations and VEX documents in our next post.

Incident Response
While many SBOM types are helpful for incident response, an analyzed SBOM is often the most useful because it includes additional data, such as known vulnerabilities at the time of generation. This information is crucial for assessing whether an N-day vulnerability was already known. If an analyzed SBOM is unavailable or lacks vulnerability data, source, build, or deploy SBOMs are still valuable for identifying components and versions present during the incident.

Increased Transparency
Transparency is a fundamental goal of SBOMs, and any type can support it. However, the choice depends on the software being developed or deployed:

• For reusable internal libraries, a source or build SBOM is likely suitable.
• For deployable software intended for external use, a build or deploy SBOM is usually more appropriate.
• For hosted applications with regular updates or patches, a runtime SBOM may be ideal.

Vendor/Customer Requirements
In most cases, a source or build SBOM will suffice. However, providing an analyzed SBOM or an SBOM with a VEX document can be valuable to downstream consumers, demonstrating awareness of specific vulnerabilities and attesting to their irrelevance or providing appropriate workarounds.

Where & When Do I Generate SBOMs?

Ultimately, the decision comes down to your goals, but some general guidelines can be adapted to your specific use cases. Here, we’ll focus on source, build, deploy, and analyzed SBOMs, excluding design and runtime SBOMs as they are either created before coding and typically don’t reflect the exact components and versions used (for design), or are dynamic, updated on the fly as applications run, and limited to post-deployment environments (for runtime).

Before discussing where and when to generate SBOMs, it’s important to note that the programming languages, frameworks, technologies, and tools you use significantly impact the types of SBOMs that can be generated. While we won’t list all variations here, it’s crucial to assess these factors upfront to ensure compatibility with your chosen SBOM types. For simplicity, we’ll assume that the language, framework, technology, and tool align with your SBOM generation needs.

Examples

The ideal scenario is generating SBOMs automatically as part of a CI/CD pipeline or post-deployment, following rules tailored to your organization’s needs. Let’s explore two examples.

SaaS Company Example

Consider a SaaS company hosting an application where all user interactions occur directly with the company’s system. They use a Git feature branch workflow, with the mainline branch always releasable, feature branches for development, and a weekly CI/CD-driven deployment. The company relies on modern languages and package managers, making source or source + analyzed SBOMs suitable. Their primary goals are regulatory and license compliance, with occasional use for incident response.

The most logical point for generating SBOMs is during the mainline build/deploy process. Since feature branches are deleted after merging, generating SBOMs only for mainline builds minimizes processing, build time, and storage requirements. Further optimization can involve generating SBOMs solely during deployment since intermediate builds never reach production. By focusing on relevant SBOMs, the company avoids wading through unnecessary ones created for transient branches or un-deployed builds.

Software Provider Example

Now, consider a company that distributes software for customers to install on their infrastructure. They use a Gitflow workflow with mainline, develop, release, feature, and hotfix branches. The CI/CD system packages software for customer distribution rather than deployment. They work with a mix of modern package-managed and older languages like C. Their goals include compliance, incident response, postmortems, and providing SBOMs to customers upon request.

Given their more complex SDLC, careful planning is essential. Since everything flows through a CI/CD system, that remains the best place to generate SBOMs. The optimal point is during the packaging stage, ensuring the SBOM reflects the exact code customers will use. Different SBOM types may be tailored for each language: for instance, source + analyzed SBOMs for modern languages and build + analyzed SBOMs for older ones. The tool choice and configuration should ensure the SBOM captures all necessary data to meet the company’s goals.

Key Takeaways

These examples illustrate the flexibility of SBOMs and how systems can be configured to generate them automatically at logical points within the SDLC. By aligning SBOM generation with business goals and technical requirements, organizations can ensure they provide meaningful, actionable insights while minimizing inefficiencies.

Check That SBOM Data!

One final note, ensure that the data provided by the tool is the data needed to satisfy your use cases. Some trivial things that are often overlooked by tools include the lack of:

• A timestamp when the SBOM was generated.
• The person or entity that produced the SBOM (in the cases of shared SBOMs this can be critical to tracking down issues/clarification with the SBOM).
• Cryptographic validation of the SBOM to ensure it has not been tampered with.
• A lack of identification for the application the SBOM represents (this should include the name and version).
• Only including file names which can be useless unless there are file hashes, or component identifier mappings.
• Useless component identifiers (there are many types of identifiers, such as PURLs, CPEs, SWIDs, etc., make sure they work for you).
• Missing component versions.

Where Do I Store SBOMs?

Where to store SBOMs, like many of the areas we’ve already discussed, depends on your goals.

For infrequent access—such as incident response when incidents are rare—storing SBOMs as assets in your CI/CD system or on disk may be sufficient. Alternatively, integrating SBOMs into an asset management system may be useful for scenarios like tracking physical devices with corresponding SBOMs.

However, for most other use cases—and even for streamlining incident response—a centralized, queryable storage solution is critical. This approach allows for quick and efficient user research into SBOM contents, ongoing component monitoring, and cross-SBOM searches that provide insights into vulnerabilities and components across larger systems.

We’ll dive deeper into these concepts in our next post on Ingesting, Managing, and Monitoring SBOMs.

Creating SBOM Relationships

Our final post in this series will explore the concept of External SBOM References, or more accurately, dependencies between SBOMs. The ability to ingest external SBOMs (which we’ll cover in the next post) and link them to your own generated SBOM is crucial for creating accurate SBOMs for large, complex applications.

To simplify this concept, imagine an application that uses a third-party component, with the component provider offering an SBOM. When generating your application’s SBOM, you need to reference the external SBOM for that component. This process of linking dependent SBOMs is key to ensuring accuracy.

It’s important to be aware of the concept at a high level, as it can play a vital role in SBOM generation when leveraging external SBOMs, especially in complex applications and systems.

Wrap-up

If I had to highlight one key takeaway from everything we’ve discussed, it would be to prioritize defining your goals. Once you have a clear understanding of those goals, the rest falls into place. You can determine the type of SBOM, the tools to use, when to generate them, and how to store them by simply aligning these choices with your goals and considering the limitations imposed by your language, framework, and technology.

Start defining those goals and then put a system into place to start generating SBOMs! If you would like to learn how SOOS can provide SBOM generation, as well as ingestion, monitoring and a lot more capabilities, drop us a line, we’d be happy to give you a demo, or sign up for our free fully functional trial and start scanning SBOMs today.
Look for our next post DevSecOps Roadmap: Ingesting, Managing, and Monitoring SBOMs.