centersl/docker-docs
1
0
Fork 0
mirror of https://github.com/docker/docs.git synced 2026-04-12 06:19:22 +07:00
Code Issues Packages Projects Releases Wiki Activity

dhi: add stig (#23114)

Browse Source 
<!--Delete sections as needed -->

## Description

Added STIG feature for DHI.
Cleaned up the attestations table to match UI wording better.

-
https://deploy-preview-23114--docsdocker.netlify.app/dhi/core-concepts/attestations/#available-attestations
-
https://deploy-preview-23114--docsdocker.netlify.app/dhi/core-concepts/stig/

## Related issues or tickets

ENGDOCS-2861

## Reviews

<!-- Notes for reviewers here -->
<!-- List applicable reviews (optionally @tag reviewers) -->

- [ ] Editorial review
- [ ] Product review

---------

Signed-off-by: Craig <craig.osterhout@docker.com>
This commit is contained in:
Craig Osterhout
2025-07-23 14:27:48 -07:00
committed by GitHub
parent 09f5d97528
commit 8ea648e314
4 changed files with 143 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
content/manuals/dhi/core-concepts/_index.md
View File

@@ -24,6 +24,10 @@ params:
description: Learn how Docker Hardened Images support FIPS 140 by using validated cryptographic modules and providing signed attestations for compliance audits.
icon: verified
link: /dhi/core-concepts/fips/
- title: STIG
description: Learn how Docker Hardened Images provide STIG-hardened container images with verifiable security scan attestations for government and enterprise compliance requirements.
icon: policy
link: /dhi/core-concepts/stig/
grid_concepts_risk:
- title: Common Vulnerabilities and Exposures (CVEs)

26
content/manuals/dhi/core-concepts/attestations.md
View File

@@ -58,23 +58,27 @@ tooling or security platforms.
## Available attestations
The following attestations are available for each image variant.
While every DHI variant includes a set of attestations, the attestations may
vary based on the image variant. For example, some images may include a STIG
scan attestation. The following table is a comprehensive list of all
attestations that may be included with a DHI:
| Attestation type | Description | Predicate type URI |
|----------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------|
| CycloneDX SBOM | A software bill of materials in [CycloneDX](https://cyclonedx.org/) format, listing components, libraries, and versions. | `https://cyclonedx.org/bom/v1.5` |
| SPDX SBOM | An SBOM in [SPDX](https://spdx.dev/) 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` |
| STIG scan | Results of a STIG scan, with output in HTML and XCCDF formats. | `https://docker.com/dhi/stig/v0.1` |
| CVEs (In-Toto format) | A list of known vulnerabilities (CVEs) affecting the image's components, based on package and distrobution scanning. | `https://in-toto.io/attestation/vulns/v0.1` |
| VEX | A [Vulnerability Exploitability eXchange (VEX)](https://openvex.dev/) 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` |
| 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` |
| Scout provenance | Provenance metadata generated by Docker Scout, including the source Git commit, build parameters, and environment details. | `https://scout.docker.com/provenance/v0.1` |
| Scout SBOM | An SBOM generated and signed by Docker Scout, including additional Docker-specific metadata. | `https://scout.docker.com/sbom/v0.1` |
| Secrets scan | Results of a scan for accidentally included secrets, such as credentials, tokens, or private keys. | `https://scout.docker.com/secrets/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](https://slsa.dev/) 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` |
| Virus scan | Results of antivirus scans performed on the image layers. | `https://scout.docker.com/virus/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` |
| SLSA provenance | A standard [SLSA](https://slsa.dev/) 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` |
| SPDX SBOM | An SBOM in [SPDX](https://spdx.dev/) format, widely adopted in open-source ecosystems. | `https://spdx.dev/Document` |
## View and verify attestations

123
content/manuals/dhi/core-concepts/stig.md Normal file
View File

@@ -0,0 +1,123 @@
---
title: STIG
description: Learn how Docker Hardened Images provide STIG-hardened container images with verifiable security scan attestations for government and enterprise compliance requirements.
keywords: docker stig, stig-hardened images, stig guidance, openscap docker, secure container images
---
## What is STIG?
[Security Technical Implementation Guides
(STIGs)](https://public.cyber.mil/stigs/) are configuration standards published
by the U.S. Defense Information Systems Agency (DISA). They define security
requirements for operating systems, applications, databases, and other
technologies used in U.S. Department of Defense (DoD) environments.
STIGs help ensure that systems are configured securely and consistently to
reduce vulnerabilities. They are often based on broader requirements like the
DoD's General Purpose Operating System Security Requirements Guide (GPOS SRG).
## Why STIG guidance matters
Following STIG guidance is critical for organizations that work with or support
U.S. government systems. It demonstrates alignment with DoD security standards
and helps:
- Accelerate Authority to Operate (ATO) processes for DoD systems
- Reduce the risk of misconfiguration and exploitable weaknesses
- Simplify audits and reporting through standardized baselines
Even outside of federal environments, STIGs are used by security-conscious
organizations as a benchmark for hardened system configurations.
STIGs are derived from broader NIST guidance, particularly [NIST Special
Publication 800-53](https://csrc.nist.gov/publications/sp800), which defines a
catalog of security and privacy controls for federal systems. Organizations
pursuing compliance with 800-53 or related frameworks (such as FedRAMP) can use
STIGs as implementation guides that help meet applicable control requirements.
## How Docker Hardened Images help apply STIG guidance
Docker Hardened Images (DHIs) include STIG variants that are scanned against
custom STIG-based profiles and include signed STIG scan attestations. These
attestations can support audits and compliance reporting.
Docker creates custom STIG-based profiles for images based on the GPOS SRG and
DoD Container Hardening Process Guide. Because DISA has not published a STIG
specifically for containers, these profiles help apply STIG-like guidance to
container environments in a consistent, reviewable way and are designed to
reduce false positives common in container images.
## Identify images that include STIG scan results
Docker Hardened Images that include STIG scan results are labeled as **STIG** in
the Docker Hardened Images catalog.
To find DHI repositories with STIG image variants, [explore
images](../how-to/explore.md) and:
- Use the **STIG** filter on the catalog page
- Look for **STIG** labels on individual image listings
To find a STIG image variant within a repository, go to the **Tags** tab in the
repository, and find images labeled with **STIG** in the **Compliance** column.
## View and verify STIG scan results
Docker provides a signed [STIG scan
attestation](../core-concepts/attestations.md) for each STIG-hardened image.
These attestations include:
- A summary of the scan results, including the number of passed, failed, and not
applicable checks
- The name and version of the STIG profile used
- Full output in both HTML and XCCDF (XML) formats
### View STIG scan attestations
You can retrieve and inspect a STIG scan attestation using the Docker Scout CLI:
```console
$ docker scout attest get \
--predicate-type https://docker.com/dhi/stig/v0.1 \
--verify \
--predicate \
<your-namespace>/dhi-<image>:<tag>
```
### Extract HTML report
To extract and view the human-readable HTML report:
```console
$ docker scout attest get <your-namespace>/dhi-<image>:<tag> \
--predicate-type https://docker.com/dhi/stig/v0.1 \
--verify \
--predicate \
| jq -r '.[0].output[] | select(.format == "html").content | @base64d' > stig_report.html
```
### Extract XCCDF report
To extract the XML (XCCDF) report for integration with other tools:
```console
$ docker scout attest get <your-namespace>/dhi-<image>:<tag> \
--predicate-type https://docker.com/dhi/stig/v0.1 \
--verify \
--predicate \
| jq -r '.[0].output[] | select(.format == "xccdf").content | @base64d' > stig_report.xml
```
### View STIG scan summary
To view just the scan summary without the full reports:
```console
$ docker scout attest get <your-namespace>/dhi-<image>:<tag> \
--predicate-type https://docker.com/dhi/stig/v0.1 \
--verify \
--predicate \
| jq -r '.[0] | del(.output)'
```

2
content/manuals/dhi/how-to/explore.md
View File

@@ -74,7 +74,7 @@ To explore image variants:
The **Tags** page provides the following information:
- Tags: A list of all available tags, also known as image variants.
- Compliance: Lists relevant compliance designations. For example, `FIPS`.
- Compliance: Lists relevant compliance designations. For example, `FIPS` or `STIG`.
- Distribution: The distribution that the variant is based on. For example, `debian 12` or `alpine 3.21`.
- Package manager: The package manager that is available in the variant. For example, `apt`, `apk`, or `-` (no package manager).
- Shell: The shell that is available in the variant. For example, `bash`, `busybox`, or `-` (no shell).