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.
\nThe Image attestation storage documentation is the primary reference.
\nThe 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.
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.
\nDSE 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.
\nReview 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.
\nMake 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.
\nPass 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.
\nProposed 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.
\nAdd 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.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: documented behavior\nThe Image attestation storage documentation is the primary reference.\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich entries describe runnable image platforms?\nWhich descriptors identify attestations and their target digests?\nIs the observed record an OCI artifact or the compatibility form?\nWhat separate verification policy determines whether the evidence is trusted?\n\nDSE recommendation: retain evidence without counting it as execution\nDSE 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.\nReview 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.\nMake 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.\nPass 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.\nVerification and evidence\nProposed 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.\nAdd 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.\nOfficial references\n\nImage attestation storage — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: documented behavior\n\nThe [Image attestation storage](https://docs.docker.com/build/metadata/attestations/attestation-storage/) documentation is the primary reference.\n\nThe 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which entries describe runnable image platforms?\n\n- Which descriptors identify attestations and their target digests?\n\n- Is the observed record an OCI artifact or the compatibility form?\n\n- What separate verification policy determines whether the evidence is trusted?\n\n## DSE recommendation: retain evidence without counting it as execution\n\nDSE 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.\n\nReview 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.\n\nMake 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.\n\nPass 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.\n\n## Verification and evidence\n\nProposed 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.\n\nAdd 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.\n\n## Official references\n\n- [Image attestation storage](https://docs.docker.com/build/metadata/attestations/attestation-storage/) — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/keep-docker-attestation-descriptors-out-of-runtime-platform-counts/", "url": "https://update.dsesecurity.com/updates/keep-docker-attestation-descriptors-out-of-runtime-platform-counts/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/keep-docker-attestation-descriptors-out-of-runtime-platform-counts/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Keep Docker attestation descriptors out of runtime-platform counts", "item": "https://update.dsesecurity.com/updates/keep-docker-attestation-descriptors-out-of-runtime-platform-counts/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/keep-docker-attestation-descriptors-out-of-runtime-platform-counts/#article", "identifier": "https://update.dsesecurity.com/updates/keep-docker-attestation-descriptors-out-of-runtime-platform-counts/", "url": "https://update.dsesecurity.com/updates/keep-docker-attestation-descriptors-out-of-runtime-platform-counts/", "headline": "Keep Docker attestation descriptors out of runtime-platform counts", "description": "Docker stores attestations alongside runnable image manifests and marks their platform unknown/unknown.", "abstract": "Docker stores attestations alongside runnable image manifests and marks their platform unknown/unknown. Classify the descriptor and its target before reporting supported execution platforms.", "articleBody": "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.\nSource fact: documented behavior\nThe Image attestation storage documentation is the primary reference.\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich entries describe runnable image platforms?\nWhich descriptors identify attestations and their target digests?\nIs the observed record an OCI artifact or the compatibility form?\nWhat separate verification policy determines whether the evidence is trusted?\n\nDSE recommendation: retain evidence without counting it as execution\nDSE 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.\nReview 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.\nMake 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.\nPass 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.\nVerification and evidence\nProposed 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.\nAdd 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.\nOfficial references\n\nImage attestation storage — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T19:49:16+00:00", "dateModified": "2026-10-29T19:50:09+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/keep-docker-attestation-descriptors-out-of-runtime-platform-counts/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/keep-docker-attestation-descriptors-out-of-runtime-platform-counts/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Keep Docker attestation descriptors out of runtime-platform counts" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 508, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Docker Docs — Image attestation storage", "url": "https://docs.docker.com/build/metadata/attestations/attestation-storage/" } } ] } }