DevSecOps Roadmap Part 3: Ingest, Manage, and Monitor SBOMs

This is the third post in our series on managing SBOMs at scale, where we’ll dive into how to ingest, manage and monitor SBOMs that you receive. If you haven’t read them yet, check out our first two posts “DevSecOps Roadmap: Do I Really Need SBOMs?” and “DevSecOps Roadmap: Generating SBOMs”.

In previous posts we talked a lot about the types of SBOMs, when and how to generate them, but glossed over what to do with them. If you’re following the guidelines outlined in the previous post and are starting to generate SBOMs for every build or deployment of every application or some other cadence that fits your needs, you’ll soon appreciate that the management of these SBOMs, especially if you need to pull data out of them, will quickly become challenging. In the case of complex systems where there are many, many applications with frequent releases and interdependencies between releases, this quickly becomes untenable. Or worse yet, imagine a scenario where you are receiving external SBOMs for components that your applications leverage, so now have a mix of your own SCA results, as well as a set of SBOMs which need to be married together when you generate your own SBOMs– seems like a bit of a nightmare. Well, as we will see in this post and the next, it is possible, and with the right tools and building on the previous posts it’s quite achievable and can be automated!

Ingesting SBOMs

SBOM Ingestion can mean different things depending on the tool. Sometimes it’s as simple as storing SBOM files without understanding their contents—but that’s not what I’m referring to here.

True SBOM ingestion involves a system that takes an SBOM (from either internal or external sources), parses it, and extracts key data such as document metadata, component details (identifiers, versions, etc.), dependency hierarchies, vulnerabilities, licenses, and attestations (if they exist). This data is then organized so it can be queried, rules can be created, alerts can be set up and relationships can be built between SBOMs, as well as between the SBOM and dependent applications. This ideal state transforms SBOMs from simple component snapshots to powerful dynamic tools that provide insight and support business requirements, such as tracking threats, attestations, license issues, etc.

Ingestion is the first step toward fully organizing, querying, and monitoring SBOMs. Many “management” tasks, as we’ll discuss in the next sections, can be automated during ingestion. This includes organizing SBOMs through naming so they align with an organization’s application naming, applying version data, and linking dependent SBOMs—something we’ll cover in more detail in the next post.

Managing SBOMs

Effective SBOM management goes beyond simple storage—it involves organizing SBOMs within the larger context of an organization’s applications. This includes logical naming, versioning, linking to other assets, managing relationships between SBOMs, and implementing governance rules.

SBOM Component Naming

Here we are referring to the name of the component or application that the SBOM represents (not the individual component names which make up the contents of the SBOM). Assigning meaningful names during SBOM generation ensures clarity about which component or application the SBOM represents. However, when receiving SBOMs from external suppliers, names may be unclear, missing, or incompatible with internal naming expectations.

To address this, names should be applied during SBOM ingestion but allow for post-ingestion renaming to align with the organizational expectations.

SBOM Component Versioning

Here again we are referring to the version of the component or application that the SBOM represents (not the individual component versions which make up the contents of the SBOM). Accurately reflecting the component or application version within the SBOM is essential and is really the job of the creator. Versions should be automatically applied upon ingestion and, unlike names, should not be editable unless they are missing. This ensures that the original versioning is retained. Unlike names, versions are typically more standardized and less likely in need of adjustment.

SBOM Relationships

This involves linking SBOMs to other SBOMs, components, or applications within an organization. These relationships help create a comprehensive view of the software ecosystem both in the SBOM management tool itself, but they also should be maintained when generating complex SBOMs that need to display these relationships.

We’ll dive deeper into this topic in the next post.

Links to Physical Assets

Organizations managing physical assets may need to associate ingested SBOMs with these assets. This can be achieved by:

Linking out to an SBOM (using component names and versions) from within an asset management system.
Linking to an asset management system using asset identifiers from within the SBOM management system.

These links can be one-directional or bi-directional, depending on organizational needs. The key piece being the ability to locate the SBOM or asset quickly and correctly based on the name and version, keeping in mind that multiple versions of a physical asset may very likely exist.

Vulnerabilities and Attestations

There is some debate about if, when, and how vulnerabilities should be represented in SBOMs, therefore we’ve previously avoided delving deeply into vulnerabilities, however vulnerabilities and attestations become critical to discuss at this stage. SBOM formats like CycloneDX, SPDX, or VEX handle vulnerabilities and attestations differently, but for simplicity, let’s define them as:

Vulnerabilities: Identifiers for security issues detected in components.
Attestations: Statements regarding a vulnerability’s status (e.g., “not exploitable,” “false positive,” or “only exploitable in specific conditions”).

Keep in mind that this is a bit of an over simplification of the possible fields and states supported by SPDX, CycloneDX, and VEX.

During the ingestions process, both vulnerabilities and attestations should be included, their state after ingestion should indicate that further action is required to review the findings:

Vulnerabilities:

Any vulnerabilities found in an SBOM should be imported and flagged as originating from the SBOM.
The system should independently analyze the component, confirming vulnerabilities, identifying new ones, or flagging unverifiable issues.

Attestations:

Attestations from the SBOM should be ingested and marked as unverified.
Users must review attestations, confirm or dispute them, and optionally add additional findings.

Governance Rules

Governance involves the creation of rules to automatically ensure specific component data, such as checking for acceptable licenses, missing licenses, or unacceptable components. When SBOMs are ingested into systems like SOOS, which support unified governance for both SCA and SBOMs, governance rules can seamlessly apply across both domains, eliminating redundant configurations.

By organizing SBOMs through thoughtful management, companies can unlock their full potential—transforming static lists of components into dynamic tools for security, compliance, investigation, and asset tracking.

SBOM Monitoring and Research

The continuous monitoring of SBOMs involves tracking the components within them for newly identified vulnerabilities, license issues, and other critical business requirements. This process should also enable querying SBOMs in the context of a larger system to quickly identify applications that use specific components, versions or contain vulnerabilities.

Initial Analysis During SBOM Ingestion

When an SBOM is first ingested, an in-depth analysis should be performed to determine if there are new insights (specifically vulnerabilities) which were not available when the SBOM was initially created or which were not identified by the original tool generating the SBOM. In the case of un-analyzed SBOMs, this process can ensure that the SBOM is essentially transformed into an analyzed SBOM. This initial analysis should include:

Component Resolution: Identifying actual software components and versions based on provided identifiers.
Vulnerability Validation: Confirming listed vulnerabilities and detecting any newly identified threats.

This process ensures that the most up-to-date information is available for review and action. It is crucial that the original information in the SBOM is maintained and newly identified information is highlighted for user review.

Ongoing Monitoring for New Intelligence

Continuous monitoring involves re-running the initial analysis on a regular basis to capture the latest updates, particularly regarding vulnerabilities. This approach ensures that newly discovered “N-day” vulnerabilities are flagged and users can take proactive action based on emerging threats. Essentially, the SBOM transitions from a static record to a dynamic, living document that reflects real-time insights.

For compliance, incident response and other activities, ongoing monitoring provides visibility into both the original state of the SBOM and new threats, making it easier to track when specific vulnerabilities were first identified.

Cross-SBOM Queries for Component, Vulnerability, and License Management

Centralizing SBOMs in a system that supports cross-SBOM searches (and ideally integrates with application scan results as well) provides powerful capabilities for:

Incident Response: Quickly identifying affected components or applications.
Vulnerability Exposure: Tracing potential security issues across systems and identifying systems affected by N-day vulnerabilities.
Component Identification: Streamlining efforts to locate specific versions or libraries.
License Management: Ensuring compliance with organizational policies.

This centralized, queryable approach makes incident response, risk mitigation, and compliance tasks efficient and manageable, turning SBOMs into valuable assets for security and operational intelligence.

A Cross-SBOM Query Example

To illustrate the power of cross SBOM queries, let’s take a quick look at the Security Dashboard in SOOS, which allows you to query for specific CVEs across your entire organization (in this case an organization consisting of 10,000+ SBOMs).

Well, that’s not too bad, only 4 SBOMs are showing log4shell, maybe we should check for that zlib vulnerability, Yikes!

All these systems are being represented by SBOMs that were ingested, however in SOOS they could be a mix of SBOM, SCA, and Container results, all queryable within seconds.

Just to quickly dive into one result here, we can see the benefit of calling out vulnerabilities identified as part of the ingestion process. As mentioned earlier, having a clear mechanism to differentiate between vulnerabilities present in the original SBOM and those newly identified during ingestion helps users understand when and where each vulnerability was discovered.

Wrapup

While standalone SBOMs are useful, they can quickly become overwhelming and inefficient. Ingesting SBOMs into systems that support ongoing management and monitoring, along with queryable searches across multiple SBOMs and existing software systems, provides organizations with essential tools to achieve their security and operational goals.One last post to go, and this is a technical one! Check out DevSecOps Roadmap: Leveraging External SBOM References to dive in.