Federal infrastructure teams have spent the last several years moving toward infrastructure-as-code as the standard method for provisioning cloud resources, platform components, and network configurations. The operational case is straightforward: version-controlled templates reduce configuration drift, accelerate deployment cycles, and create a documented record of infrastructure intent. What those same teams frequently discover after the fact is that the pipeline itself becomes a control gap. Code gets merged, plans get applied, and resources get deployed before anyone with a security or compliance function has had a meaningful opportunity to evaluate whether the resulting infrastructure meets the control requirements attached to the system authorization.
Continuous controls monitoring for infrastructure as code addresses that gap directly. Rather than relying on post-deployment scanning or periodic assessments to surface policy violations, IaC-specific CCM embeds control evaluation into the pipeline at the stages where changes can still be blocked, modified, or escalated before they reach a production environment. The distinction matters operationally. A finding that surfaces in a post-deployment posture scan requires remediation, change management, and potentially a new authorization review. A finding that surfaces at pull request or plan stage is a development workflow event that can be resolved in hours without touching a running system.
The challenge in federal environments is that the tooling, the RMF documentation, and the operational workflows rarely arrive pre-integrated. Policy-as-code engines need to be configured with rules that trace back to specific NIST SP 800-53 controls. Pipeline stages need approval gates that satisfy separation-of-duties requirements. Evidence generated by automated checks needs to be formatted and retained in a way that an assessor or ISSO can actually use during a control review. None of that happens by default when an agency adopts Terraform or CloudFormation and connects it to a CI/CD platform.
This article covers how to design a CCM architecture that works inside IaC pipelines, from policy rule design and evaluation stage placement through exception handling, evidence retention, and mapping pipeline telemetry to ATO artifacts. The focus is on the pre-deployment control lifecycle, where enforcement decisions are still reversible and where the operational cost of catching a violation is lowest.
Key Takeaways
- Policy-as-code rules must trace directly to specific NIST SP 800-53 controls to produce evidence that assessors can use during RMF reviews, not just pipeline pass/fail logs.
- Control evaluation should occur at multiple pipeline stages: pull request, merge, plan, and pre-deployment. Each stage serves a different enforcement purpose and catches different violation types.
- Exception and waiver workflows need formal approval paths and time-bounded records, or they become permanent undocumented deviations that accumulate as technical debt.
- False-positive management is an ongoing operational function, not a one-time tuning task. Unaddressed false positives erode developer trust and cause teams to bypass or suppress policy gates.
- Separation of duties between code authors, policy approvers, and deployment authorizers must be enforced at the pipeline level, not just documented in policy.
- Evidence packages generated by IaC pipeline checks can directly support CA-7, CM-3, CM-6, and SA-10 control families when structured and retained correctly from the start.
Table of Contents
Policy-as-Code Engines and Rule Design for Federal Control Requirements
Policy-as-code engines evaluate infrastructure templates against a defined rule set and return pass, fail, or warning results before any resources are provisioned. The evaluation happens against the template itself or against the execution plan that the IaC tool generates, depending on the engine and the pipeline stage. What distinguishes a well-designed federal implementation from a basic security scan is the specificity and traceability of the rules.
Generic rule sets that ship with commercial or open-source policy engines cover common misconfigurations: public S3 buckets, unencrypted storage volumes, overly permissive security groups. Those checks have value, but they are not sufficient for an ATO program. Federal control requirements are specific. CM-6 requires that configuration settings reflect the most restrictive mode consistent with operational requirements. SA-10 requires that the organization controls changes to the system. A rule that flags an unencrypted EBS volume satisfies a portion of SC-28, but it does not by itself demonstrate that your pipeline enforces CM-6 configuration baselines or that SA-10 change control requirements are met at the code level.
Rule design for federal environments needs to start from the control baseline, not from the engine’s default library. For each control in the CM, CA, SA, and SC families that has an infrastructure configuration component, the team should define what a compliant resource configuration looks like in code, what a non-compliant configuration looks like, and what the policy rule needs to evaluate to distinguish between them. That mapping work is time-consuming, but it is the foundation that makes pipeline evidence usable during assessments.
Rule Specificity and Maintainability
Rules that are too broad generate false positives at a rate that teams cannot sustain. Rules that are too narrow miss violations that fall slightly outside the expected pattern. Federal IaC environments also tend to involve multiple template languages, multiple cloud providers, and multiple platform layers, which means rule libraries need to be maintained across more than one syntax context. A rule written for Terraform AWS provider resources does not automatically apply to CloudFormation stacks or Terraform Azure provider resources covering the same logical control.
Maintainability requires that rules be versioned alongside the control baseline they implement. When NIST updates SP 800-53 or when an agency baseline changes, the team needs to know which rules are affected and update them systematically. That is not possible if rules are written ad hoc without documented control mappings. It is also not possible if the rule library lives in a single engineer’s personal repository without ownership assignment and change management.
Pipeline Stage Placement and What Each Gate Actually Enforces
The most common implementation mistake in IaC CCM is treating policy evaluation as a single gate that runs at one point in the pipeline. In practice, different evaluation stages catch different violation types, and running all checks at a single stage either creates an unacceptably long feedback loop for developers or misses violations that only become visible later in the pipeline execution.
A well-structured federal IaC pipeline evaluates controls at four distinct stages, each with a different scope and a different enforcement action.
| Pipeline Stage | What Is Evaluated | Enforcement Action | Primary Control Families |
|---|---|---|---|
| Pull Request | Template syntax, static policy rules, known misconfigurations | Block merge, require reviewer approval | CM-6, CM-7, SA-10 |
| Merge to Protected Branch | Signed commit verification, required reviewer count, branch protection rules | Block merge if approval requirements unmet | SA-10, AC-3, AU-9 |
| Plan Stage | Execution plan output, resource changes, computed attribute values | Block apply, escalate to approver | CM-3, CM-6, CA-7 |
| Pre-Deployment Approval | Aggregated policy results, exception status, human authorization record | Require named approver sign-off before apply | CM-3, SA-10, CA-2 |
The pull request stage is where static analysis runs fastest and where developer feedback is most actionable. Violations caught here cost the least to fix because no plan has been generated and no approval workflow has been initiated. The plan stage catches violations that are not visible in the template alone, such as computed values, data source lookups, or resource dependencies that only resolve during planning. Running policy evaluation against the plan output rather than the raw template is more accurate but requires that the pipeline have credentials to generate a plan in a non-production environment, which introduces its own access control considerations.
The pre-deployment approval gate is where human authorization is recorded. This is the stage that satisfies separation-of-duties requirements for change control. The person who authored the code should not be the same person who approves the deployment. In practice, enforcing this at the pipeline level means configuring the approval workflow to reject self-approvals and to require that the approver hold a specific role, not just any team member. That configuration needs to be documented and tested, because a misconfigured approval gate that allows self-approval provides no actual separation of duties regardless of what the policy document says.
Practitioner Reality
Most federal IaC pipelines that claim to have policy gates actually have advisory checks. The policy engine runs, produces a report, and the pipeline continues regardless of the result. This happens because the initial implementation was scoped as a visibility exercise rather than an enforcement exercise, or because the team did not want to block deployments until the rule set was tuned. The problem is that advisory mode rarely transitions to enforcement mode. The rule set never gets tuned because there is no operational pressure to do so, and the pipeline evidence shows policy violations that were acknowledged and ignored rather than remediated. That evidence pattern is difficult to explain during an assessment.
Control-to-Rule Traceability and RMF Evidence Generation
The value of IaC pipeline policy checks as RMF evidence depends entirely on whether the checks can be traced to specific controls in the system security plan. A pipeline log that shows a policy evaluation passed is not useful to an assessor unless the assessor can determine which control the evaluation was testing, what the pass criteria were, and whether the rule logic actually reflects the control requirement.
Traceability requires that each rule carry metadata identifying the control or controls it implements. That metadata should be machine-readable so that evidence collection can be automated, and it should be consistent with the control identifiers used in the SSP. When a pipeline run completes, the evidence package should include the rule identifier, the control identifier, the evaluation result, the resource evaluated, the template version, the commit hash, the timestamp, and the identity of any human approver. That set of fields is sufficient to support CA-7 continuous monitoring evidence, CM-3 configuration change control records, and SA-10 developer configuration management documentation.
Evidence retention is a separate operational function from evidence generation. Pipeline logs that are not exported to a durable, access-controlled store are effectively ephemeral. Most CI/CD platforms retain logs for a limited period by default, and that period is rarely aligned with the retention requirements in the system’s security plan or the agency’s records management policy. Evidence packages need to be exported at pipeline completion, stored in a location that is backed up and access-controlled, and indexed in a way that allows retrieval by control identifier, date range, or system boundary. This is where Continuous Controls Monitoring (CCM) programs that treat evidence as a first-class artifact from the beginning have a significant operational advantage over programs that try to reconstruct evidence after the fact for an assessment.
Mapping IaC Checks to NIST SP 800-53 Control Families
The CM control family is the most direct mapping target for IaC pipeline checks. CM-3 covers configuration change control and maps to the approval workflow and change record generated at each pipeline run. CM-6 covers configuration settings and maps to rules that enforce specific resource attribute values. CM-7 covers least functionality and maps to rules that flag unnecessary services, open ports, or permissive access configurations. CM-8 covers system component inventory and can be partially addressed by pipeline-generated resource manifests, though full inventory coverage requires additional tooling beyond the pipeline itself.
The CA family maps to the monitoring and assessment functions. CA-7 requires continuous monitoring of security controls, and pipeline-based policy evaluation contributes to that requirement when the checks run on every change and the results are retained as evidence. CA-2 assessment planning can reference pipeline checks as automated assessment procedures, which reduces the manual assessment burden if the rule logic is documented and the evidence is structured correctly.
SA-10 is frequently overlooked in IaC CCM implementations. It requires that the organization control changes to the system and track security flaws. The pipeline approval workflow, combined with the commit history and policy evaluation records, provides a documented chain of custody for every infrastructure change. That chain of custody is exactly what SA-10 requires, but it only satisfies the control if the pipeline is the authoritative change path and out-of-band changes are detected and recorded.
Exception Handling, Waivers, and Failed-Control Workflows
No policy rule set covers every legitimate operational scenario without generating some exceptions. Federal environments in particular involve legacy resource configurations, shared infrastructure with inherited settings, and operational requirements that conflict with default security baselines. The question is not whether exceptions will exist, but whether the exception process is documented, time-bounded, and traceable.
An exception workflow needs to capture the specific rule that failed, the resource affected, the business or operational justification, the risk acceptance authority, the approval date, and the expiration date. Without an expiration date, exceptions accumulate indefinitely and become indistinguishable from permanent policy deviations. Without a named risk acceptance authority, exceptions cannot be traced to an accountable individual during an assessment or incident review.
The pipeline needs to be configured to recognize approved exceptions and allow the deployment to proceed while still recording the exception in the evidence package. This is technically straightforward but requires coordination between the policy engine, the exception registry, and the pipeline orchestration layer. Teams that implement this manually through comment-based suppressions in the template code create a pattern where suppressions are added without approval and never reviewed. A structured exception registry that the pipeline queries at evaluation time is more auditable and more maintainable.
False-positive management is operationally distinct from exception handling. A false positive is a rule that fires on a compliant configuration because the rule logic does not account for a valid configuration pattern. False positives need to be resolved by updating the rule, not by creating exceptions. If the exception registry is used to suppress false positives, the registry becomes polluted with entries that are not genuine risk acceptances, and the evidence package becomes misleading. Maintaining a separate false-positive tracking process, with a defined path from identification to rule update to verification, keeps the exception registry meaningful.
The following framework describes the maturity progression for IaC CCM exception and waiver management in federal environments.
| Maturity Level | Exception Process | False-Positive Handling | Evidence Quality |
|---|---|---|---|
| Initial | Ad hoc suppressions in template comments | Mixed with genuine exceptions | Pipeline logs only, not retained |
| Developing | Informal approval via ticket, no expiration | Tracked separately but not systematically resolved | Exported logs, inconsistent format |
| Defined | Structured registry, named approver, expiration date | Separate tracking, rule updates documented | Structured evidence packages with control mapping |
| Managed | Registry queried by pipeline at evaluation time | Formal resolution path, rule version history | Automated evidence export, indexed by control |
| Optimizing | Expiration alerts, periodic risk review, trend reporting | False-positive rate tracked as pipeline health metric | Evidence directly consumable by ATO tooling |
Common Mistakes
Federal teams implementing IaC CCM consistently encounter the same set of avoidable problems. Most of them stem from treating the pipeline as a technical implementation rather than an operational program with ownership, governance, and lifecycle requirements.
Running policy checks in advisory mode indefinitely. Advisory mode is a reasonable starting point for rule tuning, but it requires a defined transition plan with a date and an owner. Without that, advisory mode becomes the permanent operating state, and the pipeline produces evidence of violations that were never acted on. That evidence is worse than no evidence during an assessment.
Writing rules without control mapping. A rule library that is not mapped to specific NIST SP 800-53 controls cannot produce usable RMF evidence. The mapping work feels like overhead during implementation, but it is the difference between a pipeline that supports the ATO program and a pipeline that produces logs no one can interpret during a control review.
Allowing out-of-band infrastructure changes. IaC pipeline CCM only covers changes that flow through the pipeline. If administrators retain the ability to make direct changes to cloud resources through console access or CLI sessions, those changes bypass every policy gate and every evidence record. The pipeline evidence then reflects a partial picture of the infrastructure state, which creates a gap between what the SSP documents and what is actually deployed.
Treating the approval gate as a formality. When the pre-deployment approval gate is configured but approvers routinely approve changes without reviewing the policy evaluation results, the gate provides separation of duties on paper but not in practice. Approvers need to understand what they are reviewing and what a failed policy check means for the authorization boundary. That requires training and clear escalation guidance, not just a button in the pipeline interface.
Neglecting rule maintenance after initial deployment. Control baselines change. Cloud provider resource schemas change. New resource types get added to the infrastructure. Rules that were accurate at deployment become stale over time, and stale rules either miss new violation patterns or generate false positives on new resource configurations. Rule maintenance needs to be assigned to a named owner with a defined review cadence, not treated as a one-time implementation task.
Scoping CCM only to production pipelines. Development and staging environments that share the same cloud tenant or platform as production can introduce misconfigured resources that persist or propagate. Policy gates in lower environments also provide earlier feedback and reduce the volume of violations that reach the production pipeline, which reduces the operational burden on approvers and security reviewers.
Recommended Federal Approach
The following approach reflects the operational realities of federal DevSecOps environments: constrained staffing, existing pipeline infrastructure that may not have been designed with CCM in mind, RMF programs that need evidence in specific formats, and acquisition timelines that do not always align with implementation readiness.
Start with a control-to-configuration mapping exercise. Before selecting a policy engine or writing a single rule, identify which controls in the system’s baseline have infrastructure configuration components. For each control, document what a compliant configuration looks like in the IaC templates currently in use. This exercise surfaces gaps in existing templates and provides the foundation for rule design. It also produces a document that the ISSO and assessors can review before any pipeline changes are made.
Select a policy engine based on template language coverage and rule maintainability. The engine needs to support the template languages in use across the program, produce machine-readable output that can be parsed for evidence collection, and support rule metadata that includes control identifiers. Evaluate the engine against the actual templates in the environment, not against vendor documentation or generic test cases.
Implement enforcement in phases, starting with a defined rule set. Begin with a small set of high-confidence rules covering the most critical CM and SC controls. Run in enforcement mode from the start on this limited rule set rather than running a large rule set in advisory mode. Expand the rule set incrementally as each new rule is validated against the environment and the false-positive rate is confirmed to be acceptable.
Configure all four pipeline stages before declaring the CCM capability operational. Pull request checks, merge protections, plan-stage evaluation, and pre-deployment approval gates each serve distinct functions. A pipeline that has only pull request checks and no plan-stage evaluation will miss violations that only appear in computed plan output. A pipeline that has no pre-deployment approval gate cannot satisfy SA-10 change control requirements through the pipeline record alone.
Establish the exception registry and false-positive tracking process before the first enforcement-mode deployment. Teams that implement enforcement without a functioning exception process will face pressure to disable enforcement the first time a legitimate deployment is blocked. Having a working exception path available from day one removes that pressure and keeps the program on track.
Automate evidence export and retention from the first pipeline run. Do not plan to reconstruct evidence later. Configure the pipeline to export structured evidence packages at completion, store them in a durable location, and index them by control identifier and date. Validate that the evidence format is interpretable by the ISSO and assessors before the first assessment cycle that will rely on pipeline evidence.
Assign named ownership for rule maintenance, exception review, and evidence management. Each of these functions requires ongoing attention. Rule maintenance needs a technical owner who understands both the policy engine and the control baseline. Exception review needs a security owner who can evaluate risk acceptance decisions. Evidence management needs coordination between the pipeline team and the ISSO. Without named owners, all three functions degrade over time as the initial implementation team moves on to other priorities.
Validate the CCM capability against a simulated assessment before the first formal review. Run a tabletop exercise where the ISSO attempts to answer a set of CA-7 and CM-3 assessment questions using only the evidence generated by the pipeline. Gaps in the evidence package will surface during this exercise rather than during the actual assessment, when remediation options are more limited.
Need help evaluating solutions for your environment?
Whether you’re modernizing infrastructure, improving resilience, or evaluating technologies, Anchor Defense helps organizations align mission requirements with practical outcomes.