Evidence as Code: Pipeline Gates, OSCAL, and Continuous Monitoring for RMF

An authorization decision rests on evidence, and in most programs that evidence is produced by people. An ISSO exports scanner results, captures console screenshots, pastes configuration excerpts into implementation statements and uploads the lot to eMASS, Xacta or CSAM. The package is accurate on the day it is assembled. By the next sprint it describes a system that no longer exists.

NIST SP 800-37 Rev. 2 (opens in a new tab) already assumes something better. Its seven steps, starting with Prepare, support ongoing authorization based on continuous monitoring, and the Monitor step expects control effectiveness to be tracked as the system changes. The framework is not the bottleneck. The manual evidence model underneath it is.

This article describes the engineering that replaces it: where controls get checked, how results get recorded, and how the governance record stays current without a data call.

Why the Pipeline Is the Right Control Point

Every change that reaches a pipeline-delivered system passes through the build and deployment pipeline. That makes the pipeline the one place where configuration, dependencies and infrastructure definitions can be checked on every change, with a timestamp and an identity attached to the result.

A control gate is a pipeline stage that runs a defined check and either passes the change, fails it, or opens a tracked exception. The useful gates for RMF evidence fall into four groups:

• Configuration baselines. Operating system and application settings checked against the applicable DISA STIGs or agency baselines, using SCAP content where DoD requires it and OpenSCAP for operating system profiles.
• Infrastructure-as-code policy. Terraform or CloudFormation templates checked before deployment for the misconfigurations assessors find most often: wildcard IAM permissions, storage buckets with public access, unencrypted EBS volumes or managed disks, and security groups open to 0.0.0.0/0 on SSH or RDP.
• Dependency and image scanning. Container images and third-party packages scanned for known vulnerabilities, with results mapped to RA-5.
• Change records. Each merged change linked to its ticket, approver and test results, which is the evidence CM-3 asks for.

A failed gate is evidence too. A record that shows a noncompliant change was blocked, or accepted with a documented exception and an owner, tells the assessor more about control effectiveness than a clean screenshot does.

Compliance-as-Code Profiles

Gates are only as good as the checks they run. Compliance-as-code means writing each check as a versioned, testable artifact tied to the control it evidences.

The mapping column is where most programs cut corners. A check that proves encryption at rest evidences SC-28 for that resource, not for the system. Each profile should state which control, which component and which organization-defined parameter it tests, so an assessor can trace the control to the check, the check to its last result, and the result to a date.

Cloud-provider posture tools deserve a caution. Their NIST 800-53 mappings cover the cloud configuration layer only. They do not know the system boundary, the inherited controls, or the agency's parameter values, so their compliance percentages are inputs to the record, not the record itself.

Inheritance Is Architecture, Not Assertion

Most systems now run on a FedRAMP-certified cloud service or an enterprise platform, and a large share of their controls are inherited or shared. AOs reject inheritance when it is asserted rather than mapped.

The fix is a customer responsibility matrix built from the provider's own documentation. For each control, it records whether the control is inherited, shared (hybrid), or the system's own responsibility. Shared controls need the most care: the provider encrypts the storage service, but the tenant must enable encryption on each resource and manage its keys. Those tenant-side halves become compliance-as-code checks like any other.

The provider side is changing too. The FedRAMP Consolidated Rules for 2026 (opens in a new tab), launched June 25, 2026 and mandatory from January 1, 2027, replace the Low, Moderate and High structure with certification classes and push providers toward machine-readable evidence. Agency packages that inherit from those providers should expect the provider-side artifacts to change format over the next two years, and should map inheritance at the control level so a format change does not break the record.

Structuring the Record in OSCAL

OSCAL (opens in a new tab), NIST's Open Security Controls Assessment Language, defines machine-readable models for the artifacts an authorization depends on: control catalogs and baseline profiles, component definitions, the system security plan, assessment plans and results, and the POA&M.

The practical value is not the file format. It is that each implementation statement can be tied to a component definition, and each assessment result to a specific control and component, in a structure tools can read. Where the governance platform accepts OSCAL, results can be imported rather than retyped. Where it does not, structuring the source data to the OSCAL model still pays off: implementation statements live in version control next to the code they describe, and change when it changes.

Two limits apply. Platform support for OSCAL import varies, so the record in eMASS, Xacta or CSAM remains the system of record the AO signs against. And OSCAL describes evidence; it does not make weak evidence strong.

The Monitoring Strategy That Holds It Together

Pipeline gates cover what changes. Continuous monitoring covers what drifts. NIST SP 800-137 (opens in a new tab) defines the information security continuous monitoring (ISCM) program, and the strategy for a system has to answer four questions for every control:

1. How often is it checked? Automated configuration controls can be checked daily or on every change; policy and training controls may be checked annually.
2. What metric shows it is working? Examples include the share of assets scanned within the required window, or the median age of open high-severity findings.
3. Which data feed supplies the metric? Scanner exports, configuration monitoring, pipeline results, or the identity provider's logs.
4. When and how is it reported to the AO?

The feeds then drive the record. A new scanner finding above the risk threshold opens a POA&M item with an owner and a due date. A closed finding closes it, with the rescan as evidence. That loop is what CA-5 and CA-7 describe, and it is what keeps the risk picture current between assessments.

What DoD's Continuous Authorization Asks For

DoD's February 2022 cATO memorandum (opens in a new tab) sets three competencies a program must demonstrate: ongoing visibility of cybersecurity activity inside the boundary with continuous monitoring of RMF controls, active cyber defense that responds to threats in real time, and use of an approved DevSecOps reference design. The same memo is explicit that continuous authorization can be revoked, and that losing it does not by itself remove an existing ATO.

Evidence as code addresses the first competency directly and supports the third. It does not deliver the second, which depends on the program's security operations. A program pursuing cATO should map its evidence to the DoD evaluation criteria early, because the gap is usually in operations, not in paperwork.

DoD has also named a successor to the framework itself. Its Cybersecurity Risk Management Construct (opens in a new tab), announced September 24, 2025, lists automation, continuous monitoring and ATO, DevSecOps, inheritance and reciprocity among its tenets. RMF processes, DoDI 8510.01 and eMASS remain in use while implementation guidance is issued. Evidence tied to the underlying controls carries across constructs; evidence tied to a document template does not.

What Stays Manual

Some controls will always need people. Policy, awareness training, contingency plan testing, personnel screening and physical protection are evidenced by documents, records and exercises, not scans. The goal of evidence as code is not full automation. It is to automate what can be automated so ISSOs spend their time on risk decisions and the controls that need judgment.

The same honesty applies to cost. Automation only pays when there is manual labor to replace and delay to remove, and a break-even test for RMF Integration (opens in a new tab) shows the case where it does not.

How the Build Sequence Runs

For one Moderate system, the work typically takes four to eight months:

Hands-on remediation of findings is capped in the scope and overflows by change order, the same way remediation is treated as a funded line item rather than a backlog (opens in a new tab). The independent assessment and the authorization decision stay with the assessor and the AO.

Avalon's RMF Integration service builds this evidence layer for one system at a time: the tailored baseline, the inheritance matrix, the pipeline gates and compliance-as-code profiles, and the monitoring strategy feeding your governance record. It positions the system for independent assessment and the authorization decision, and leaves your staff running the process when the engagement ends.