# Review provenance detail before sharing a Docker build attestation > Inspect the documented min and max provenance content before distributing build-input metadata or an embedded Dockerfile. - Canonical URL: https://update.dsesecurity.com/updates/review-provenance-detail-before-sharing-a-docker-build-attestation/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-30T06:04:22+00:00 - Modified: 2026-10-30T06:05:14+00:00 - Last reviewed by DSE: 2026-10-30 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Inspect the documented min and max provenance content before distributing build-input metadata or an embedded Dockerfile. ## Potentially affected BuildKit provenance attestations generated through Docker Buildx. ## DSE recommendation Choose and inspect the provenance detail level against the release’s information-sharing requirement. ## Article Bottom line: Review the actual provenance content before sharing an image attestation. Choose the detail level deliberately and keep approval of disclosed build information separate from verification of the attestation’s trust. ## Source fact: documented behavior The [Provenance attestations](https://docs.docker.com/build/metadata/attestations/slsa-provenance/) documentation is the primary reference. Docker documents mode=min as the default provenance detail level, including items such as build materials, source repository and revision, and build platform. The documented min mode omits build-argument values, secret identities and rich layer metadata. Max mode adds the build’s LLB definition, Dockerfile information including the complete base64-encoded file, and source maps; it also exposes build-argument values. The inspection workflow exposes provenance through .Provenance using docker buildx imagetools inspect and its --format option. ## What the source does not establish This article reviews disclosure in the documented provenance modes. It does not establish authenticity, approve sensitive build arguments or guarantee that an arbitrary build artifact contains no confidential data. Keep signature and release-policy verification separate from deciding which provenance information may be shared. ## Applicability questions - Who is allowed to receive the attestation and its build information? - Which documented detail mode is actually selected by the build? - Do argument values, Dockerfile contents or source details require restricted handling? - What separate verification policy will evaluate the resulting attestation? ## DSE recommendation: inspect the disclosure before release DSE recommends a sharing review that names the recipient group, selected provenance mode and permitted build-information categories. Have the build and information owners agree what may leave the build environment before changing the output configuration. Do not choose a mode solely from a desire for either the smallest or most detailed record. Inventory nonsecret build arguments and Dockerfile content as part of that review. Route a discovered credential or sensitive value to the established secret-handling process rather than relying on a lower-detail mode as its only remedy. Keep the provenance decision alongside the actual image digest and build invocation. Inspect a harmless representative result through the documented tooling. Preserve the selected mode and a restricted copy of the actual attestation for authorized review. Compare observed fields with the approved sharing categories, marking unexpected information explicitly. Decode or display embedded content only within the permitted handling environment. Record the disclosure decision separately from artifact trust. Pass the accepted evidence to the release’s verification procedure when provenance authenticity or policy is required. Have the responsible owner resolve missing or additional fields without treating a readable JSON record as proof of the build’s correctness or permission to run the image. ## Verification and evidence Proposed verification, not performed: prepare a harmless test build containing a recognizable nonsecret argument and a simple reviewed Dockerfile. Generate separately identified min and max attestations through the documented Buildx workflow. Predict which of those benign inputs should be observable before inspecting either result. Use the documented provenance inspection path and compare actual fields with that prediction and the sharing rule. Retain image digests, invocation, selected modes, sanitized observations and the information owner’s decision. Keep any secret-value exercise out of the fixture. Report the observed disclosure difference only; authenticity, functional release tests and exhaustive confidentiality analysis remain independent acceptance work. ## Official references - [Provenance attestations](https://docs.docker.com/build/metadata/attestations/slsa-provenance/) — Docker Docs. Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Docker Docs — Provenance attestations - Authority: docs.docker.com - URL: https://docs.docker.com/build/metadata/attestations/slsa-provenance/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Review provenance detail before sharing a Docker build attestation,” DSE Security, https://update.dsesecurity.com/updates/review-provenance-detail-before-sharing-a-docker-build-attestation/ 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.