“Software is never done and must be managed as an enduring capability that is treated differently than hardware,” observed the Defense Innovation Board (DIB) in its influential Software Acquisition report, urging the Pentagon to treat code as a ‘living system’, not a finished product. Yet, the Department of the Air Force’s (DAF) new Software-as-a-Service (SaaS) policy does the opposite. Aimed at standardizing enterprise IT and improving cybersecurity, the memo bans “custom code development” or “modification that extends a SaaS platform beyond its original design,” including APIs or integrations to meet evolving mission needs.
While the policy seeks to reduce vulnerabilities and enforce uniformity, it risks rapid and adaptive innovation – necessary for resilience and mission success. In trying to mitigate risk, the DAF undermines the core principles of software-defined warfare – speed, iteration, and continuous adaptation that are the foundations of lean development, DevSecOps, and the DIB’s doctrine that “software is never done.” These practices lock systems into static silos resulting in slower iteration, and a regression to the bureaucratic “security theater” that modern DevSecOps was meant to replace.
By locking platforms to their vendor’s original design, the department hopes to maintain a uniform, ‘locked down’ software environment that’s easier to monitor, certify and secure. There are three key problems with this approach –
Software is never done
One, the provision misunderstands the nature of software – it is never static, only constantly evolving. In contrast to hardware, which can be maintained in a linear fashion, software degrades not through physical wear, but through obsolescence. By prohibiting custom code development and API-based modification, the provision freezes every SaaS platform at the point of purchase.
When all modifications are banned, embedded development teams are structurally prevented from fixing bugs or improving usability, creating mandatory time-consuming waits for vendor or headquarters approval, even for small changes. For example, if a flight operations unit discovers that their alert dashboard needs an additional filter or visualization, the unit awaits authorization from the Chief Information Officer (SAF/CN) or the Cloud Authorizing Function (CAF), a process that can take weeks or even months. A developer could address this in a day via an API. This introduces waste, adds bureaucratic rigidity, and kills experimentation- key characteristics of agile and lean development.
In DevSecOps, waste is any effort that consumes resources without adding value to the customer (warfighters). Lean development seeks to eliminate that waste by accelerate learning and delivering capability at mission speed. By forcing teams to endure bureaucratic ‘wait states’ via centralized approvals, the policy erases competitive advantage and multiplies administrative overhead, by diverting feature development and increasing handoffs. Such waste has direct operational consequences: every delay in code flow means vulnerabilities linger longer, fixes arrive slower, and the system’s overall resilience declines. When flow stops, learning stops – killing experimentation necessary for innovative edge.
Most importantly, the Lean principle of “decide as late as possible” emphasizes rapid experimentation, deferring major commitments until facts are clear. The DAF policy forces the opposite. Teams must lock functionality early for enterprise approval, committing to architectures long before user needs are validated. By forcing teams to define scope and functionality years in advance, the policy almost guarantees that the final product will be outdated by the time it’s delivered, creating high-technical debt. This prohibition also undermines the Hacking for Defense (H4D) approach, which applies Lean startup methods to military innovation. If embedded teams cannot rapidly prototype capabilities, they lose the technical ability to ‘discover and validate customer needs’ and test their solutions in a low-cost, low-risk, high-speed manner. This breaks the iterative feedback loop required for meaningful agile success, effectively killing organic innovation at the tactical edge.
In software, Speed is security
Two, While the department views restricting APIs and custom development as a security safeguard, in modern software the opposite is true. The DIB’s study has established slowing change in software developments cripples both innovation and security. The faster a system can be developed, deployed, and updated, the lower its cumulative risk. In short, in software, speed is security. By iteratively developing and deploying software, rapid iteration teams can focus on critical functionality and allow quicker identification and correction of any existing problems.
By locking platform functionality and tying updates to external vendor roadmaps, the department’s policy effectively surrenders control over its own response timeline. If an adversary exploited a vulnerability or launched a zero-day attack, internal teams would be barred from issuing immediate fixes, forced instead to await a vendor update. The result is extended exposure and degraded mission assurance, the exact vulnerabilities the policy aims to prevent.
Software is not hardware, and not all software is the same
Three, the DAF’s policy rests on a fundamental category error: treating software like hardware. Hardware can be frozen, certified, and fielded in stable configurations. Software, by contrast, is inherently dynamic, and depends on continuous updates.
The institutional failure underpinning this policy stems from an analytical inability to differentiate between software types. The memo classifies SaaS as a “commodity-based subscription service” managed primarily by consumption metrics. This model is appropriate for administrative applications (Type A/B software, such as email systems). However, applying the same rigid customization ban to SaaS systems that support mission capabilities (Type C/D software, such as logistics or command and control) fails to recognize that software is not monolithic. This misclassification violates the DIB’s crucial finding that “software is different than hardware, and not all software is the same.”
Modern, cloud-native software is built not as a standalone product but as a component within a larger system-of-systems. The policy misreads this reality, treating purchased SaaS tools as finished products rather than foundational layers on which mission-specific capabilities are built. This rigidity directly affects the Air Force’s current digital ecosystems like Kessel Run, Platform One, and Wavelength, which rely on rapid iteration and embedded teams to deliver updates at operational tempo. Without API-driven integration, they risk sliding back into the legacy “block upgrade” cycles the service worked to escape. At the enterprise level, the restriction endangers integration efforts including the Advanced Battle Management System (ABMS) and Combined Joint All-Domain Command and Control (CJADC2), which depend on real-time interoperability. Limiting connectivity makes these networks brittle just when joint operations demand seamless coordination, while blocking the interfaces and data flows essential for government-owned competence and rapid algorithmic innovation.
The Way Forward: From Restriction to Assurance
To address this, the DAF must shift its approach from restriction to assurance. First, the DAF must redefine security as process, not prohibition. Continuous integration, automated testing, and real-time monitoring already provide visibility far beyond what static certification can achieve. These tools make agility and assurance mutually reinforcing rather than mutually exclusive.
Second, the DAF must differentiate governance by mission risk. Administrative systems can justifiably be locked down, but operational and warfighting platforms must remain adaptable. A tiered model that allows greater customization and API use for high-impact systems would restore speed without sacrificing accountability.
Third, the DAF must empower embedded software teams such as Kessel Run and Platform One to execute secure changes at the edge. These teams already operate within accredited toolchains and continuous monitoring environments. SAF/CN’s role should evolve from gatekeeper to standard-setter, providing technical baselines instead of waivered benchmarks.
Ultimately, the DAF must prioritise process over product and ensure modern software does not turn into a closed procurement catalogue. Only by embracing iterative adaptation and agile development as a measure of strength, the DAF can transform software into a true technological and strategic advantage.
Rohith Narayan Stambamkadi is an Associate at Starburst, an innovation consulting firm that fast-tracks innovation to deployment of early-stage ventures in defense and aerospace. He is a graduate student at the Security Studies Program (SSP), Georgetown University, where he focuses on Defense innovation and Software-defined warfare.
This article was originally published by RealClearDefense and made available via RealClearWire.
