Records and SBOMs

This page explains the package identity inside an execution record and how a record chains to an SBOM or an attestation. It is a sibling of Execution Records, which covers switching recording on and what a record promises.

What pkg:oci buys

packages[].uri is a purl of type pkg:oci. The version is the sha256 digest and tag is advisory, matching OCX’s digest-is-identity model.

The packages[] entries are field-for-field an in-toto ResourceDescriptor. They drop into an SLSA resolvedDependencies list without reshaping if an attestation flow is ever built on top. Sigstore, Tekton Chains and GUAC all consume in-toto shapes.

The claim is narrow, so nothing is promised that is not delivered. A purl gives a stable, standardized identity string, the same shape Trivy emits. It joins across tools and stays forward-compatible if records ever feed an SBOM or attestation pipeline.

It does not give vulnerability lookup. OSV has no OCI ecosystem and treats purl as informational rather than a query key. Grype decomposes an image into its constituent packages and matches those, so a whole-artifact pkg:oci purl gets zero CVE matches.

CVE visibility into a packaged binary would require the package’s upstream ecosystem purl carried alongside. That is a separate feature, not a side effect of this one.

Chaining to an SBOM or attestation

A record answers “which exact digests ran” and says nothing about what is inside those digests. ocx package sbom answers that second question. The two chain through a key the record already carries, with no format change on either side.

execution record  →  "these exact digests ran"
        │ packages[].digest.sha256 is the join key
        ▼
ocx package sbom <digest>  →  "and here is what is inside them"

The join is deliberately a digest, never a name or a purl. ocx package sign and ocx package attest bind every signature and attestation to the manifest digest alone. The verification pipeline hardcodes the sha256 algorithm and ignores the subject’s name field entirely. A name-keyed or purl-keyed join would match on a field the pipeline never treats as binding. packages[].digest.sha256 in a record is that same digest.

To confirm that what ran was also what was approved, read the digest out of a record. Hand it to ocx package sbom or ocx package verify --attestation.

digest=$(jq -r '.packages[0].digest.sha256' /var/log/ocx/records/*.json)
ocx package sbom "registry.example/cmake@sha256:${digest}" --summary
ocx package verify --attestation -p linux/amd64 "registry.example/cmake@sha256:${digest}"

Both commands need a package that carries an SBOM attestation, which ocx package attest attaches (see Attest and SBOM). With --summary, the sbom listing gains a detail such as , CycloneDX 1.5 with 42 component(s) under cmake.