Tested Waves: The Engineering Behind a Federal Remediation Sprint

Most federal patching problems are not tooling problems. Agencies already own Configuration Manager, Intune, Tanium or BigFix, Ansible, and the cloud providers' patch services. What they lack is a disciplined pipeline that turns scan output into closed findings without breaking the systems the mission depends on. Patches that break a mission application teach system owners to refuse the next wave, and the backlog grows.

This article walks through that pipeline as it runs in a fixed-scope remediation sprint, from intake to proof of closure.

Step 1: Normalize Before You Patch

Findings arrive from several sources: scanner exports (Tenable, ACAS in DoD, Qualys, Rapid7), penetration test reports, IG and GAO findings, Security Assessment Report results and open POA&M items. The same flaw on the same asset is typically reported more than once, under different identifiers.

Normalization merges them into one backlog in which each entry is a specific flaw on a specific asset with a named owner. Two decisions are made here and written down:

• The baseline. A named scan export and date that defines the scope of the sprint. New findings after that date go to an emergency lane or a change order.
• The validation tool. The scanner and scan policy used for the baseline must be the same ones used to confirm closure. Switching tools at the end produces mismatched results and disputes about what was fixed.

Asset-to-owner mapping is often the slowest part of this step, and the most valuable. It also exposes inventory gaps: assets the scanner sees that no one claims, and assets in the inventory the scanner never reaches. Both go on a list for the agency rather than being silently dropped, because an unscanned asset is an unmeasured risk. Findings age in the gaps between the ISSO who owns the POA&M, the system owner who holds the ATO, and the contractor who touches the servers.

Step 2: Triage Against BOD 26-04

For civilian agencies, CISA BOD 26-04 (opens in a new tab) sets the remediation clock for each vulnerability from four inputs: whether the asset is publicly exposed, whether the CVE is in the Known Exploited Vulnerabilities catalog, whether exploitation can be automated, and whether it yields total or partial control. A KEV-listed flaw with total control gets three days plus forensic triage; an internal, automatable flaw with partial control gets 60 days.

The triage step assigns every finding its clock, then refines order within each tier using EPSS exploit-prediction scores and SSVC decision logic, plus mission context the agency supplies. CVSS stays in the record as supporting context, but it no longer drives federal prioritization. DoD systems are not bound by the directive, but the same four questions are a sound way to order a STIG and ACAS backlog ahead of a readiness inspection.

Step 3: The Test Ring

Every update is applied first to a test ring: a designated test group or pre-production environment for its platform, or, where none exists, a small pilot ring of production systems named in writing. The ring runs long enough to surface the common failures:

• services that fail to restart after a reboot;
• application compatibility problems with a changed library or runtime;
• agents or drivers that conflict with security tooling;
• configuration drift where a patch resets a hardened setting.

Findings from the ring go into the change-board package for the wave. A patch that breaks something in the ring is either fixed, deferred with a documented reason, or routed to mitigation engineering.

Step 4: Change-Board Packages and Waves

Waves are grouped by platform and fix type, so each one can be tested, approved and deployed as a unit. Each goes to the agency's change advisory board as a complete package:

1. scope and affected systems;
2. test-ring results;
3. deployment method and window;
4. validation approach;
5. rollback plan with a defined response time.

Deployment uses the agency's own tools: Configuration Manager, Intune or WSUS for Windows, Ansible or the agency's Linux tooling, and AWS Systems Manager Patch Manager or Azure Update Manager for cloud workloads. Waves start with the least critical systems in each group and move toward the most critical, so problems surface where they cost least.

The throughput limit is almost always the change board, not the engineers. In a planning model for a 480-finding sprint, closing about 60 findings a week clears the backlog in 12 weeks; at 35 a week, which is what scarce maintenance windows typically allow, it takes 18. The cost side of that difference (opens in a new tab) is what a budget office will weigh.

Step 5: The Emergency Lane

Top-tier BOD 26-04 findings cannot wait for the regular wave. They go through an emergency lane agreed with the agency in advance: a compressed test step, an expedited change approval, deployment outside the normal cycle, and forensic triage.

Forensic triage matters because patching a flaw an attacker has already used does not evict the attacker. For the highest tier, the check for prior compromise comes before or alongside the fix, with evidence collected before the patch overwrites it. Confirmed compromise moves to a formal incident response engagement.

Step 6: Configuration Remediation

Many findings are not missing patches but configuration deviations: STIG or CIS Benchmark settings, weak protocols and cipher suites, unnecessary services, and policy or registry settings. These are fixed through the same wave process and verified with SCAP Compliance Checker or Evaluate-STIG on DoD systems, which produce the evidence CM-6 needs.

Cloud configuration findings follow the same path. 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 are remediated through infrastructure-as-code changes where the environment is managed that way, so the fix survives the next deployment.

Step 7: Mitigation Engineering for What Cannot Be Patched

Every backlog includes findings with no usable patch: end-of-support software, frozen mission systems, vendor-managed appliances. These get compensating controls designed for the specific risk:

Each mitigated finding gets a residual-risk memo for the Authorizing Official. For end-of-support edge devices, mitigation is temporary: BOD 26-02 (opens in a new tab) requires civilian agencies to decommission devices already past end of support within 12 months and replace all identified devices within 18.

Step 8: Validation and Closure Evidence

A finding is closed when the baseline scanner, run with the baseline policy, no longer reports it, and when an assessor would accept the evidence. Each closure package contains the before-and-after scan results, any configuration diff, the change record and screenshots where useful. Packages are stored in the agency's system of record, such as eMASS, CSAM, ServiceNow or Jira, with recommended POA&M updates so the ISSO can close items without rebuilding the proof.

The evidence format is agreed and sampled early in the sprint. Changing it later means reworking hundreds of packages, which is why format changes after the sample go through a change order. That evidence is also what an ATO compliance roadmap (opens in a new tab) expects to find in the authorization record when the next assessment comes.

Step 9: Rollback That Has Been Rehearsed

A rollback plan that has never been tried is a hope, not a plan. For each platform, the first wave includes a deliberate rollback on a test-ring system, timed and documented, so the team knows how long recovery actually takes before it needs to. Rollback methods differ by platform: uninstalling an update or restoring a snapshot on Windows, package downgrade or image rollback on Linux, and redeploying the previous image or template for cloud workloads. The change-board package states which one applies and how long it takes, which is what lets a cautious system owner approve the wave.

Step 10: Reporting That Separates Cause From Delay

Weekly wave reports cover findings closed, findings mitigated, clock compliance by BOD 26-04 tier, and aging of what remains. Each report also carries an agency-attributable delay log: maintenance windows not granted, access that arrived late, approvals still waiting. That log is not defensive paperwork. It shows the program office exactly which of its own levers would speed the sprint up, and it keeps the schedule conversation factual when dates move.

Where the Sprint Stops

A remediation sprint fixes and proves. It does not discover new vulnerabilities beyond validation rescans, own the POA&M lifecycle, run full incident response, deploy a new patching platform, or fix custom application code. Some findings will always be unpatchable, and the honest output for those is a documented residual risk, not a claim of closure.

Avalon's Remediation & Patch Management service runs this pipeline as a fixed-price sprint for one system boundary on your own tools: normalized backlog, BOD 26-04 triage, tested waves through your change board, mitigation engineering, and closure evidence your ISSO can file.