Federal Risk and Authorization Management Program (FedRAMP) compliance costs typically range from $450,000 to over $2 million and take 12 to 18 months to achieve, time your competitors are using to capture government contracts. While you’re spending months configuring FIPS cryptography, hardening security baselines, and navigating 400+ security controls, your competitors are already shipping to federal agencies. Companies that want to sell cloud products and services to the US government must meet the rigorous requirements of FedRAMP, which mandates they implement the expansive security controls described in NIST Special Publication 800-53. As more companies go through this process, they’re looking for ways to accelerate the process (faster time-to-market) and reduce the cost of maintaining FedRAMP compliance.
Shift from months of manual compliance work to automated, auditable security. In May, we announced Docker Hardened Images (DHI) – a curated catalog of minimalist images, kept continuously up to date by Docker to ensure near-zero known CVEs. Today, we are announcing support for FIPS 140-compliant and STIG hardened images – two FedRAMP hurdles that companies have found particularly challenging. Below, we will dive into these new features in more detail and give an overview of all the ways DHI addresses pain points associated with FedRAMP.
FIPS-enabled Docker Hardened Images
FIPS Validated Cryptography Made Simple
FIPS 140 is a US government standard that defines security and testing requirements for cryptographic modules that protect sensitive information. FedRAMP requires that companies use cryptographic modules that have been validated by the NIST Cryptographic Module Validation Program (CMVP).
Although swapping out a cryptographic library for a FIPS-validated one in a base image might seem simple, it can become increasingly difficult as some software must be specifically configured or built from source to use the FIPS-validated module, and even the selection of cryptographic algorithms may need to change. And it’s not just a one-time effort. As you update your software over time, you must be able to prove that your image is still compliant and you haven’t accidentally introduced non-validated cryptographic software.
FIPS-compliant Docker images do all the hard work for you. They are pre-configured to use FIPS-validated software and tested during our secure build process to confirm correct function. But you don’t have to take our word for it. Every FIPS-compliant image comes with signed attestations that list the FIPS-validated software in use, complete with links to its CMVP certification and the test results proving it. We support all major open source cryptographic modules, including OpenSSL, Bouncy Castle, and Go.
{
"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"
}
STIG Hardened Images without the Headache
Security Technical Implementation Guides (STIGs) are the FedRAMP preferred baselines for secure configuration. STIGs are application-specific versions of the more general Security Requirements Guides (SRGs) and are designed to be run programmatically using Security Content Automation Protocol (SCAP) compatible software. Both STIGs and SRGs are published by the US Defense Information Systems Agency (DISA).
Currently, there are no government-published, container-specific STIGs or SRGs. However, per Department of Defence guidance, if there is no related STIG, the most relevant SRG can be used to determine compliance. For containers, that is the General Purpose Operating System (GPOS) SRG. Docker has created a custom STIG that checks for all the container-relevant content from the GPOS SRG. We’re also aligned with industry efforts to create government-published, container-specific STIGs, which we can leverage in the future.
STIG-hardened Docker images are scanned during our secure build process using OpenSCAP and our custom container STIG, and we deliver the results as signed attestations. The STIG compliance score (% of checks passing) is easily visible inside the attestation and from the Docker Hub UI, making it simple to gauge compliance. Not only do we run this scan when we build the initial image, but also anytime we rebuild it using DHI’s new customization features so that you can easily see if you’ve added customizations that would affect your compliance.
STIG-Hardened Docker Images Scoring
In addition to the scan score, we also provide the full HTML and Extensible Configuration Checklist Description Format (XCCDF) output of OpenSCAP so that you can inspect the results yourself.
The HTML output is convenient for taking a quick look, while XCCDF is great for loading into the SCAP-compliant tool of your (or your auditor’s) choice for rich visualization. For example, Heimdall will helpfully map the checks to the underlying NIST 800-53 controls for you. For those wanting to manually map our checks back to the GPOS SRG, we’ve used consistent numbering of check IDs between the two for easy cross-referencing.
{
"name": "Docker Hardened Image - Debian 12 GPOS STIG Profile",
"output": [
{
"content": "...",
"format": "html",
"mediaType": "text/html"
},
{
"content": "...",
"format": "xccdf",
"mediaType": "application/xml"
}
],
"profile": "xccdf_dhi-debian_profile_.check",
"publisher": "Docker, Inc.",
"result": "passed",
"status": "active",
"summary": {
"defaultScore": 100,
"failedChecks": 0,
"maxDefaultScore": 100,
"notApplicableChecks": 107,
"passedChecks": 91,
"totalChecks": 198
},
"tool": "openscap",
"type": "Vendor published STIG-ready content, SRG aligned",
"version": "0.1"
}
Continuous Compliance at Scale
Vulnerability Reduction
Docker Hardened Images start with a dramatically reduced attack surface, up to 95% smaller by package count, to limit exposure from the outset, and are kept continuously up to date to ensure near-zero known CVEs. Images are also scanned for viruses and secrets with corresponding attestations that can serve as evidence during audits.
Vulnerability Detection & Remediation
FedRAMP requires that companies monitor and scan for vulnerabilities and remediate them within a defined timeframe (30/90/180 days for high/moderate/low risk). Docker continually monitors various CVE sources to detect applicable vulnerabilities in our hardened images. CVE counts are reported in the Docker Hub UI and as attestations and Docker Scout can be configured to notify you of new vulnerabilities affecting previously pulled images. DHI has a remediation SLA of 7 days for critical/high vulnerabilities and 30 days for medium/low ones (from availability of an upstream fix), ensuring that you can comfortably meet the FedRAMP remediation timelines.
Docker also provides Vulnerability Exploitability eXchange (VEX) attestations that identify vulnerabilities that do not apply to the image (and explains why) so that scanners that support the VEX standard can automatically filter these results, allowing you to look past the noise and focus on exploitability.
Integrity and Supply Chain Transparency
Doctor Hardened Images are built using an SLSA Build Level 3 secure build pipeline that ensures verifiability and prevents tampering during and after the build. Build provenance is provided via signed attestations, and Software Bills of Materials (SBOMs) are generated in multiple popular formats to help satisfy FedRAMP’s asset management and software inventory reporting requirements.
Audit Evidence
You’ve heard attestations mentioned multiple times in this post. There’s a good reason for that. Evidence is everything when demonstrating compliance with FedRAMP or other regulatory frameworks. DHI attestations serve as secure evidence of all aspects of DHI security, from provenance to asset management to vulnerability and other security scanning to FIPS compliance. Attestations follow the in-toto attestation standard, a project of the Cloud Native Computing Foundation (CNCF), ensuring compatibility across a wide range of software vendors.
Government Grade Security for Every Environment
While there are definitely parts of the FedRAMP process specific to the federal government, the NIST 800-53 controls on which it is based are intended to be common-sense security best practices. So whether or not your company is currently subject to FedRAMP, aligning your security practices with the underlying controls makes good sense. We see this with initiatives like GovRAMP that define FedRAMP-aligned security controls for companies selling to state and local governments.
Ready to accelerate your FedRAMP journey?
Docker Hardened Images are designed both to help you ship software with confidence and to make FedRAMP compliance easier and less costly. Let Developers stay focused on building while giving Compliance teams and Auditors the evidence they need.
We’re here to help. Get in touch with us and let’s harden your software supply chain, together.