Keep Docker attestation descriptors out of runtime-platform counts

Bottom line: Classify supplemental attestation entries before turning an image index into a runtime-platform inventory. Keep the target image relationship and attestation evidence available without treating every descriptor as an executable platform choice.

Source fact: documented behavior

The Image attestation storage documentation is the primary reference.

The guide stores attestation manifests separately in the root image index, with each attestation manifest applying to one target platform manifest. The attestation descriptor uses unknown/unknown for its platform to prevent a runtime from pulling or running it as an image. The descriptor annotations vnd.docker.reference.type and vnd.docker.reference.digest identify the attestation-manifest role and its target object. The OCI-artifact form uses a subject descriptor for the target, while oci-artifact=false selects the documented compatibility image-manifest format.

What the source does not establish

This article classifies storage and index relationships. A descriptor, digest reference or claimed predicate is not a completed authenticity or policy-verification result. Keep the established attestation-verification procedure separate, and confirm the actual format rather than assuming all producers use the same representation.

Applicability questions

• Which entries describe runnable image platforms?
• Which descriptors identify attestations and their target digests?
• Is the observed record an OCI artifact or the compatibility form?
• What separate verification policy determines whether the evidence is trusted?

DSE recommendation: retain evidence without counting it as execution

DSE recommends two linked inventories for an index review: intended runnable platform manifests and supplemental attestation records. Preserve each digest and its observed role. Reconcile the target relationship before excluding an entry from the execution-platform list.

Review the actual descriptor fields and documented annotations, not a user-interface label alone. Keep a missing or unexpected role or target reference as an unresolved parsing finding. Do not delete an unfamiliar entry merely to make the supported-platform display look cleaner.

Make the parser’s format branch explicit. Identify how it recognizes the OCI-artifact relationship and how it handles the documented compatibility form. Retain the original index and manifest bytes beside the parser result so another operator can inspect a disagreement without relying on a transformed summary.

Pass the preserved attestation to the separate verification workflow when trust is required. Have that policy owner establish the accepted producer, signature or provenance requirements. Keep a correct inventory classification distinct from a conclusion that an artifact is authentic, compliant or suitable to run.

Verification and evidence

Proposed verification, not performed: use a harmless fixture patterned on the documented index with one runnable platform and its attestation descriptor. Predict both inventories and the target relationship before passing it through the proposed parser. Compare actual output with the raw fixture.

Add a deliberately unknown descriptor role and a mismatched test target as separate negative inputs. If both documented formats are in scope, use a clearly labeled fixture for each. Retain the source bytes, parser revision, classification and unresolved results. Do not invent a trusted attestation or report an unsigned fixture as successful authenticity verification.

Official references

• Image attestation storage — Docker Docs.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.