Rohith Narayan
“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.
No comments:
Post a Comment