Infrastructure-as-Code changes that violate NIST 800-53 controls are significantly more expensive to fix post-deployment than pre-deployment. A Terraform change that disables S3 bucket encryption or creates a public security group reaches production in seconds. Remediating it after the fact requires change control board approval, an updated SSP, and potentially a POAM entry — all avoidable if the violation was caught before the terraform apply.
Rutagon's approach to government infrastructure compliance embeds scanning directly into the Terraform planning pipeline. Violations block the plan. Nothing compliant gets delayed. Everything non-compliant gets a clear error with the specific control it violates.
The Scanning Stack
Three tools compose the compliance scanning pipeline:
Checkov — a static analysis tool from Bridgecrew that evaluates Terraform plan output against 1,000+ built-in checks covering AWS, GCP, and Azure. Checkov includes out-of-box checks for CIS Benchmarks, NIST 800-53, HIPAA, SOC2, and PCI-DSS. For government infrastructure, the NIST 800-53 check pack is the primary ruleset.
OPA Conftest — Open Policy Agent's Conftest tool evaluates structured data (Terraform plan JSON output) against Rego policies. Where Checkov provides breadth, OPA provides depth — custom policies can encode agency-specific rules, environment-specific constraints, or control implementations that Checkov's generic checks cannot capture.
AWS Config — runtime compliance evaluation after deployment. Where Checkov and OPA catch violations pre-deploy, Config evaluates resources that have already been deployed and detects drift from compliant state. Config rules serve as the continuous monitoring backstop for anything that slips through or changes post-deploy.
Integrating Checkov into the Terraform Pipeline
Checkov runs against the Terraform plan file in the CI pipeline. The plan file is in JSON format — Checkov parses it and evaluates every resource against applicable check policies.
# GitHub Actions: Terraform compliance pipeline
- name: Terraform Init
run: terraform init
- name: Terraform Plan
run: terraform plan -out=tfplan
env:
TF_VAR_environment: ${{ vars.ENVIRONMENT }}
- name: Export Plan JSON
run: terraform show -json tfplan > tfplan.json
- name: Checkov Scan
uses: bridgecrewio/checkov-action@v12
with:
file: tfplan.json
framework: terraform_plan
check: CKV_AWS_* # AWS resource checks
quiet: false
soft_fail: false # Fail the pipeline on violations
output_format: cli,junitxml
output_file_path: checkov-results.xml
# Custom NIST 800-53 policies
external_checks_dir: ./compliance/checkov-custom
- name: Upload Results
uses: actions/upload-artifact@v3
with:
name: checkov-results
path: checkov-results.xmlThe soft_fail: false setting is critical — it converts any Checkov finding from a warning into a pipeline failure. In a government pipeline, compliance violations are blocking conditions, not advisory notes.
Custom Policies for Government-Specific Controls
Checkov's built-in checks cover a broad set of common misconfigurations. Government infrastructure requires additional custom checks for agency-specific control implementations:
# Custom Checkov check: Enforce GovCloud region only
from checkov.common.models.enums import CheckResult, CheckCategories
from checkov.terraform.checks.resource.base_resource_check import BaseResourceCheck
class GovCloudRegionCheck(BaseResourceCheck):
def __init__(self):
name = "Ensure all resources deploy to GovCloud regions only"
id = "CKV_CUSTOM_GOV_001"
supported_resources = ['aws_instance', 'aws_s3_bucket', 'aws_eks_cluster']
categories = [CheckCategories.GENERAL_SECURITY]
super().__init__(name=name, id=id, categories=categories,
supported_resources=supported_resources)
def scan_resource_conf(self, conf):
provider_region = conf.get("region", [""])[0]
if provider_region.startswith("us-gov-"):
return CheckResult.PASSED
return CheckResult.FAILEDGovernment-specific custom checks Rutagon deploys on program pipelines:
- Mandatory tag enforcement (cost center, classification, environment, POAM ID)
- GovCloud region enforcement (no commercial region deployments)
- KMS CMK requirement (AWS-managed keys not permitted for classified data)
- VPC flow logs enabled on all VPCs
- No public S3 bucket ACLs or bucket policies
- CloudTrail enabled in all accounts
- GuardDuty enabled in all regions
OPA Conftest for Complex Policy Logic
Some compliance requirements involve relationships between resources that Checkov single-resource checks cannot evaluate. OPA Conftest handles these through Rego policies that can query across the full Terraform plan.
# OPA policy: Ensure all S3 buckets use CMK encryption (not SSE-S3)
package terraform.aws.s3
import future.keywords.in
deny[msg] {
resource := input.resource_changes[_]
resource.type == "aws_s3_bucket_server_side_encryption_configuration"
rule := resource.change.after.rule[_]
apply := rule.apply_server_side_encryption_by_default[_]
apply.sse_algorithm != "aws:kms"
msg := sprintf(
"S3 bucket encryption must use KMS (aws:kms), not AES256. Resource: %s",
[resource.address]
)
}
deny[msg] {
resource := input.resource_changes[_]
resource.type == "aws_s3_bucket_server_side_encryption_configuration"
rule := resource.change.after.rule[_]
apply := rule.apply_server_side_encryption_by_default[_]
apply.sse_algorithm == "aws:kms"
not apply.kms_master_key_id
msg := sprintf(
"S3 KMS encryption must use a customer-managed key (CMK), not AWS-managed key. Resource: %s",
[resource.address]
)
}Running OPA Conftest in the pipeline:
# Convert Terraform plan to JSON and run OPA policies
terraform show -json tfplan > tfplan.json
conftest test tfplan.json \
--policy ./compliance/opa-policies/ \
--output json \
--all-namespacesContinuous Runtime Compliance with AWS Config
Pre-deploy scanning catches violations before they reach production. AWS Config catches anything that slips through and detects post-deployment configuration drift.
Config rules relevant to NIST 800-53 government environments:
encrypted-volumes— EBS volumes must be encrypteds3-bucket-server-side-encryption-enabled— S3 buckets must have SSE enabledvpc-flow-logs-enabled— VPC flow logging must be activecloudtrail-enabled— CloudTrail must be active in all regionscloud-trail-encryption-enabled— CloudTrail log encryption with KMSguardduty-enabled-centralized— GuardDuty must be active
Config findings feed Security Hub, which aggregates them with GuardDuty and Inspector findings for the ISSO's continuous monitoring dashboard. For the full continuous monitoring architecture, see Automated Compliance Reporting for Gov Systems.
For the Kubernetes STIG compliance equivalent, see STIG Compliance Automation in Kubernetes.
Working With Rutagon
Rutagon implements pre-deploy compliance scanning pipelines for federal infrastructure teams — Checkov, OPA, and custom NIST 800-53 policies that catch violations before they become POAM entries.
Frequently Asked Questions
What is infrastructure compliance scanning for Terraform?
Infrastructure compliance scanning evaluates Terraform configuration and plan files against security and compliance policies before any infrastructure is deployed. Tools like Checkov and OPA Conftest parse the Terraform plan JSON and check every resource against applicable rules — NIST 800-53 controls, CIS Benchmarks, agency-specific requirements. Violations block the pipeline before terraform apply, preventing non-compliant resources from ever reaching the production environment.
What is Checkov and how does it work with Terraform?
Checkov is an open-source static analysis tool from Bridgecrew (now part of Palo Alto Networks) that evaluates IaC files and Terraform plan output against 1,000+ built-in security and compliance checks. It parses the Terraform plan JSON and evaluates each resource against applicable checks. Checkov includes built-in check packs for NIST 800-53, CIS Benchmarks, HIPAA, and other frameworks, and supports custom checks written in Python or YAML for organization-specific requirements.
What is OPA Conftest and when should I use it over Checkov?
OPA (Open Policy Agent) Conftest evaluates structured data (including Terraform plan JSON) against Rego policies. Use OPA when you need policies that evaluate relationships between multiple resources — for example, verifying that every S3 bucket uses a CMK (not just any KMS key), or that all VPCs in a production account have flow logs enabled. Checkov excels at single-resource compliance checks; OPA handles cross-resource relationships and complex conditional logic that Checkov's check model cannot express.
How do pre-deploy compliance gates affect deployment speed?
Checkov and OPA scans on a typical government Terraform plan complete in under 60 seconds, adding minimal time to the overall pipeline. The business case is straightforward: a 60-second scan that catches a compliance violation pre-deploy saves hours or days of remediation work (change control, SSP update, POAM documentation) compared to catching it post-deploy. Pipeline performance impact is negligible relative to the compliance risk reduction.
What NIST 800-53 controls does infrastructure scanning address?
Infrastructure compliance scanning primarily addresses the Configuration Management (CM) and System and Communications Protection (SC) control families. CM-2 (baseline configuration), CM-6 (configuration settings), CM-7 (least functionality), SC-8 (transmission confidentiality), SC-28 (protection of information at rest). Pre-deploy scanning provides continuous evidence that configurations meet control requirements before each deployment, directly supporting the ATO evidence package and continuous monitoring requirements.