Making the Most of Your Docker Hardened Images Enterprise Trial – Part 2

Verifying Security and Compliance of Docker Hardened Images

In Part 1 of this series, we migrated a Node.js service to Docker Hardened Images (DHI) and measured impressive results: 100% vulnerability elimination, 90% package reduction, and 41.5% size decrease. We extracted the SBOM and saw compliance labels for FIPS, STIG, and CIS.

The numbers look compelling. But how do you verify these claims independently?

Security tools earn trust through verification, not promises. When evaluating a security product for production, you need cryptographic proof. This is especially true for images that form the foundation of every container you deploy.This post walks through the verification process: signature validation, provenance analysis, compliance evidence examination, and SBOM analysis. We’ll focus on practical verification you can run during your trial, with links to the official DHI documentation for deeper technical details. By the end, you’ll have independently confirmed DHI’s security posture and built confidence for a production scenario.

Understanding Security Attestations available with Docker Hardened Images

Before diving into verification, you need to understand what you’re verifying.

Docker Hardened Images include attestations: cryptographically-signed metadata about the image’s build process, contents, and compliance posture. These are signed statements that can be independently verified.

List all attestations for your hardened image:

docker scout attestation list registry://<your-org-namespace>/dhi-node:24.11-debian13-fips

This shows 16 different attestation types:

https://slsa.dev/provenance/v0.2            SLSA provenance
https://docker.com/dhi/fips/v0.1            FIPS compliance
https://docker.com/dhi/stig/v0.1            STIG scan
https://cyclonedx.org/bom/v1.6              CycloneDX SBOM
https://spdx.dev/Document                   SPDX SBOM
https://scout.docker.com/vulnerabilities    Scout vulnerabilities
https://scout.docker.com/secrets/v0.1       Scout secret scan
https://scout.docker.com/virus/v0.1         Scout virus/malware
https://scout.docker.com/tests/v0.1         Scout test report
https://openvex.dev/ns/v0.2.0               OpenVEX
...

Each attestation is a JSON document describing a specific aspect of the image. The most critical attestations for verification:

• SLSA provenance: Build source, builder identity, and build process details
• SBOM: Complete software bill of materials
• FIPS compliance: Evidence of FIPS 140-3 certified cryptographic modules
• STIG scan: Security Technical Implementation Guide compliance results
• Vulnerability scan: CVE assessment
• VEX report: CVE exploitability

These attestations follow the in-toto specification, an open framework for supply chain security. Each attestation includes:

• Subject: What the attestation describes (the container image)
• Predicate: The actual claims (FIPS certified, STIG compliant, etc.)
• Signature: Cryptographic signature from the builder

Let’s see how you can verify the signatures yourself.

Verifying Attestations with Docker Scout

The attestations we’re about to examine are cryptographically signed by Docker’s build infrastructure. Docker Scout provides a simple, integrated approach that handles DHI attestations natively and without the hassle of managing public keys or certificate chains.To validate an attestation, simply append the –verify flag, which provides explicit validation feedback. This process relies on cryptographic hashing: the digest is a hash of the attestation content, so even a single character change completely alters the hash. Moreover, the attestation’s signature is cryptographically bound to the specific image digest it describes, guaranteeing that the metadata you’re verifying corresponds exactly to the image you have and preventing substitution attacks.

Retrieving an Attestation

To extract a specific attestation (like SLSA provenance), use the attestation get command with the full predicate type URI:

docker scout attestation get registry://<your-org-namespace>/dhi-node:24.11-debian13-fips \
  --predicate-type https://slsa.dev/provenance/v0.2 \
  --output provenance.json

Success looks like this:

✓ SBOM obtained from attestation, 32 packages found
✓ Provenance obtained from attestation
✓ Report written to provenance.json

The checkmarks confirm Docker Scout successfully retrieved and verified the attestation. Behind the scenes, Scout validated:

• The attestation signature matches Docker’s signing key
• The signature hasn’t expired
• The attestation applies to this specific image digest
• The attestation hasn’t been tampered with

If signature verification fails, Scout returns an error and won’t output the attestation file.To learn more about available predicate types, check out the DHI verification documentation.

Validating SLSA Provenance

Signatures prove attestations are authentic. Provenance shows where the image came from.

SLSA (Supply-chain Levels for Software Artifacts) is a security framework developed by Google, the Linux Foundation, and other industry partners. It defines levels of supply chain security maturity, from SLSA 0 (no guarantees) to SLSA 4 (highest assurance).

Docker Hardened Images target SLSA 3, which requires:

• Build process fully scripted/automated
• All build steps defined in version control
• Provenance generated automatically by build service
• Provenance includes source, builder, and build parameters

Using our previously extracted SLSA provenance.json, we can check the source repository and commit hash:

jq '.predicate.invocation.environment.github_repository' provenance.json

Output:

"docker-hardened-images/definitions"
jq '.predicate.invocation.environment.github_sha1' provenance.json

Output:

"698b367344efb3a7d443508782de331a84216ae4"

Similarly, you can see exactly what GitHub Actions workflow produced this image.

jq '.predicate.builder.id' provenance.json

Output:

“https://github.com/docker-hardened-images/definitions/actions/runs/18930640220/attempts/1”

For DHI Enterprise Users: Verifying High-Assurance Claims

While the free hardened images are built with security best practices, DHI Enterprise images carry the specific certifications required for FedRAMP, HIPAA, and financial audits. Here is how to verify those high-assurance claims.

FIPS 140-3 Validation

FIPS (Federal Information Processing Standard) 140-3 is a U.S. government standard for cryptographic modules. Think of it as a certification that proves the cryptography in your software has been tested and validated by independent labs against federal requirements.

If you’re building software for government agencies, financial institutions, or healthcare providers, FIPS compliance is often mandatory: without it, your software can’t be used in those environments!

Check if the image includes FIPS-certified cryptography:

docker scout attestation get registry://<your-org-namespace>/dhi-node:24.11-debian13-fips \
  --predicate-type https://docker.com/dhi/fips/v0.1 \
  --output fips-attestation.json

Output:

{
  "certification": "CMVP #4985",
  "certificationUrl": "https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4985",
  "name": "OpenSSL FIPS Provider",
  "package": "pkg:dhi/openssl-provider-fips@3.1.2",
  "standard": "FIPS 140-3",
  "status": "active",
  "sunsetDate": "2030-03-10",
  "version": "3.1.2"
}

The certificate number (4985) is the key piece. This references a specific FIPS validation in the official NIST CMVP database.

STIG Compliance

STIG (Security Technical Implementation Guide) is the Department of Defense’s (DoD) checklist for securing systems. It’s a comprehensive security configuration standard needed for deploying software for defense or government work.
DHI images undergo STIG scanning before release. Docker uses a custom STIG based on the DoD’s General Operating System Security Requirements Guide. Each scan checks dozens of security controls and reports findings. You can extract and review STIG scan results:

docker scout attestation get registry://<your-org-namespace>/dhi-node:24.11-debian13-fips \
  --predicate-type https://docker.com/dhi/stig/v0.1 \
  --output stig-attestation.json

Check the STIG scan summary:

jq '.predicate[0].summary' stig-attestation.json

Output:

{
  "failedChecks": 0,
  "passedChecks": 91,
  "notApplicableChecks": 107,
  "totalChecks": 198,
  "defaultScore": 100,
  "flatScore": 91
}

This shows DHI passed all 91 applicable STIG controls with zero failed checks and a 100% score. The 107 “notApplicableChecks” typically refer to controls that are irrelevant to the specific minimal container environment or its configuration. For a complete list of STIG controls and DHI compliance details, including how to extract and view the full STIG scan report, see the DHI STIG documentation.

CIS Benchmark Hardening

CIS (Center for Internet Security) Benchmarks are security configuration standards created by security professionals across industries. Much like STIGs, they represent consensus best practices, but unlike government-mandated frameworks (FIPS, STIG), CIS benchmarks are community-developed.

CIS compliance isn’t legally required, but it demonstrates you’re following industry-standard security practices—valuable for customer trust and audit preparation.

You can verify CIS compliance through image labels:

docker inspect <your-org-namespace>/dhi-node:24.11-debian13-fips | \
  jq '.[0].Config.Labels["com.docker.dhi.compliance"]'

Output: “fips,stig,cis”

The CIS label indicates that an image is hardened according to the CIS Docker Benchmark.

What exactly is a SBOM used for?

Compliance frameworks tell you what standards you meet. The SBOM tells you what’s actually in your container—and that’s where the real security work begins.

Identifying Transitive Dependencies

When you add a package to your project, you see the direct dependency. What you don’t see: that package’s dependencies, and their dependencies, and so on. This is the transitive dependency problem.

A vulnerability in a transitive dependency you’ve never heard of can compromise your entire application. Real example: the Log4Shell vulnerability affected millions of applications because Log4j was a transitive dependency buried several levels deep in dependency chains.

Most vulnerabilities hide in transitive dependencies because:

1. Developers don’t know they exist
2. They’re not updated when the direct dependency updates
3. Scanning tools miss them without an SBOM

Minimal images reduce this risk dramatically. Fewer packages = fewer transitive dependencies = smaller attack surface.

Compare dependency counts:

• Official Node.js image: 321 packages, ~1,500 dependency relationships
• DHI Node.js image: 32 packages, ~150 dependency relationships

90% reduction in packages means 90% reduction in transitive dependency risk.

Scanning for Known (Exploitable) Vulnerabilities

With the SBOM extracted, scan for known vulnerabilities:

docker scout cves registry://<your-org-namespace>/dhi-node:24.11-debian13-fips

Output:

Target: <your-org-namespace>/dhi-node:24.11-debian13-fips

  0C     0H     0M     8L

8 vulnerabilities found in 2 packages
  CRITICAL  0
  HIGH      0
  MEDIUM    0
  LOW       8

Zero critical, high, or medium severity vulnerabilities. Docker Scout cross-references the SBOM against multiple vulnerability databases (NVD, GitHub Security Advisories, etc.).This is the payoff of minimal images: fewer packages means fewer potential vulnerabilities. The official Node.js image had 25 CVEs across CRITICAL, HIGH, and MEDIUM severities. The hardened version has zero actionable vulnerabilities—not because vulnerabilities were patched, but because vulnerable packages were removed entirely.

Understanding Exploitability with VEX

Not all CVEs are relevant to your deployment. A vulnerability in a library function your application never calls, or a flaw in a service that isn’t running, doesn’t pose real risk. Docker Hardened Images include signed VEX attestations that identify which reported CVEs are not actually exploitable in the image’s runtime context. This helps you distinguish between CVEs that exist in a package (reported), and CVEs that can actually be exploited given how the package is used in this specific image (exploitable). In other words, VEX reduces false positives.

You can see which CVEs have been evaluated with this command:

docker scout attestation get registry://<your-org-namespace>/dhi-node:24.11-debian13-fips \
  --predicate-type https://openvex.dev/ns/v0.2.0 \
  --output vex.json

License Compliance Analysis

When you use open source software, you’re bound by license terms. Some licenses (MIT, Apache) are permissive and you can use them freely, even in commercial products. Others (GPL, AGPL) are copyleft: they require you to release your source code if you distribute software using them.

SBOMs make license compliance visible. Without an SBOM, you’re blind to what licenses your containers include.

Export the SBOM in SPDX format:

docker scout sbom registry://<your-org-namespace>/dhi-node:24.11-debian13-fips \
  --format spdx \
  --output node-sbom-spdx.json

Analyze license distribution:

jq '.packages[].licenseConcluded' node-sbom-spdx.json | \
  sort | uniq -c | sort -rn

Output:

15 "MIT"
8 "Apache-2.0"
5 "GPL-2.0-or-later"
2 "BSD-3-Clause"
1 "OpenSSL"
1 "NOASSERTION"

In this example:

• ✅ MIT and Apache-2.0 are permissive (safe for commercial use)
• ⚠️ GPL-2.0-or-later requires review (is this a runtime dependency or build tool?)
• ⚠️ NOASSERTION needs investigation

Conclusion: What You’ve Proven

You’ve independently verified critical security claims Docker makes about Hardened Images:

• Authenticity: Cryptographic signatures prove images are genuine and unmodified
• Provenance: SLSA attestations trace builds to specific source commits in public repositories
  Compliance: FIPS certificate, STIG controls passed, and CIS benchmarks met
• Security posture

Every claim you verified (except CIS) has a corresponding attestation you can check yourself, audit, and validate in your CI/CD pipeline.

You can customize a Docker Hardened Image (DHI) to suit your specific needs using the Docker Hub UI. This allows you to select a base image, add packages, add OCI artifacts (such as custom certificates or additional tools), and configure settings. In addition, the build pipeline ensures that your customized image is built securely and includes attestations.

In Part 3, we’ll cover how to customize Docker Hardened Images to suit your specific needs, while keeping all the benefits we just explored.

You’ve confirmed DHI delivers on security promises. Next, we’ll make it operational.

If you missed reading part 1, where we discussed how you can get to 100% vulnerability elimination and 90% package reduction, read the blog here.