Meeting FedRAMP High Authorization with Container Security
FedRAMP High is the most stringent cloud authorization level for federal systems. It requires compliance with NIST SP 800-53 (421 security controls). CleanStart is designed to satisfy FedRAMP requirements through built-in compliance controls.
FedRAMP High Authorization
What FedRAMP High Requires
FedRAMP High applies to systems categorized with Moderate to High impact. Typical use cases include Defense systems, Financial services, regulated Healthcare systems, and systems handling classified information up to SECRET level.
FedRAMP High requires implementation of 421 NIST 800-53 controls. It also mandates continuous monitoring throughout the authorization period, annual assessments to verify compliance, and documented incident response procedures for handling security events.
CleanStart FedRAMP Mapping
CleanStart satisfies FedRAMP High authorization through six layers of defense controls. Supply Chain Security using SLSA and Provenance mechanisms maps to NIST controls SA-3, SA-4, SA-8, and SA-11, ensuring secure development and acquisition processes. Vulnerability Management through VEX and SBOM documents maps to SI-2, SI-4, SI-5, and CM-3, enabling comprehensive flaw identification and remediation. Cryptography controls including FIPS compliance and TLS encryption map to SC-13, SC-28, and SC-7, protecting information and system boundaries. Container Security based on CIS benchmarks and STIG hardening maps to AC-2, AC-6, AU-2, AU-12, and SI-7, implementing account and system integrity controls. Identity and Access controls through RBAC and comprehensive auditing map to AC-3, AC-4, AC-5, and AU-9, enforcing access policies and accountability. Incident Response capabilities including logs and traces map to IR-4, IR-6, and IR-8, enabling rapid incident detection and response.
Sample NIST 800-53 Mappings
SA-3: System Development Life Cycle
Requirement: Document and manage system development with security controls
CleanStart Satisfaction: CleanStart provides SLSA Level 4 provenance to demonstrate build integrity, In-Toto supply chain links to verify each step of the build process, Git commit signing to ensure source integrity, and comprehensive build automation audit logs documenting every action.
Evidence Provided:
cleanimg-init --compliance fedramp --image myapp:1.0.0 \ --control sa-3 # Output includes:# - SLSA provenance attestation# - Build environment isolation proof# - Signed commits from authorized developers# - Audit trail of all buildsSA-4: Acquisition Process
Requirement: Include security requirements in all acquisitions (software, libraries, dependencies)
CleanStart Satisfaction: CleanStart provides a comprehensive Software Bill of Materials (SBOM) documenting all components, performs license compliance scanning to verify legal usage rights, maintains vulnerability inventories for all dependencies, and verifies components against approved vendor lists.
Evidence Provided:
# Generate software composition evidencecleanimg-init --image myapp:1.0.0 --sbom app.spdx # SBOM includes:# - Every library and version (SA-4 requires this)# - License information# - Vulnerability status (CVE mapping)# - Integrity hashes (component verification)SA-11: Software Assurance
Requirement: Include security testing throughout development
CleanStart Satisfaction: CleanStart implements automated vulnerability scanning throughout the development lifecycle, performs dynamic testing through SBOM analysis, includes malware detection capabilities, and applies code pattern analysis to identify security issues.
SI-2: Flaw Identification and Remediation
Requirement: Identify and fix vulnerabilities
CleanStart Satisfaction: CleanStart performs vulnerability scanning using Grype, documents VEX (Vulnerability Exploitability eXchange) status for all CVEs to indicate whether they are affected or not applicable, tracks remediation timelines for identified vulnerabilities, and maintains risk acceptance documentation for any accepted vulnerabilities.
Evidence Provided:
# Generate vulnerability assessment evidencecleanimg-init --scan --image myapp:1.0.0 --output-vex vex.json # VEX shows for each CVE:# - Status (affected/not_affected/fixed)# - Justification (why not_affected if applicable)# - Remediation timeline (fix by date)# - Risk assessment (confidence level)SC-7: Boundary Protection
Requirement: Monitor and control network boundaries
CleanStart Satisfaction: CleanStart implements network policies within Kubernetes to control inter-pod communication, uses FIPS-compliant TLS encryption for all network traffic, enforces egress rules to prevent unauthorized outbound connections, and integrates with intrusion detection systems for real-time threat monitoring.
SC-13: Cryptographic Protection
Requirement: Use FIPS-validated cryptography
CleanStart Satisfaction: CleanStart uses the OpenSSL FIPS module (CMVP #4949) for cryptographic operations, enforces TLS 1.3 with FIPS-approved ciphers, implements AES-256-GCM encryption for data confidentiality, and maintains RSA-2048 as the minimum key size for asymmetric cryptography.
Evidence Provided:
# FIPS compliance evidencecleanimg-init --fips-verifier --image myapp:1.0.0 # Output shows:# - CMVP module validation certificate# - Approved algorithm usage# - Certificate key sizes and hashing# - Compliance level (Level 2 or 3)AC-2: Account Management
Requirement: Manage user accounts with appropriate controls
CleanStart Satisfaction: CleanStart enforces non-root container users to minimize privilege, separates service accounts by function to limit lateral movement, implements Kubernetes RBAC for fine-grained access control, and maintains comprehensive audit logging of all account actions including authentication and authorization events.
AU-2/AU-12: Audit and Accountability
Requirement: Generate and maintain audit logs
CleanStart Satisfaction: CleanStart maintains comprehensive build audit logs documenting who performed the build, what was built, and when it occurred. Deployment audit logs track all deployment actions, FIPS-Traces logging documents cryptographic operations, and Kubernetes audit logs capture all API requests and cluster events.
Evidence Provided:
# Audit trail generationcleanimg-init --audit-trail --from="2025-09-01" --to="2025-10-04" # Shows all builds, deployments, configuration changes# With timestamps, authors, modifications, outcomesFedRAMP Compliance Report Generation
Generate Compliance Evidence
# Generate FedRAMP compliance reportcleanimg-init --compliance fedramp \ --image myapp:1.0.0 \ --controls-file nist-800-53.json \ --output fedramp-report.json # Report includes:# - Each NIST 800-53 control# - Control status (compliant/non-compliant/partial)# - Evidence references# - Remediation for non-compliant controls# - Risk ratingsReport Structure
{ "compliance_framework": "FedRAMP High", "assessment_date": "2025-10-04T14:30:00Z", "assessed_system": "myapp:1.0.0", "controls": [ { "control_id": "SA-3", "control_name": "System Development Life Cycle", "status": "COMPLIANT", "evidence": [ { "type": "SLSA_PROVENANCE", "reference": "https://attestation.example.com/sha256:abc123", "timestamp": "2025-10-04T14:00:00Z" }, { "type": "BUILD_LOG", "reference": "/var/log/builds/myapp-1.0.0.log", "entries": 245 } ], "confidence": 0.98 }, { "control_id": "SI-2", "control_name": "Flaw Identification and Remediation", "status": "COMPLIANT", "evidence": [ { "type": "VEX", "reference": "sha256:vex-hash", "vulnerabilities_assessed": 247, "affected_count": 0, "remediation_timeline": "30 days" } ] } ], "summary": { "total_controls": 421, "compliant": 410, "partial": 8, "non_compliant": 3, "compliance_percentage": 97.4 }}Assessment Process
FedRAMP Assessment Timeline
The FedRAMP assessment spans four distinct phases over 8 weeks to achieve High authorization. Phase 1: Readiness (Weeks 1-2) involves verification that CleanStart controls are in place, reviewing documentation completeness, and confirming that audit logs are available for assessor review. Phase 2: Testing (Weeks 3-4) involves a third-party assessor reviewing all security controls, verifying SLSA provenance artifacts, testing vulnerability assessment capabilities, and checking encryption configuration compliance against FIPS standards. Phase 3: Assessment (Weeks 5-6) performs a full NIST 800-53 control assessment across all 421 controls, conducts a comprehensive risk assessment for the system, identifies mitigation plans for any non-compliant controls, and generates a preliminary authorization decision. Phase 4: Authorization (Weeks 7-8) conducts a final compliance review, issues the Authority to Operate (ATO), establishes continuous monitoring requirements, and schedules the re-assessment timeline, which is typically annual for ongoing compliance.
This structured 8-week timeline leads to formal FedRAMP High authorization once all phases are successfully completed.
Continuous Monitoring
Ongoing Compliance Verification
# Daily compliance checkcleanimg-init --compliance fedramp \ --image myapp:latest \ --check-daily # Weekly vulnerability assessmentcleanimg-init --scan --image myapp:latest \ --output weekly-vulns.json # Monthly control verificationfor control in SA-3 SI-2 SC-13 AC-2 AU-2; do cleanimg-init --compliance fedramp \ --image myapp:latest \ --control $controldone # Annual full assessment (required by FedRAMP)cleanimg-init --compliance fedramp \ --image myapp:latest \ --full-assessmentMonitoring Metrics
Key metrics are continuously tracked throughout the authorization period. Vulnerability remediation time measures how quickly vulnerabilities are fixed and verified once identified. Build success rate tracks the percentage of builds that complete successfully without errors. Deployment audit log completeness ensures that all deployments are recorded in audit logs for forensic analysis. FIPS algorithm compliance rate should be maintained at 100 percent with no non-compliant algorithms used in any cryptographic operations. Access control violations should remain at zero, indicating proper access control implementation and enforcement. Incident response time measures how quickly security incidents are detected and responded to when they occur.
Common Non-Compliances and Fixes
Issue: No Build Provenance
Control SA-3 and SA-4 require proof of a secure build process. Address this by enabling SLSA Level 4 builds, which automatically generate signed provenance artifacts that document the entire build process from source code to deployed image.
Issue: Unassessed Vulnerabilities
Control SI-2 requires formal assessment of all vulnerabilities. Address this by generating VEX (Vulnerability Exploitability eXchange) documents for all CVEs, providing formal justification for each finding indicating whether the vulnerability is affected, not affected, or has been fixed.
Issue: Non-FIPS Cryptography
Control SC-13 requires FIPS-validated cryptographic algorithms. Address this by verifying FIPS module usage in your images to ensure only FIPS-approved algorithms are used, actively rejecting any non-compliant algorithms that may be introduced.
Issue: Audit Logs Missing
Controls AU-2 and AU-12 require comprehensive audit logging across all systems. Address this by enabling Kubernetes audit logging with a properly configured audit policy file and log destination, and configuring application logging to capture who performed what action, when it happened, and what the result was, with logs sent to centralized systems like ELK or Splunk for aggregation and analysis.
FedRAMP Providers
Systems using CleanStart can be deployed on FedRAMP-authorized cloud platforms including AWS GovCloud (FedRAMP), Microsoft Azure Government (FedRAMP), and Google Cloud FedRAMP services. Before deploying, verify that your chosen cloud provider holds a current FedRAMP authorization at the appropriate impact level for your system.
Helpful Resources
NIST SP 800-53: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf. FedRAMP Docs: https://www.fedramp.gov/. Continuous Monitoring: https://www.fedramp.gov/continuous-monitoring-process/.
See Also
EU CRA Compliance: eu-ai-act-cra.md — International compliance. Reconstructive Compliance: ../supply-chain-provenance/reconstructive-compliance.md — Built-in controls. FIPS Requirements: ../fips/fips-140-overview.md — Cryptography standards.
