FedRAMP compliance documentation is written for security officers and compliance teams. It references control families, implementation statements, and evidence packages. DevOps engineers building and deploying containers at FedRAMP cloud service providers need to understand what these requirements mean in terms of actual pipeline changes — not compliance language.
The gap between “our company has a FedRAMP ATO” and “our build pipeline implements what the ATO requires” is where many container security programs fail. The compliance team documented the controls; the engineering team was not told what to build.
This guide translates the FedRAMP container scanning requirements that matter most into specific pipeline actions.
The Core Requirement: Scan Before Deployment
The most foundational FedRAMP requirement for container security (RA-5): every container image that runs in the FedRAMP boundary must be scanned for vulnerabilities before it is deployed.
“Before deployment” means in the CI/CD pipeline, not as a separate periodic process. An image that was scanned in the pipeline three weeks ago and then deployed today does not satisfy the “before deployment” interpretation of most FedRAMP ATOs.
The pipeline implementation:
# GitHub Actions: FedRAMP-compliant container build
name: Container Build (FedRAMP)
jobs:
build-and-deploy:
steps:
– name: Build image
run: docker build -t $IMAGE_NAME:$SHA .
– name: Scan image
run: |
trivy image \
–exit-code 1 \
–severity CRITICAL \
–format json \
–output scan-results.json \
$IMAGE_NAME:$SHA
– name: Archive scan results
uses: actions/upload-artifact@v3
with:
name: scan-results-${{ github.sha }}
path: scan-results.json
retention-days: 365 # FedRAMP retention requirement
– name: Deploy (only if scan passed)
if: success()
run: deploy $IMAGE_NAME:$SHA
The scan runs as part of the pipeline. The results are archived with 365-day retention. The deployment only proceeds if the scan passes. This is the pattern that satisfies “scan before deployment.”
The Evidence Retention Requirement
FedRAMP requires that vulnerability scan evidence be retained and available to the authorizing agency during continuous monitoring reviews. For pipeline-based scanning, this means:
- Scan results must be stored in a queryable, durable location (not just CI job logs that expire after 30 days)
- Results must include enough metadata to answer: when was this image scanned, with which tool, against which CVE database, with what result?
- Results must be linkable to specific deployments: when this image was deployed, what was its scan status?
The implementation pattern: export scan results in a structured format (JSON, SARIF) and push them to a dedicated evidence store (S3 bucket, artifact registry, security SIEM) alongside the image deployment record.
# After each scan, push results to evidence store
aws s3 cp scan-results.json \
s3://fedramp-evidence/container-scans/$(date +%Y/%m)/$IMAGE_DIGEST-scan.json \
–metadata “image=$IMAGE_NAME,sha=$SHA,date=$(date -u +%Y-%m-%dT%H:%M:%SZ)”
The metadata attached to the stored result enables later querying: “show me all scans for images deployed to production in March.”
The Remediation Timeline Requirement
FedRAMP container scanning requirements include not just scanning but remediation on defined timelines. For FedRAMP Moderate, standard timelines are:
- Critical CVEs: 30 days to resolve (some agency ATOs require 7 days)
- High CVEs: 60-90 days
- Medium CVEs: 180 days
“Resolve” means patched, removed, or formally accepted as risk with documented rationale. A CVE that sits open past its timeline creates a POA&M (Plan of Action and Milestones) entry, which is visible to the authorizing agency.
For DevOps teams, meeting these timelines requires automated tracking:
# Simplified remediation tracking query
def check_open_critical_cves(scan_records, remediation_records):
for finding in scan_records.critical_findings():
discovery_date = finding.first_seen
age_days = (today – discovery_date).days
if age_days > 30 and finding.id not in remediation_records:
alert_security_team(finding, age_days)
Automated alerts when CVEs approach their remediation deadline prevent surprise POA&M entries during monthly ConMon reporting.
Frequently Asked Questions
What is FedRAMP in DevOps?
FedRAMP (Federal Risk and Authorization Management Program) is the US government framework that authorizes cloud service providers to handle federal data. For DevOps teams at FedRAMP CSPs, it means specific security controls must be implemented directly in the CI/CD pipeline — including container scanning before every deployment, structured evidence retention, and CVE remediation on defined timelines. FedRAMP compliance is not a separate workstream; it is an engineering requirement embedded in normal build and deploy operations.
What is container vulnerability scanning?
Container vulnerability scanning is the automated analysis of a container image’s packages, libraries, and binaries against known CVE databases to identify security weaknesses before deployment. FedRAMP container scanning requires that this scan occur in the CI/CD pipeline before any image is deployed to the authorization boundary, with results archived in a durable evidence store for at least 365 days. The scan must produce structured output — JSON or SARIF — that links each finding to the specific image digest and deployment record.
How often should vulnerability scans be performed?
FedRAMP requires that container images be scanned before every deployment as the baseline requirement under RA-5. Beyond per-build scanning, production images that have not been rebuilt must also be scanned on a scheduled basis — typically weekly — to detect newly disclosed CVEs against images already running in the environment. FedRAMP High baseline imposes near-continuous scanning requirements, while Moderate requires at minimum monthly scheduled scans of production systems.
Is Azure DevOps FedRAMP compliant?
Azure DevOps has a FedRAMP authorization, meaning Microsoft’s platform itself meets the authorization requirements. However, a CSP using Azure DevOps as their pipeline infrastructure still bears full responsibility for implementing FedRAMP-required security controls within their workflows — including container scanning gates, evidence archiving, and remediation tracking. The platform’s authorization does not substitute for the CSP’s own control implementations inside the pipeline.
How Hardening Simplifies FedRAMP Compliance?
Container image security programs that include automated hardening reduce the compliance burden on DevOps teams in concrete ways:
Fewer open findings: A hardened image with 5 Critical CVEs requires tracking and documentation for 5 findings. An unminimized image with 50 requires tracking for 50. The per-finding compliance overhead is the same; the count multiplier is dramatically different.
Consistent pipeline gate passes: Images that fail the Critical CVE threshold gate block deployments and require manual intervention. Hardened images typically pass the threshold gate consistently, removing the exception handling overhead from DevOps workflows.
Simpler ConMon reporting: Monthly reports that show a fleet of hardened images with low CVE counts require less risk acceptance documentation and fewer explanatory notes than reports showing high CVE counts with bulk risk acceptance justifications.
The DevOps team’s relationship to FedRAMP compliance is most sustainable when the security controls are automated into the pipeline and produce clean, consistent outputs. Compliance becomes a byproduct of normal operations rather than a separate workstream.