A Vulnerable Component Match and a Product VEX Status Answer Different Questions

A component name leaves two important relationships unresolved

A component can contain many functions. A product can include that component while excluding the particular code associated with a defect. Another product can include the vulnerable code while providing no executable path to it as used by that product. Component presence, vulnerable-code presence and product execution therefore describe different relationships.

The distinction appears in VEX justification vocabularies. SPDX 3.0.1 separately describes an absent component, absent vulnerable code and affected code outside an execution path. These are explanations of different circumstances, rather than interchangeable ways to say that a package name looks acceptable.

A component match alone does not supply the missing relationships. Conversely, the fact that a function was not observed running in one workload does not establish that the product cannot execute it. A product-path assertion concerns the product's behavior within the stated scope; a quiet observation concerns only what was observed.

References: [J1]

VX-228: one library match, three supplier assertions

Consider fictional software delivery VX-228 with three product revisions, A1, A2 and B1. Stipulate that a scanner matches the same fictional library name, CedarMath, in each revision's inventory to symbolic vulnerability V-EX. V-EX is an invented teaching label, not a real CVE. The name match supplies no code-path analysis.

The fictional supplier issues three product-specific statements concerning V-EX. For A1, status is not_affected and justification is vulnerable_code_not_in_execute_path. Its stated premise is that A1 includes the relevant code but cannot execute it as used by that product. For A2, status is under_investigation: whether this revision is affected remains unknown. For B1, status is fixed: the supplier asserts that this revision contains a fix.

These are stipulated supplier assertions. No scanner run, execution-path assessment, fix validation or security acceptance has been performed. The exercise is to interpret the three claims without upgrading them into observed results.

References: [VX1]

A1's execution-path premise belongs to A1

A1's explanation depends on a relationship between particular code and a particular product. It does not say that CedarMath is absent or that the vulnerable portion was removed. Replacing its justification with a code-absence claim would change the asserted mechanism.

Suppose, as an additional fictional possibility, A2 adds an application feature that calls a previously unused CedarMath function. The unchanged library name would not establish an unchanged execution path. This possibility does not prove that A2 is affected; it explains why A1's rationale cannot settle A2's still-open assessment.

The same boundary applies to the host. A1's statement does not cover another program using a host-installed CedarMath copy merely because the names agree. That other program has a different relationship to the code. Product scope cannot be expanded by a shared dependency label.

References: [VX1][J1]

Preserve what fixed and under investigation actually contribute

B1's fixed assertion concerns a fix in B1. A1's not_affected assertion concerns an execution-path premise in A1. Neither label makes the other explanation redundant: a product can be described as avoiding a vulnerable path, while another is described as containing a fix. The records do not supply a common assessment history or establish that B1 was derived from A1.

A2's under_investigation statement supplies an explicit knowledge gap. It is not a low numerical risk score, a failed test or a passed acceptance decision. Converting it into any of those would add information that the supplier has not supplied.

VX-228 consequently contains one statement of each of the three kinds. It contains no affected statement, but that absence does not prove zero affected products. Three scanner matches do not establish three exploitable systems, either. The count describes the received assertions, not an independently established population of safe or exploitable deployments.

References: [VX1]

OpenVEX makes the claim expressible

OpenVEX 0.2.0 is the named interchange model used here. A complete statement needs product, vulnerability, status and time, even where fields inherit values. Its not_affected field rules require either a justification label or an impact_statement. Labels are recommended; explanatory text may accompany one. VX-228 supplies the explicit vulnerable_code_not_in_execute_path justification for A1.

A recognized label makes the supplier's rationale expressible. It does not demonstrate that the rationale applies. A1's statement could be structurally complete while its execution-path premise was mistaken. Format completeness and assessment truth answer different questions.

References: [VX1]

Keep product revision, statement time and document version distinct

OpenVEX requires an author identifying an individual or organization. Its document timestamp records issuance; a statement timestamp records when the information was known to be true. Statement time overrides document time, which overrides enclosing-document time. Document version must increase when content changes.

Those fields preserve meaning across updates. If the supplier later revises A2's assessment, that new assertion concerns A2 and its applicable time. A1's older conclusion does not acquire a new assessment time merely because it appears beside newer information. Product labels A1, A2 and B1 also remain distinct from the version number of the document carrying their statements.

For the buyer, the useful question is which issuer made which assertion about the supplied revision and V-EX, with what rationale and time. A familiar company name, a more recent document or the same library label cannot individually repair a mismatch in that relationship.

References: [VX1]

Authentication cannot supply missing product analysis

The in-toto Statement v1 model illustrates another useful distinction: an attestation's subject identifies the artifacts to which its claim applies, using digests. Binding a claim to an artifact gives the claim an identified subject. It does not establish the claimed behavior of that artifact.

Similarly, even if a statement is correctly authenticated, an incorrect execution-path premise remains incorrect. Authentication cannot supply an omitted product assessment or turn a statement about A1 into one about A2. This is a reasoning limit, not a reported signature-verification result.

The related SBOM and build-provenance guide addresses component inventory and production origin. Use it for those questions. Here the additional question is the supplier's vulnerability-impact claim for the exact product. Evidence about expected production can coexist with a defect, and a VEX assertion cannot fill gaps in the inventory or build record.

References: [I1]

Connect the software recipient to the physical installation

When the same GPU project needs equipment installed, Leviathan's rack-and-stack service covers agreed mounting, IT cabling, labels and physical installation records. Use the related service and project inquiry to discuss the equipment list, site, released rack and cable plans, target window and receiving team.

Name the appointed software and security owners receiving that physical handoff. They retain the product vulnerability assessment and software-use decision. The installation inquiry concerns the surrounding physical work.

References: [L1]