Rob Caudill and John Speed Meyers
Open source code is used increasingly across the entire federal government and the U.S. military. But a new digital rubicon is looming: the use of open source code as a condition within U.S. Defense Department and intelligence community software acquisition contracts.
A 2003 survey conducted by The MITRE Corporation found, even then, that the Defense Department used over 100 free and open source software applications. The National Security Agency and the National Geospatial-Intelligence Agency, among others, now also maintain public GitHub accounts, websites for sharing and accepting open source code.
Before contract officers lock their doors and hide under their desks, the notion of open source code should be defined. Open source software can be freely accessed, used, changed and shared by anyone. An open source software contract extends this idea by requiring a government contractor to provide or maintain open source software—to be managed on a web-accessible code hosting site such as GitHub or GitLab and made searchable via code.gov—as a contract deliverable. Such open source code contracts within the military and intelligence software contracting community are sufficiently rare to be essentially nonexistent. What little data that does exist paints a similar picture. Although federal source code policy requires that agencies open source at least twenty percent of all new custom code created from 2016 to 2019, the Defense Department has open sourced less than 10 percent of its new custom code during that period, earning a “noncompliant” status.
To help parties—both in and out of government—consider the adoption of open source code contracts, this article summarizes both advantages and disadvantages related to user innovation, software development, contracting, governance, national security and cybersecurity.
When code developed for the government is made open source, the government accrues several advantages.
Most importantly, open source isn’t just a concept to be used by programmers. It’s a mode of organization and thinking that can inspire a community of users to collaborate and share ideas. It brings users together to build, test and use products, which, in the process, improves the software product. Examples of successful military and intelligence open source initiatives are the geospatial and situational awareness app TAK, the mapping system FalconView, and the software reverse engineering tool Ghidra.
Second, open source software is a better fit for the post-COVID-19 government workforce. The pandemic has forced the U.S. government to rethink the traditional work environment, forcing many civil servants to work from home. While working from home precludes writing software in a classified facility, it makes working on open source projects easier. Open source projects lend themselves to geographically distributed software development. With Internet access, users can collaborate and contribute to a project from anywhere.
Third, open source code contracts also potentially provide benefits related to contracting and democratic governance. Similar to the idea of open architectures for military contracting, open source code contracts can help avoid vendor lock-in, making application programming interfaces only a website away and thus easy to inspect. Moreover, making contracts open source would bring the Defense Department and other executive branch agencies into compliance with federal source code policy. These contracts also make oversight easier, both for technical management organizations and even potentially for the public at large. Fraud, waste and abuse can be monitored more efficiently in a world of open source repositories. However, this might require the rise of new open source code nonprofit watchdogs.
Finally, another benefit is that bugs are potentially discovered and fixed more quickly than for proprietary software. Because anyone can view, modify and improve code, as Linus’s law states, “given enough eyeballs, all bugs are shallow.”
Skeptics will likely point out that firms selling software to the military and intelligence community might balk at this proposition. Why open source their secret sauce? While this reaction is possible and likely, there is also potential that some contractors, especially upstarts, might view open source code contracts as a way to pry open an otherwise closed market, creating a software market more easily accessed by nontraditional defense contractors.
It should be expected that some, especially senior officials, will worry that open source code produced by the American defense and intelligence industrial base will benefit America’s enemies. American government-developed code has already been used against America before, so why encourage this outcome? Although some code will and ought to remain closely held, it’s worth considering that this perspective mistakes Internet access for an ability to integrate software into military and intelligence operations. Yes, open source code contracts would result in public code repositories, but it seems possible, even likely, that American government institutions are more capable of quickly identifying, adapting and integrating such code into their daily operations. The tremendous success of the FalconView geospatial software developed within the U.S. military points to this possibility.
There are also counterintelligence and cybersecurity risks. Hostile intelligence organizations could target the maintainers associated with open source code repositories, even though the rise of social media, especially LinkedIn, suggests that open source code profiles might be less of a counterintelligence threat than other existing trends. Nefarious organizations might also try to slip malicious code into open source code repositories, perpetrating a software supply chain attack. The website of the Defense Department’s chief information officer cautions against excessive worry about open source software supply chain attacks; proprietary software is also vulnerable, perhaps more so. Nevertheless, some will worry that even if security by obscurity might be the wrong strategy for cryptographic protocols, it might be appropriate for contractor-delivered code to the military and intelligence community.
Open source code contracts would be disruptive, to say the least.
To some, this change could be welcome, ushering in a new market. To others, this idea might represent “faddish” thinking, simply the manifestation of excessive enthusiasm for open source code found among some software developers and open source zealots. Viewed as an open case, open source will increasingly present itself to the military and intelligence software contracting community.
No comments:
Post a Comment