The Department of Defense doesn't accept "trust us, we scanned it" anymore. Since the DoD Enterprise DevSecOps Reference Design first codified what a compliant software factory looks like, and since Executive Order 14028 (May 12, 2021) and OMB Memo M-22-18 (September 14, 2022) made software supply chain evidence a condition of doing business with the federal government, program offices building or buying a "software factory" need an actual architecture — not a marketing label. Anchore has spent the last several years positioning itself as the default vulnerability-scanning layer inside that architecture, particularly around Iron Bank and Platform One. That's a reasonable starting point, but scanning containers at build time is one control among dozens the reference design requires. This piece breaks down what a real DoD software factory has to do, where Anchore fits, where the gaps show up in practice, and how Safeguard closes them.
What Actually Counts as a "DoD Software Factory"?
A DoD software factory is a CI/CD pipeline plus a governed set of hardened artifacts, automated security gates, and continuous evidence generation — not just a Jenkins instance with a scanner bolted on. The DoD Enterprise DevSecOps Reference Design (first published in 2019, with the DoD CIO's Software Factory Reference Architecture following as a companion document) defines the factory as the combination of a source control system, a CI/CD orchestration layer, an artifact repository of hardened base images, and automated security tooling covering SAST, DAST, SCA, container scanning, and SBOM generation — all wired so that every artifact carries evidence from commit to deployment. Platform One, run by the Department of the Air Force since 2019, is the DoD's flagship implementation: it hosts Iron Bank, the centralized repository of over 2,700 hardened, continuously re-scanned container images, and Big Bang, the packaged DevSecOps stack for on-prem and edge deployments. Program offices don't have to use Platform One, but any factory they stand up independently has to demonstrate equivalent controls to earn an Authorization to Operate (ATO), which is where most contractors underestimate the lift.
Why Does the DoD Care About SBOMs Specifically?
Because OMB M-22-18 made a signed self-attestation of secure development practices — grounded in NIST SP 800-218 (the Secure Software Development Framework) — a precondition for federal software procurement, and SBOMs are the evidentiary backbone of that attestation. The memo, later extended by M-23-16 in June 2023, requires agencies to collect attestations for any third-party software deployed on federal systems, with SBOMs available on request as corroborating evidence. Inside a DoD software factory, that means every build has to emit a machine-readable SBOM (CycloneDX or SPDX), tie it to the specific commit and container digest that produced it, and retain it for the life of the ATO package. A one-time SBOM generated during a security review satisfies an auditor for exactly as long as the code doesn't change — which, in an active CI/CD pipeline pushing multiple builds a week, is measured in hours. Anchore's open-source tools, Syft and Grype, are widely used to generate that SBOM and match it against vulnerability feeds, and Anchore Enterprise wraps them with a policy engine. The tooling generates the artifact; it doesn't answer the harder question of whether that artifact is actually being consumed by anything downstream.
Where Does Anchore Fit Into Iron Bank and Platform One?
Anchore has been one of the vulnerability-scanning engines used in the Iron Bank pipeline, running Grype-based scans against submitted container images before they're approved into the hardened repository, and Anchore Federal is marketed specifically at agencies pursuing this workflow. That's a legitimate and useful function — Iron Bank's whole value proposition depends on catching known-CVE images before they get distributed to hundreds of downstream programs. But Iron Bank approval is a point-in-time gate, not a continuous state. A container that clears Iron Bank on a Tuesday can have three new CVEs published against its base image by Friday, and Anchore's model, built around scan-at-submission and periodic re-scan cycles, was designed for a repository gatekeeper use case, not for the continuous per-build, per-deployment evidence trail that a cATO decision requires. Programs that treat "we scan in Iron Bank" as the totality of their software factory security posture consistently find that assessors ask for evidence the scanning workflow was never built to produce — runtime drift detection, deployment-level attestation, and policy enforcement tied to the actual running environment rather than the registry image.
What Is Continuous ATO and Why Does It Change the Requirements?
Continuous ATO (cATO), formalized in the DoD CIO's February 2022 memo, lets a system maintain its authorization indefinitely instead of re-certifying every three years, but only if it satisfies three ongoing criteria: continuous monitoring of the system's security posture, active cyber defense, and adherence to an approved DevSecOps reference design. That third criterion is the one most factories fail quietly. It's not enough to have used a compliant pipeline once at accreditation time — assessors expect to see that every subsequent build still passes the same gates, that the SBOM and vulnerability evidence for the artifact currently in production matches what's on file, and that policy violations trigger automated blocks rather than after-the-fact reports. A factory built around a scanner that reports findings to a dashboard, leaving a human to decide whether to act on them, doesn't meet the "active" bar cATO assessors are increasingly applying. The gap isn't detection — most scanning tools, Anchore included, detect known CVEs reasonably well. The gap is closing the loop between detection, policy, and enforcement inside the pipeline itself, continuously, without manual triage as the bottleneck.
How Do You Prove Compliance Without Drowning Assessors in PDFs?
You don't — DoD assessors reviewing a software factory for ATO or cATO increasingly expect machine-readable, queryable evidence rather than static compliance binders, and programs still submitting PDF SBOM exports and spreadsheet-tracked POA&Ms are the ones facing repeated RFIs and extended review cycles. A single mid-sized program can generate an SBOM per build, a vulnerability scan report per image, a SAST report per commit, and a policy-compliance record per deployment; across a factory pushing 20-plus builds a week, that's thousands of individual artifacts a year that need to map back to NIST SP 800-53 control families for the eMASS or Xacta package. Anchore's policy engine can enforce rules at scan time, but it wasn't built to normalize that output against control-family mappings or to hand an assessor a queryable evidence trail spanning SAST, DAST, SCA, and runtime posture in one place. Most Platform One tenants end up bolting on a separate GRC layer to make the scan output audit-ready, which reintroduces exactly the manual reconciliation work cATO is supposed to eliminate.
How Safeguard Helps
Safeguard was built for the compliance reality DoD software factories actually operate under, not just the detection problem. Where a container scanner stops at "here are the CVEs in this image," Safeguard generates SBOMs automatically on every build, correlates them against live vulnerability intelligence, and maps every finding directly to the NIST SP 800-53 and SSDF control it affects — so the evidence an assessor needs for an ATO or cATO package already exists in a queryable form instead of being assembled after the fact. Safeguard enforces policy inline in the pipeline, blocking noncompliant artifacts before they reach Iron Bank submission or deployment rather than flagging them after release, which is the enforcement gap most factories built around traditional scanning tools still have. For teams already standardized on Platform One or Big Bang, Safeguard slots in alongside existing scanners to add the continuous evidence layer — SBOM lifecycle management, attestation tracking against M-22-18 requirements, and control-mapped reporting — that turns a one-time authorization into a defensible continuous one. If your program is trying to move from periodic ATO to cATO, or is standing up a new software factory and wants the compliance architecture built in from day one rather than retrofitted before an assessment, that's the gap Safeguard is designed to close.