The push for software that is secure by design — as well as for improved software supply chain security — is gaining momentum with new marching orders from the U.S. Department of Defense (DoD) as it revamps how it tests, authorizes, and procures software.
Dubbed the Software Fast Track (SWFT) program, the initiative is part of DoD’s drive to modernize for the continuous-delivery, open-source-dominated software world. DoD leadership said that SWFT will ditch the slow, point-in-time authority-to-operate (ATO) procurement process with better supply chain risk management (SCRM) tooling and assessment.
The goals are clear, wrote acting DoD CIO Katie Arrington in a memo announcing SWFT: to fast-track suppliers that offer usable software bills of materials (SBOMs) and continuous risk assessments with easily shared artifacts, and to better automate DoD-led risk assessments.
“Lengthy, outdated authorization processes frustrate agile, continuous delivery. Additionally, widespread use of open-source software, with contributions from developers worldwide, presents a significant and ongoing challenge. The fact that the Department currently lacks visibility into the origins and security of software code hampers software security assurance.”
—Katie Arrington
Here's what your organization needs to know about the new SWFT rules for software procurement — and what they mean for the state of supply chain security and tooling.
[ Get the White Paper: Go Beyond the SBOM. See the Webinar, Welcome CycloneDX's xBOM ]
The SWFT timeline
The DoD memo kicked off what the Pentagon said would be a 90-day blitz to come up with a SWFT Framework and Implementation Plan. The first part of this process was the release of a trio of requests for information (RFIs) from the software and supplier community about industry capabilities and preferences regarding SCRM tooling and SBOMs, information sharing, and automated assessments. Those RFIs closed on May 20, and the planning process is still underway.
Dick Brooks of Business Cyber Guardian (BCG), who worked closely with NASA in developing the Secure by Design Software Acquisition guide, published by the U.S. Cybersecurity and Infrastructure Agency (CISA), said SWFT is part of an approach to software that is currently evolving at DoD.
“We see some of this work being played out within other guidance that DoD is producing already. They have their fiscal year 2025-26 modernization plan, and that has some very good insights on what you should expect from DoD. And they've already made it very clear that they're following CISA guidance with regard to Secure by Design and best practices such as the Software Acquisition Guide.”
—Dick Brooks
Brooks said the DoD changes expected in SWFT and the modernization plan are consistent with the work NASA has done to bring more governance and rigor to SCRM and the generation and sharing of SBOMs. He said this is reflected also in an overhaul of broader guidelines from the Federal Acquisition Regulation Council, which includes guidance for SBOM requirements that were led by NASA’s early work.
“A lot of what SWFT is doing is already starting to be addressed, especially if you’re watching what’s happening with federal acquisition rules. We also see this playing out in the U.S. Coast Guard order that recently came out for the maritime industry. They’re now going to require vessels and onshore facilities and offshore facilities like oil rigs to maintain a trust registry of products they have installed in IT and OT.”
—Dick Brooks
Reading the tea leaves
Despite the groundswell of interest in SCRM, SWFT is still emerging. Experts trying to figure out how it will compare to ATOs are sifting through clues to figure out where DoD is headed. Most DoD attestations [ATOs] in the past have been about demonstrating point-in-time security and controls for products.With SWFT, the emphasis will need to shift toward demonstrable security practices, evidence collection, and processes to maintain visibility in the software supply chain, while not slowing down deployment, the experts stressed.
The RFIs offer some of the best clues for how the DoD hopes to achieve this shift to a more continuous machinery for proving out software security and SCRM. A three-prong approach, summarized below, seems likely:
- SBOM and artifact sharing: The first RFI tackles tool chain capabilities around SCRM and how SBOMs are generated and shared. It asks organizations that use SBOMs about best practices and organizations that don’t what roadblocks they have encountered.
- Shift in external risk assessment of supplier software: The second RFI asks whether and how organizations audit and assess their software security and what qualifications and requirements might be needed to carry out external assessment functions in future DoD-led assessments.
- Automation and AI: The third RFI focuses on automation and AI, asking how DoD-led assessments — governed by the DoD’s risk management framework (RMF) could leverage automation or AI to execute assessments, automate determinations, and streamline the process. It also asks about the data needs around SBOMs and other sources that would be required to use automation to the fullest in this capacity.
Chris Hughes, CEO of Aquia, said it’s clear that DoD's intention is to fundamentally change how software products are authorized for use, but how it will get there is still up in the air.
“It’s safe to say that there is a lot to be seen in how DoD implements this SBOM requirement and how effectively it does so to avoid it becoming another performative art and checkbox exercise."
—Chris Hughes
Risk ownership is in play
One important question with the new DoD initiative is risk ownership. The DoD hasn’t said who will be in charge of the external assessments — and how much self-attestation will figure into SWFT. Jason Soroko, senior fellow at Sectigo, said the SWFT initiative signals a potential shift in risk ownership.
"The plan for federal government-led risk determinations, rather than sole reliance on vendor or community attestations, could fundamentally alter accountability. This suggests the Department of Defense may increasingly define and accept risk for both proprietary and open-source software components.”
—Jason Soroko
Learn how SaaSBOMs deliver better visibility. RL's Dave Ferguson explains how they can deliver insights into all of the APIs and services in your software, enhancing transparency beyond a typical SBOM.
