SBOM and VEX: separating component inventory from vulnerability status

A component appearing in an inventory and a product being affected by a vulnerability are different statements. Confusing them can create unnecessary upgrade work or leave a customer relying on an assurance that does not apply to its installed release. Software buyers need both a reliable component record and a product-specific explanation of relevant vulnerability status.

An SBOM supplies the inventory. Vulnerability Exploitability eXchange, usually shortened to VEX, carries statements about the relationship between a vulnerability and a product. The commercial value comes from connecting those statements to the customer's actual purchase and maintaining them as the supplier learns more. A VEX file offered only during a sales exercise is a much weaker commitment than an ongoing product-status service.

Identify the statement being made

The OASIS CSAF 2.0 specification provides a VEX profile covering products, vulnerability identifiers and status. It requires an explanation for a product described as unaffected and product-specific action information for an affected product. Its status vocabulary distinguishes fixed versions from versions still under investigation. A fixed version is not necessarily the version the vendor recommends installing.

The OpenVEX 0.2.0 specification expresses a statement through product, vulnerability and status information at a particular time. It identifies the author, gives documents timestamps and versions, and requires the document version to change when its contents change. It also describes how later statements can update earlier knowledge.

These are documented ways of communicating an assessment. They do not make every assessment equally trustworthy. A customer still needs to understand who issued it, which product it covers and why its conclusion should inform the customer's own decision. Selecting a format and selecting a source of authority are separate parts of evaluating the offer.

Match the product before judging the status

The first practical question is whether the statement applies to the delivered product. Similar marketing names can cover different editions, releases and supported environments. A supplier's assessment for a newly issued package may say little about an earlier release still running in the customer's environment.

A useful evaluation follows a product identifier from the purchase record to the inventory and then to the status statement. Each step should be explicit enough for the receiving team to repeat it later. If the supplier relies on a mapping between internal and customer-facing identifiers, that mapping belongs in the supporting documentation.

Our guide to SBOM product coverage examines the inventory side of this relationship. A complete inventory helps establish where a component appears. The status service then needs to explain the significance for the product containing it. Improving one side cannot compensate for a broken identity link on the other.

Configuration scope should be visible where it affects the assessment. The buyer need not request sensitive implementation details to ask whether the conclusion covers the offered standard configuration, an optional integration or a customer-modified edition. An unexplained assumption can become a support dispute when the customer discovers that its purchase sits outside the supplier's intended scope.

Treat uncertainty as a managed state

A supplier may need time to determine whether a newly reported issue affects a product. A clear statement that the question remains under investigation is useful information. It tells the customer that the absence of a confirmed impact is not yet a confirmed absence of impact.

The commercial service should describe what happens next. Who owns the investigation? How will affected customers receive a changed conclusion? What determines the next update when the assessment remains open? Those commitments are more useful than a promise to issue a final answer within an arbitrary period for every possible report.

Consider a hypothetical document-management vendor supporting two releases. It completes its assessment of the current release first while the older supported release remains under review. A dashboard showing one company-wide green indicator would erase a material distinction. A product-specific status record lets the current-release customer act on available evidence while preserving the older customer's unresolved question.

The buying decision is whether the supplier can sustain that distinction across its support portfolio. A small vendor does not need a large public advisory operation to do so. It does need consistent release identities, an accountable assessment process and a communication route that survives changes in the sales relationship.

Ask what supports an unaffected conclusion

A statement that a product is unaffected should explain the relevant basis at a level the customer can evaluate. Repeating the status in more confident language adds little. The evidence might be held in a detailed internal assessment while the customer receives a bounded explanation and a route for authorised follow-up.

The important commercial question is how the explanation relates to the supplied product. Is it a conclusion from the product's maintainer, a statement passed through from a component producer, or an independent assessment commissioned for a particular delivery? Those sources can all contribute, but their scopes differ. The recipient should not mistake a statement about one dependency for a completed review of the assembled offer.

The customer should also know what could cause the conclusion to be revisited. A changed release, corrected component information or new knowledge about the reported issue can make an earlier statement insufficient. This is a reason to maintain the assessment history, rather than treating an unaffected label as a permanent property of the vendor.

For the supplier, a concise and well-scoped explanation can reduce repetitive customer questionnaires. The same defensible record can support several authorised customer conversations, provided its applicability remains clear. That is a tangible support benefit without making an unverified claim about hours saved.

Separate the assessment from the customer's change decision

A confirmed fix answers one question about a product release. The customer may still need to evaluate compatibility, support status and the work required to adopt that release. The supplier's commercial package should connect the security assessment to the release and support information needed for that wider decision.

This is especially relevant where a software company delivers through another platform or integration partner. Our profile of Second Front Systems describes a business operating in that delivery environment. The application supplier, platform provider and customer need to understand which party issues the assessment and which party assists with adopting an updated product.

A buyer should therefore compare support offers using the whole communication path. Can the customer identify its affected purchase, obtain the supplier's current assessment, understand the available supported release and find the responsible contact? A technically valid advisory file is useful, but it is only one element of that path.

Preserve the decision record

Status information changes over time. A later version may close an investigation, correct a product identity or revise an earlier conclusion. The customer's record should retain the statement it relied on, alongside the date and reason for its own decision. Otherwise a later review may compare an old decision with information that was unavailable when it was made.

The supply agreement can define how updates are distributed and how earlier versions remain accessible. The terms should also address continuing access after a customer stops buying new releases but remains within a support period. A public feed, a controlled customer portal or another agreed delivery method can work if it preserves the necessary identity and history.

A credible VEX offer gives a customer a maintained answer to a specific product question. It joins inventory evidence, attributed assessment, time and support responsibility. That lets commercial teams discuss product assurance in concrete terms and helps buyers avoid making a purchase decision from an unexplained vulnerability count or an equally unexplained reassurance.