# Keep Docker attestation descriptors out of runtime-platform counts > Docker stores attestations alongside runnable image manifests and marks their platform unknown/unknown. Classify the descriptor and its target before reporting supported execution platforms. - Canonical URL: https://update.dsesecurity.com/updates/keep-docker-attestation-descriptors-out-of-runtime-platform-counts/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T19:49:16+00:00 - Modified: 2026-10-29T19:50:09+00:00 - Last reviewed by DSE: 2026-10-29 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Docker stores attestations alongside runnable image manifests and marks their platform unknown/unknown. Classify the descriptor and its target before reporting supported execution platforms. ## Potentially affected Review scope: Docker BuildKit attestation index descriptors and the documented OCI-artifact versus compatibility format; authenticity verification and policy acceptance are separate. ## DSE recommendation Identify attestation descriptors and referenced image manifests separately, preserving the evidence while counting only the intended runnable platform entries. ## Article 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](https://docs.docker.com/build/metadata/attestations/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](https://docs.docker.com/build/metadata/attestations/attestation-storage/) — Docker Docs. Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Docker Docs — Image attestation storage - Authority: docs.docker.com - URL: https://docs.docker.com/build/metadata/attestations/attestation-storage/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep Docker attestation descriptors out of runtime-platform counts,” DSE Security, https://update.dsesecurity.com/updates/keep-docker-attestation-descriptors-out-of-runtime-platform-counts/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.