Attestations
Docker Hardened Images (DHIs) include comprehensive, signed security attestations that verify the image's build process, contents, and security posture. These attestations are a core part of secure software supply chain practices and help users validate that an image is trustworthy and policy-compliant.
What is an attestation?
An attestation is a signed statement that provides verifiable information about an image, such as how it was built, what's inside it, and what security checks it has passed. Attestations are typically signed using Sigstore tooling (such as Cosign), making them tamper-evident and cryptographically verifiable.
Attestations follow standardized formats (like in-toto, CycloneDX, and SLSA) and are attached to the image as OCI-compliant metadata. They can be generated automatically during image builds or added manually to document extra tests, scan results, or custom provenance.
Why are attestations important?
Attestations provide critical visibility into the software supply chain by:
- Documenting what went into an image (e.g., SBOMs)
- Verifying how it was built (e.g., build provenance)
- Capturing what security scans it has passed or failed (e.g., CVE reports, secrets scans, test results)
- Helping organizations enforce compliance and security policies
- Supporting runtime trust decisions and CI/CD policy gates
They are essential for meeting industry standards such as SLSA, and help teams reduce the risk of supply chain attacks by making build and security data transparent and verifiable.
How Docker Hardened Images use attestations
All DHIs are built using SLSA Build Level 3 practices, and each image variant is published with a full set of signed attestations. These attestations allow users to:
- Verify that the image was built from trusted sources in a secure environment
- View SBOMs in multiple formats to understand component-level details
- Review scan results to check for vulnerabilities or embedded secrets
- Confirm the build and deployment history of each image
Attestations are automatically published and associated with each mirrored DHI in your Docker Hub organization. They can be inspected using tools like Docker Scout or Cosign, and are consumable by CI/CD tooling or security platforms.
Available attestations
The following attestations are available for each image variant.
| Attestation type | Description | Predicate type URI |
|---|---|---|
| CycloneDX SBOM | A software bill of materials in CycloneDX format, listing components, libraries, and versions. | https://cyclonedx.org/bom/v1.5 |
| SPDX SBOM | An SBOM in SPDX format, widely adopted in open-source ecosystems. | https://spdx.dev/Document |
| Scout SBOM | An SBOM generated and signed by Docker Scout, including additional Docker-specific metadata. | https://scout.docker.com/sbom/v0.1 |
| CVEs (in-toto format) | A list of known vulnerabilities (CVEs) affecting the image's components, based on package and distro scanning. | https://in-toto.io/attestation/vulns/v0.1 |
| CVEs (Scout format) | A vulnerability report generated by Docker Scout, listing known CVEs and severity data. | https://scout.docker.com/vulnerabilities/v0.1 |
| VEX | A Vulnerability Exploitability eXchange (VEX) document that identifies vulnerabilities that do not apply to the image and explains why (e.g., not reachable or not present). | https://openvex.dev/ns/v0.2.0 |
| Secrets Scan | Results of a scan for accidentally included secrets, such as credentials, tokens, or private keys. | https://scout.docker.com/secrets/v0.1 |
| Virus Scan | Results of antivirus scans performed on the image layers. | https://scout.docker.com/virus/v0.1 |
| Tests | A record of automated tests run against the image, such as functional checks or validation scripts. | https://scout.docker.com/tests/v0.1 |
| Scout Health Score | A signed attestation from Docker Scout that summarizes the overall security and quality posture of the image. | https://scout.docker.com/health/v0.1 |
| Build Provenance (Scout) | Provenance metadata generated by Docker Scout, including the source Git commit, build parameters, and environment details. | https://scout.docker.com/provenance/v0.1 |
| SLSA Provenance | A standard SLSA provenance statement describing how the image was built, including build tool, parameters, and source. | https://slsa.dev/provenance/v0.2 |
| SLSA Verification Summary | A summary attestation indicating the image's compliance with SLSA requirements. | https://slsa.dev/verification_summary/v1 |
View and verify attestations
To view and verify attestations for an image, see Verify a Docker Hardened Image.
Add your own attestations
In addition to the comprehensive attestations provided by Docker Hardened Images, you can add your own signed attestations when building derivative images. This is especially useful if you’re building new applications on top of a DHI and want to maintain transparency, traceability, and trust in your software supply chain.
By attaching attestations such as SBOMs, build provenance, or custom metadata, you can meet compliance requirements, pass security audits, and support policy evaluation tools like Docker Scout.
These attestations can then be verified downstream using tools like Cosign or Docker Scout.
To learn how to attach custom attestations during the build process, see Build attestations.