GPU Software Supply Chains: What an SBOM and Build Provenance Actually Establish

Start with the software population being described

A GPU application may arrive as an image containing an inference program, runtime libraries and a native preprocessing extension. A component inventory helps explain that population. It needs to make clear whether it describes the finished image, a source package or a wider environment. An inventory of the image cannot silently become an inventory of software supplied separately on its host.

SPDX supports descriptions of packages, files, snippets and relationships, including dependencies and bundled components. That expressiveness helps distinguish a named component from the claim that another component contains or depends on it. A list of familiar names alone leaves those relationships unresolved.

The inventory is a description with a scope and an evidence basis. Receiving it does not, by itself, establish that every relevant component was identified or that its contents were described correctly.

References: [S1]

Build provenance describes production, with different coverage

SLSA v1.2 describes provenance as a statement that a build platform produced identified artifacts through a build definition. Its buildDefinition records the process type, parameters and known resolved dependencies. Its runDetails identifies the builder and details of the particular execution.

These records explain a transformation into an output. They need not be a fine-grained inventory of everything in that output. A compiler can help produce the application without being included in the delivered image. Conversely, a list of shipped libraries does not identify every tool or parameter that affected their production.

This is a distinction between questions, rather than mutually exclusive file formats. SPDX 3.0 includes build information, and its Build profile can express inputs, outputs, procedures, environments and actors. An SPDX document may therefore contain useful evidence for both questions. The conclusion depends on the information actually present.

References: [P1][S1][S2][P3]

Artifact A arrives with an inventory for B

Consider a fictional GPU application delivery called artifact A. The supplier advertises three fictional package labels: Inference Engine version 4, GPU Runtime version 2 and Preprocessor version 1. Its attached component inventory lists those labels but identifies a different artifact, B. A and B are symbolic labels, with no invented digest strings or performed verification result.

The names look relevant to A, but the inventory describes B. It does not establish A's contents. Even an authentic signature on that inventory would authenticate the statement about B; it would not change the object being described.

The missing relationship is between the received artifact and the inventory's stated population. Content identity matters because a digest identifies particular content, whereas a product name or version label can be reused. A digest says neither that the content is permitted for use nor that it behaves acceptably.

An inventory correctly connected to A would address this identity gap. Its accuracy and completeness would still depend on how A's contents were established. Binding the right object and describing that object adequately are separate requirements.

References: [S1][I1][P2]

A signed statement identifies A; trust is still a separate question

Now the supplier adds a signed build statement whose subject identifies A. In the in-toto Statement v1 model used by SLSA provenance, subject entries identify the artifacts concerned by digest. That binding answers which output the build claim concerns. It does not transfer B's component inventory to A.

The signature, subject binding and production expectations do different work. Signature assessment concerns authentication under the accepted trust model. Subject matching concerns the artifact. The expected source, process and builder concern whether the reported production is the production the enterprise intended.

SLSA's verification guidance treats those as distinct checks. A recognizable signer is insufficient if the statement concerns another artifact or reports an unexpected source. The signer and builder are also distinct identities: trust in a signer does not automatically authorize its claims for every builder.

For A, the added statement makes a build claim available for assessment. It supplies no conclusion here that the signature is trusted or that the reported build meets the enterprise's expectations.

References: [I1][P1][P2]

The same component labels can accompany different builds

Extend the example: the supplier now provides separate inventories connected to A and B. Both declare the same three package names and versions. A and B nevertheless come from different builds.

Suppose the fictional build descriptions show that one used the chosen source revision and release process, while the other used modified source or an additional build parameter without changing the advertised package-version labels. Matching inventory rows cannot establish identical inputs or production. Build information is needed to expose that difference.

Different builds are not automatically evidence of wrongdoing. The relevant question is whether each artifact's production agrees with the application's expected origin and process, using evidence the appointed owners can trust. A familiar component list cannot answer that question, and an unchanged version label cannot erase a build difference.

References: [S2][P2][P3]

Keep unknown dependencies visible

An absent dependency record leaves a knowledge gap. It is not proof that the dependency does not exist. SPDX 3.0.1 explicitly distinguishes relationship completeness from incompleteness and from making no assertion. Its Relationship model also distinguishes asserting that no relationship exists from making no assertion about it.

Apply that distinction to A. If its inventory lists the inference program but leaves the preprocessing extension's dependencies unassessed, retain that gap. Do not turn the short list into a conclusion that the extension has no dependencies.

Build provenance has its own completeness boundary. SLSA v1.2 describes resolvedDependencies as best-effort, including through Build L3. A recorded set of build inputs therefore cannot automatically serve as a complete component inventory. Preserve the declared coverage and the unknowns for the appointed application and security owners.

References: [S3][S4][P1][P3]

Acceptable build origin leaves other conclusions open

Evidence that A came from the expected source and builder through the expected process can support its build-origin assessment. It does not establish a complete SBOM, absence of vulnerabilities, correct application output or licensing rights.

The SLSA FAQ distinguishes trust in a single build from trust in all of its dependencies. It also contrasts provenance's build focus with the finer component information typically needed for SBOM uses. Those scopes explain why one favorable conclusion cannot substitute for the others.

An expected build can faithfully produce software containing an existing defect. A well-described component can still be unsuitable for the intended application. Software evidence goes to the enterprise's appointed application and security owners, who assess each claim within its coverage. The result remains a set of supported conclusions and unresolved questions, rather than a secure-product certification.

References: [P3]

Connect the software decision to the surrounding equipment work

The related factory-component article addresses delivered hardware identity. The confidential-computing article addresses the running execution environment. The Arm-container article addresses which CPU-platform artifact is selected. Each concerns a different object or stage; evidence about A's build cannot substitute for those decisions. The disconnected-deployment article separately addresses availability of the required software material.

When the project also needs physical equipment installation, 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 that surrounding work, with a nonconfidential equipment outline, site, released rack and cable plans, and required physical handoff.

The software evidence remains with the appointed application and security owners. The inquiry concerns the agreed physical installation alongside their work.

References: [L1]