DevSecOps Software Factory
Platform One alignment and cATO-ready pipelines
DoDI 5000.87 requires programmes on the software acquisition pathway to demonstrate viability and effectiveness for operational use no later than one year after funds are first obligated. The Secretary of Defense memorandum of 6 March 2025 makes that pathway the preferred route for software development.
DoD Software Factories provide standardized development environments that enable rapid, secure software delivery. Thalorin aligns with Platform One and service-specific software factory requirements to enable cATO-ready pipelines with integrated security controls and continuous compliance monitoring.
The acquisition side moved first. A Secretary of Defense memorandum of 6 March 2025, Directing Modern Software Acquisition to Maximize Lethality, made the software acquisition pathway the preferred route for the software components of business and weapons system programmes, with Commercial Solutions Openings and Other Transactions as the default award vehicles. DoDI 5000.87 obliges a programme on that pathway to demonstrate viability for operational use within a year of funds first being obligated, and to deliver at least annually after that. That cadence forces the authorization question.
Two mandates now pull in opposite directions. Executive Order 14306, signed on 6 June 2025, struck subsections 2(a) and 2(b) of Executive Order 14144 — the provisions that would have driven FAR language requiring producers to file machine-readable attestations and validating artifacts with CISA. What survived is the attestation obligation that already existed under OMB memoranda M-22-18 and M-23-16. The Department pushed the other way: the Software Fast Track memorandum of 24 April 2025, Accelerating Secure Software, drives towards machine-readable supply-chain evidence and government-led risk determinations.
The condition that stalls software factories is the middle one. The DoD CIO memorandum of 3 February 2022 sets three requirements for continuous authorization: continuous monitoring of RMF controls with a complete understanding of what sits inside the boundary, the ability to conduct active cyber defense against threats in real time, and adoption of an approved DoD Enterprise DevSecOps Reference Design. Two are engineering problems a platform team can own. Active cyber defense is a staffed operations capability, and a pipeline that gates flawlessly does not supply it.
Pipeline output becomes evidence only once it is bound to something. A gate result held against the image digest, the commit, the control it speaks to and the authorization boundary it was produced under can be re-read a year later; the same result held against a build number cannot. That binding is what keeps an inherited control claimed only where the hosting platform documents inheritance. A continuous authorization submission needs a defensible account of which control each artifact answers, and for how long — not more scanning.
Protecting critical programs requires vigilance
Active cyber defense has to be staffed
The February 2022 criteria require real-time response capability alongside continuous control monitoring and an approved reference design. Teams reach the third condition through engineering, then find the second one needs an operations function with people in it.
Iron Bank assesses, it does not authorize
Iron Bank publishes hardened images with their scan findings, justifications and bills of materials, and states plainly that it does not approve containers. The assessment is an input to your authorization; inheritance is granted by the platform, never assumed.
Annual delivery, periodic authorization
The software acquisition pathway obliges a programme to field capability at least annually while a traditional authorization re-evaluates on its own cycle. The mismatch surfaces as releases waiting on a package never designed to move that fast.
A bill of materials nobody consumes
Generating an SBOM is now the easy half. Holding one per released artifact, resolving a fresh disclosure to the images actually deployed, and keeping the justification for what was accepted is where supply-chain evidence is won.
How Thalorin helps
Platform One alignment assessment
Record which platform services an application genuinely consumes and which controls the hosting platform documents as inheritable, so the line between platform responsibility and programme responsibility is written down before an assessor draws it.
Pipeline security control integration
Each gate is mapped to the control it evidences, so a failed stage registers as a change in control status with the build that caused it attached, rather than as a red pipeline somebody re-ran.
Container security compliance
Image findings are held against the digest that was deployed rather than the tag that was requested, with accepted findings carrying their justification, in the shape Iron Bank's own scan output and SBOMs already take.
IaC security scanning
Infrastructure-as-code findings resolve to the deployed resource and to the control that resource configures, so drift between the committed definition and the running environment reads as a control question rather than a diff.
cATO evidence automation
Continuous monitoring evidence is produced from pipeline and runtime telemetry per authorization boundary, which is the condition the 2022 memorandum expects to hold every day rather than at review.
DevSecOps maturity assessment
Assessment runs against DoD Enterprise DevSecOps Fundamentals and the accompanying Activities and Tools Guidebook, so a gap names a missing activity and the artifact it should produce instead of returning a maturity score.
DevSecOps Software Factory: common questions
Does deploying on Platform One give my application a cATO?
No. A platform's continuous authorization covers the platform and the controls it operates. An application deployed on it inherits the controls the platform documents as inheritable, and only those; everything above that line — the application's own code, configuration, data handling and users — stays with the programme and its Authorizing Official. The inherited set is substantial and already evidenced, which is the real benefit. What it is not is a transfer of authorization.
What does DoD require before granting a cATO?
The DoD CIO memorandum of 3 February 2022 sets three conditions: continuous monitoring of RMF controls with a complete understanding of everything inside the authorization boundary, the ability to conduct active cyber defense against threats in real time, and adoption of an approved DoD Enterprise DevSecOps Reference Design. All three are required, and the decision remains the Authorizing Official's. Evaluation criteria published afterwards by the DoD CIO set out what each condition looks like in assessment.
Do Iron Bank images satisfy our container hardening requirement?
They carry evidence for it; they do not conclude it. Iron Bank rebuilds images every 24 hours with updated operating-system packages and republishes what Anchore, Twistlock and OpenSCAP found — including OS STIG policy checks — alongside a Syft bill of materials and vendor justifications for findings left unremediated. Iron Bank states that it does not authorize or approve containers. Your assessment consumes that output and still accounts for how the image is configured, deployed and run.
Do we still have to submit a secure software development attestation?
For federal software sales, yes. Executive Order 14306 struck the provisions of Executive Order 14144 that would have required machine-readable attestations and validating artifacts to be filed with CISA, but it left the underlying obligation untouched: OMB M-22-18, as updated by M-23-16, and the CISA attestation common form both stand. NIST published the initial public draft of SP 800-218 Revision 1 on 17 December 2025; comments closed on 30 January 2026 and it is not yet final.
How does the software acquisition pathway change the authorization timeline?
It compresses it. Under DoDI 5000.87 a programme must demonstrate viability for operational use within a year of funds first being obligated and deliver capability at least annually afterwards, and the memorandum of 6 March 2025 makes that pathway the preferred one for software. An authorization approach built around a multi-year cycle and a document package cannot keep pace with that. It is the practical argument for continuous authorization rather than a philosophical one.
Regulatory state described as of August 2026. Requirements change; verify against the current rule before relying on any date above.
Talk to us about DevSecOps Software Factory.
See how one evidence artifact satisfies DevSecOps Software Factory requirements alongside every other framework you carry.