The Authorization to Operate (ATO) has always been the toll booth on the road to running software inside the federal government. It's also, increasingly, the reason mission software ships eighteen months after the threat it was built to counter has already moved on. In 2022, the DoD CIO tried to fix that by formally defining continuous ATO (cATO) — a path that lets systems keep their authorization indefinitely as long as they can prove, continuously, that they're still secure. Three years later, only a handful of programs (Kessel Run, Platform One, a few Army and Space Force systems) have actually pulled it off, because cATO doesn't reward better paperwork — it rewards better evidence. Vendors like Anchore have built businesses around one slice of that evidence: container image scanning. This post explains what ATO and cATO actually require, where container-only tooling falls short, and how Safeguard closes the evidence gap across the full software supply chain.
What is an ATO, and why does it take so long?
An ATO is the formal risk decision, signed by an Authorizing Official (AO), that a federal information system may operate in production. It comes out of the NIST Risk Management Framework (RMF, NIST SP 800-37 Rev. 2), a seven-step process — Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor — built around NIST SP 800-53 Rev. 5, which contains over 1,000 individual controls across 20 control families. Assessing all of that manually is slow: GAO and multiple DoD IG reports have put average ATO timelines at 6 to 18 months, and FedRAMP authorizations for cloud service offerings have historically averaged closer to 12 to 24 months and $2-4 million in assessment costs. Worse, the ATO is a snapshot: the moment it's signed, the system is already drifting from the state that was assessed, because dependencies update, configurations change, and new CVEs get published daily.
What is continuous ATO, and how is it different?
Continuous ATO replaces the point-in-time snapshot with an ongoing, evidence-backed authorization that never has to be fully re-earned from scratch. The DoD CIO's March 2022 memo, signed by John Sherman, defines three criteria a program must meet to qualify: (1) continuous visibility into the system's cybersecurity posture through automated tooling, (2) an active cyber defense capability that can detect and respond to threats in near-real time, and (3) adoption of an approved DevSecOps reference design with automated security gates in the CI/CD pipeline. In practice this means an AO no longer approves a system once every three years — they approve a pipeline and a monitoring regime that continuously regenerates the evidence a traditional ATO would have required a team of assessors to manually compile. The authorization becomes a living artifact, refreshed by telemetry rather than a triennial audit cycle.
Which programs have actually achieved cATO, and what did it take?
Only a small, well-documented set of DoD software factories have reached cATO, and all of them got there by instrumenting their pipelines, not by writing better security plans. Kessel Run, the Air Force's software factory, was among the first to receive cATO in 2022 after building automated control validation directly into its deployment pipeline. Platform One's Big Bang and Party Bus followed a similar path, layering hardened, continuously scanned container baselines from Iron Bank on top of an automated ATO package generator. The common thread across every public cATO case study is the same: none of them treated a single scanning tool as sufficient. Each built a chain of evidence spanning source code provenance, build integrity, artifact signing, SBOM generation, and runtime monitoring, because the DoD memo's "continuous visibility" criterion applies to the whole system, not just the container it ships in.
Why isn't container image scanning enough to sustain a cATO?
Container image scanning isn't enough because a cATO's continuous-visibility requirement covers the entire software supply chain, and a container image is only the last few inches of it. This is the gap that shows up when programs try to lean on tools like Anchore, which built its reputation on scanning built container images and generating SBOMs at the registry stage. That's real value, but it answers only one question — "what's inside this image right now?" — while an AO assessing cATO evidence needs answers to several more: Where did this source code come from, and was it signed by a known identity? Did the build system that produced this artifact match an approved, attested pipeline (per SLSA and NIST SP 800-218, the Secure Software Development Framework)? Are the 200+ transitive dependencies typically found in a modern Java or Node service being tracked for newly disclosed CVEs after the image was built and deployed, not just at scan time? Executive Order 14028 and OMB Memo M-22-18 both push agencies to require software producer attestations covering the entire build process — a scope that image scanning alone, by design, doesn't reach.
What does FedRAMP 20x mean for the future of continuous authorization?
FedRAMP 20x, launched by the FedRAMP PMO in 2025, matters because it's an explicit attempt to bring the DoD's cATO logic to the much larger population of civilian cloud authorizations. The pilot program, which began accepting Low- and Moderate-impact cloud service offerings that year, replaces large parts of the traditional paper-heavy Security Assessment Report with machine-readable, continuously validated evidence submitted through automated pipelines — cutting the target authorization timeline from FedRAMP's historical 12+ months toward a matter of weeks for participating vendors. The direction of travel across both DoD and civilian agencies is now the same: authorizations built on automated, continuously refreshed evidence will outcompete authorizations built on static documentation, and vendors whose compliance tooling stops at the container registry will need to bolt on separate systems to cover source, build, and dependency provenance — exactly the pieces FedRAMP 20x and OMB M-22-18 attestations are starting to require by name.
How Safeguard Helps
Safeguard is built for the evidence chain a cATO actually requires, not just the image at the end of it. Where container-scanning-first tools like Anchore give you a point-in-time inventory of what's running, Safeguard continuously tracks software provenance from source commit through build pipeline through deployed artifact, generating and maintaining SBOMs and VEX documents that update automatically as new CVEs are disclosed against your dependency tree — not just at build time. That continuous, always-current record maps directly onto the DoD's cATO "continuous visibility" criterion and onto the machine-readable evidence FedRAMP 20x and OMB M-22-18 attestations are moving toward.
Concretely, Safeguard gives compliance and security teams:
- Full-pipeline provenance, from source code identity and commit signing through build attestation aligned to SLSA and NIST SP 800-218, so AOs get evidence of how software was built, not just what it contains.
- Continuous SBOM and VEX generation that stays current after deployment, automatically flagging newly disclosed CVEs against components already in production — closing the gap left by scan-once, ship-once tooling.
- Control-mapped reporting that ties findings directly to NIST SP 800-53 control families and RMF steps, so evidence packages for AOs and assessors can be generated on demand instead of compiled manually every assessment cycle.
- DevSecOps pipeline integration that fits the DoD's approved reference-design model, so security gates run automatically in CI/CD rather than as a separate, periodic audit activity.
For agencies and contractors trying to move from a triennial ATO to a defensible cATO, the bottleneck usually isn't the container — it's everything upstream and downstream of it. Safeguard is built to cover that whole chain, so the authorization you earn keeps holding up long after the ink on it has dried.