Supplier SBOM: How to Validate and Use It in Practice

A supplier completed a delivery and sent along a file such as bom.json or sbom.spdx.json.

The first reaction is usually positive: finally, there is a structured list of the components used in the software.

The second question is harder:

Now, what do we do with it?

An SBOM does not reduce risk simply by existing.

Its value appears when the organization can validate the document, link it to the software received, enrich the data, and transform the inventory into security, operational, support, and response decisions.

Start with identity: does this SBOM belong to the software I received?

Before looking for CVEs, there is a more fundamental question.

The SBOM must correspond to the exact product, version, and artifact being evaluated.

Check, when available:

Product name;
Version;
Supplier;
Generation date;
Component identifiers;
Relationships between components;
Hashes;
Format version;
Generation tool or process;
Reference to the corresponding artifact or release;
Provenance information;
Signing or attestation mechanism, when available;
Evidence of SBOM integrity and authenticity.

If the supplier delivered version 5.4.2 of the product, but the SBOM represents 5.3.9, the analysis may be technically correct and operationally useless.

The same applies to an SBOM generated from a manifest that does not reflect the final artifact.

SPDX or CycloneDX is not the first decision

SPDX and CycloneDX are widely used formats for representing composition and related information.

While SPDX is an open international standard whose 3.x specifications expand the model to various BOM types, CycloneDX offers specialized capabilities tailored for SBOM, VEX, and other technical inventories.

Format choice matters for interoperability, tooling, and available details, but the consumer should avoid turning the discussion into:

Which format is better?

before answering:

Does the document contain the data we need to make a decision?

An incomplete SBOM in an excellent format is still incomplete.

Check the depth of the composition

One of the first controls is assessing whether the inventory represents only first-level components or includes transitive dependencies as well.

Consider:

Application
└── library A
    └── library B
        └── library C

If the SBOM presents only library A, a vulnerability or support issue in library C may remain invisible.

The European CRA establishes, in its vulnerability handling requirements, that manufacturers identify and document vulnerabilities and components, including through an SBOM in a commonly used and machine-readable format covering at least first-level dependencies.

This is a specific regulatory minimum under the CRA, not necessarily a sufficient level of detail for all risk scenarios.

For operational security, transitive dependencies are frequently required.

An SBOM is not a list of CVEs

It is important to separate composition from intelligence.

The SBOM primarily answers:

What exists in this software?

The vulnerability analysis answers:

What do we know today about known risks in these components?

These data change at different rates.

An SBOM can remain identical while a new vulnerability is published tomorrow.

Therefore, the correct model is not to analyze the file once and archive it. It is to keep the composition continuously linked to updated sources of:

Vulnerabilities;
Malware;
Licenses;
EOL/support;
Supplier advisories;
Internal policies.

01Received SBOMComposition declared by the supplier
02ValidationIdentity, version, format, and relationships
03EnrichmentVulnerabilities, licenses, EOL, and intelligence
04ContextVEX, exposure, and actual usage
05PolicyAcceptance and exception criteria
06DecisionAccept, remediate, block, or escalate
07MonitoringReevaluate when new data emerges

Malware requires a different question

An SBOM can help locate a component known to be malicious, but having a component list is not equivalent to performing malware detection.

Therefore, vulnerabilities, malware, integrity, provenance, and trust in the source must be treated as complementary signals. A vulnerability can be identified by a known identifier; a compromised or malicious component, on the other hand, requires other intelligence sources and analysis mechanisms.

In practice, the question shifts from merely “does this component have a vulnerability?” to “is this component trustworthy, intact, free of known vulnerabilities, and does it remain acceptable for our context?”

This point is explored in depth in the article:

SCA finds vulnerabilities. But what about malware?

Licensing and support are also part of the decision

The composition may reveal components that:

Use licenses incompatible with company policy;
Have an unknown license;
Have reached end of life (EOL) or end of support (EOS/EOSL);
Are abandoned;
Depend on outdated versions;
Have no clear upgrade path.

An operational SBOM should not be treated solely as input for vulnerability scanning.

It can support security, legal/licensing, architecture, continuity, procurement, and supplier management decisions.

Where VEX fits

VEX — Vulnerability Exploitability eXchange — exists to represent the status of a vulnerability within the context of a product.

Imagine the SBOM identifies a library associated with a critical CVE.

This does not automatically mean the vulnerability is exploitable in the final product.

The component may not execute the vulnerable code, might be configured in a way that the condition does not exist, could have specific mitigations, or might only be present in a stage that never reaches runtime.

A VEX statement can record this context.

CycloneDX, for instance, offers specific support for representing exploitability through VEX.

However, VEX should not be used as an "ignore vulnerability" button.

A not_affected statement must have sufficient justification and context to support the decision, and it must be reevaluated whenever relevant changes occur in the product, component, or exploitation condition.

The supplier should be able to answer questions about the SBOM

Receiving the file does not end the relationship.

A mature procurement process can establish questions such as:

Which product and version does the SBOM represent?
How was it generated?
Does it cover transitive dependencies?
Is it linked to the delivered artifact?
How frequently is it updated?
How does the supplier communicate new vulnerabilities?
Does the supplier publish VEX?
How are fixed versions communicated?
What is the support period for critical components?
Is there a vulnerability disclosure channel?
How are composition changes between releases communicated?

These responses can be incorporated into supplier due diligence and management processes.

The SBOM needs to remain useful after purchase

A common mistake is concentrating all effort on software ingestion.

On the day of acquisition:

SBOM → analysis → acceptance

After that, the file is archived and never consulted again.

The problem is that risk changes.

An application approved today may be affected tomorrow by a new CVE, new evidence of exploitation, a package identified as malicious, EOL, a license change, a shift in criticality, or a supplier advisory.

Therefore, the operational relationship should be continuous:

01ProductKnown version and ownership
02SBOMComposition linked to the product
03IntelligenceContinuously updated data
04PolicyRisk and exception criteria
05OwnerDecision and response

The CRA is accelerating adoption — but generation is only the beginning

In June 2026, ENISA published a report on SBOM adoption.

The research pointed to the Cyber Resilience Act as an accelerator for SBOM initiatives and their integration into the SDLC.

The regulatory push helps increase the availability and standardization of these documents.

However, the evolution of the community itself already highlights the next stage.

In August 2026, the OpenSSF announced BOMHort as a Sandbox project, emphasizing the operational challenge of managing, querying, and analyzing large volumes of SBOMs at scale.

This movement suggests an important shift: the challenge is moving from generating SBOMs to operating SBOMs at scale.

A simple process to get started

It is not necessary to build a complex platform on day one.

An organization can start with five steps.

1. Receive

Define accepted formats, channels, and minimum metadata.

2. Validate

Confirm product, version, structure, and inventory quality.

3. Enrich

Cross-reference the composition with vulnerabilities, malware, licenses, support, and other sources.

4. Decide

Apply policies and record acceptance, remediation, blocking, or exceptions.

5. Monitor

Reevaluate existing products as new data emerges.

SBOM consumption checklist

Before considering an SBOM "processed," verify:

Product and version match the delivery;
Format is valid and processable;
Components have useful identifiers;
Dependency relationships are present;
Dependency depth is known;
Composition was cross-referenced with vulnerability intelligence;
Malware was considered separately;
Licenses were evaluated;
EOL/support was evaluated;
VEX contains justification when used;
Exceptions have an owner and expiration date;
An update and monitoring mechanism exists;
The origin and authenticity of the SBOM were verified, when applicable;
The SBOM has a verifiable link to the analyzed artifact or release.

The decisive test

Choose a third-party software product currently in production.

Take the SBOM delivered by the supplier and try to answer:

If a new critical vulnerability is published tomorrow in a transitive dependency of this product, who will be notified and how long will it take for us to know if we are exposed?

If the answer is "we need to open the file and investigate manually," then the SBOM exists.

But it hasn't turned into operational governance yet.

Sources and references

Does your organization receive SBOMs, but struggle to turn them into decisions?

Xmart supports the architecture, governance, analysis, and operation of Software Supply Chain and AppSec controls.

Request a technical assessment Explore Xmart solutions