August 30, 2016

Open Source Software and the Department of Defense

By: Ben FitzGerald, Jacqueline Parziale and Peter L. Levin

Senior leaders across the defense establishment are justifiably concerned about the erosion of U.S. military technical superiority and have recently launched several high-level initiatives to ensure continued military advantage for the United States. Secretary of Defense Ashton Carter has been outspoken about the need to collaborate with, and recruit talent from, Silicon Valley and other like-minded technology hubs to increase innovation within the Department of Defense (DoD). Deputy Secretary of Defense Bob Work has been tasked by Secretary Carter to lead the development of a new approach, the third offset strategy, to extend U.S. military technical advantages. The acquisition reform efforts set forward by House Armed Services Committee (HASC) Chairman Mac Thornberry highlight similar concerns and goals.

The capabilities that underpin the United States’ current military advantage – such as global command and control; intelligence, surveillance, and reconnaissance (ISR); precision munitions; global positioning systems (GPS); and cyber capabilities – are largely based on information technologies and ultimately depend on the quality of the software upon which they are constructed. From game-changing weapons to routine back-office systems, the DoD is entirely reliant on its ability to identify, acquire, certify, deploy, and manage software.

Important Definitions
In national security circles, open source software is often confused with other “open” initiatives, which sometimes leads to misunderstanding and incorrect conclusions.

Open Source Software is defined by the Department of Defense as “software for which the human-readable source code is available for use, study, re-use, modification, enhancement, and re-distribution by the users of that software.” 1 Like nearly all software development methodologies, open source software is built collaboratively. For open source software, sometimes that collaboration is private, and sometimes it is public.

Open source software is distinct from:

Open Source Intelligence – intelligence collected from publicly available sources such as the media, social networking sites, government reports, or academia, as opposed to intelligence collected from covert or clandestine sources.

Open Architectures – hardware and software system architectures designed to make extensions, maintenance, upgrades, and component exchange easier. Open architectures enable software developers to create new features and users to easily install them.

Open Data – data that is freely available to use, reuse, and redistribute without restrictions from copyright, patents, or, sometimes, the need for privacy control mechanisms.

This challenge maps directly to the fierce competition in the commercial market for technology. Successful organizations in every sector must use all the tools at their disposal to gain advantage, especially as the pace of breakthroughs accelerates and their availability increases. In recent years, the private sector has become increasingly reliant on open source software, which underpins critical software infrastructure from enterprise applications to smartphones and advances from artificial intelligence to electric cars. But while the commercial world has installed repeatable and scalable frameworks that improve the software it uses, the DoD struggles to keep pace. Unless the Department is able to accelerate how it procures, builds, and delivers software, it will be left behind.

From massive delays in the production of new weapons systems caused by software integration issues, to major cost overruns for ordinary projects such as logistics support systems, to the seemingly unknowable cost of its total software portfolio, the DoD struggles mightily to acquire, create, and maintain its software, both open source and proprietary. Indeed, the challenges of software management led to a specific requirement in the 2013 National Defense Authorization Act that the DoD inventory its software use.

Unfortunately, software development is not currently a high-profile, high-priority topic in the discussion about diminishing U.S. military technical superiority. It should be. And one of the most effective ways the U.S. could maintain dominance and further strengthen system capability is to insist on openly architected systems – as articulated in Chairman Thornberry’s acquisition reform efforts – and to make much better use of open source software.

Software development is not currently a high-profile, high-priority topic in the discussion about diminishing U.S. military technical superiority. It should be.

Of course, the challenges of effective software management are not unique to the DoD; the entire U.S. government struggles with such investments. One way the White House is seeking to address these problems is through the increased use of open source software across all federal agencies. On August 8, 2016, the White House Chief Information Officer (CIO) released a Federal Source Code Policy that calls for new software to be built, shared, and adapted using open source methods to capitalize on code that is “secure, reliable, and effective in furthering our national objectives.” The policy requires that “new custom-developed source code developed specifically by or for the Federal Government to be made available for sharing and re-use across all Federal agencies ... [and] Federal agencies to release at least a portion of new custom-developed Federal source code to the public”

The draft policy contains a notable exemption for “source code developed for National Security Systems.” This exemption is specific. It includes systems that involve intelligence activities, cryptologic activities, command and control of military forces, and weapons, and explicitly excludes systems used for routine administrative and business applications. It would be easy for the DoD to broadly exploit these exemptions in favor of custom proprietary code, but such action would be counterproductive and unwise. The Department should instead seize this opportunity to make greater use of open source methods and more fully embrace the use of open source software. In doing so, it will gain the common mode benefits of open source platforms and methods, as well as important advantages specific to the DoD’s needs.

There are many instances in which the Department successfully uses open source software, from the platforms that power Predator drones to DARPA’s Memex, a search tool for the dark web. However, at present, the Department is failing to institutionally exploit many best practices available to ensure the optimal generation and management of its code base. While the value of open source software is important to acquisition reform and cost-efficiency goals, its most consequential contribution is to the very foundation of the nation’s military capability. The DoD must overcome bureaucratic hurdles and embrace open source software as a critical element of its efforts to maintain military technical superiority in the 21st century.

Recommendations

The cultural and bureaucratic hurdles to open source software are significant but ultimately surmountable. There is abundant evidence demonstrating that the increased use of open source software is possible, and even desirable, within the DoD. These examples can serve as a basis from which to develop institutional approaches to promote open source software and methods. The following recommendations offer direct and actionable ways in which the Department can rapidly increase its use of open source software to improve software outcomes and manage costs across the DoD’s technology infrastructure and projects.

The Department’s senior leadership must actively embrace open source software. A lack of explicit support implies tacit support for the status quo. The Under Secretary of Defense for Acquisition, Technology, and Logistics; the DoD CIO; and service acquisitions executives and CIOs should capitalize on the opportunity provided by the White House’s new open source policy, set specific goals for its integration within the Department, and interpret the national security exemption in the narrowest possible way.

In addition to agreeing to meet the goals set in the White House open source software policy, the DoD should actively seek to identify areas in which it can share its code with key interagency partners, including the Departments of State, Treasury, Justice, and Homeland Security.

The Department of Defense should adopt a policy of using widely available open source software components, tools, and platforms as a default position. Proprietary software should require special approval and only be used in instances where it delivers vital functionality not provided by open source alternatives.

The Department should establish a project or task force to develop methodologies, architectures, and repositories with which to ease the sharing and use of open source code to include the appropriate release of code via the White House’s forthcoming website Code.gov, the Defense Information Systems Agency’s code repository Forge.mil, GitHub, or agencies’ own websites.10 Such a project could build on the lessons learned by and methods generated from DoD projects such as Forge.mil and DARPA’s Memex and xDATA. The DoD should also draw on the documented experience of sister agencies such as NASA.11 The DoD could also provide itself and the technical public an irreplaceable benefit by creating an inspection and certification program that would help qualify and certify modules for reuse in other applications.

The Department of Defense should collaborate with the Departments of State and Commerce to make a formal policy statement regarding the role of open source software within ITAR and export controls, specifying what is permissible under the agreements and in what ways open source licensing can speed the transfer of code to and facilitate the codevelopment of code with U.S. allies.

The Department leadership should also examine the involvement of open source software in any future innovation and acquisition reform policies, such as in the Better Buying Power series.

Chief technology officers and vice presidents for strategy in the defense industry should explore methods by which they can benefit from increased use of open source software. The DoD’s industry partners stand to derive similar benefits as the Department itself. For businesses that develop significant quantities of custom code, open source offers important tools to maintain competitive advantage. This is particularly critical as the defense industry is forced to address long-term declines in global defense spending.

Misconceptions about the Security of Open Source Software
Discussion of open source software in national security is often dismissed out of hand because of technical security concerns. These are unfounded. To debunk a few myths:
  • • Using open source licensing does not mean that changes to the source code must be shared publicly.
  • • The ability to see source code is not the same as the ability to modify deployed software in production.
  • • Using open source components is not equivalent to creating an entire system that is itself open sourced.

    As In-Q-Tel’s Chief Information Security Officer Dan Geer explains, security is “the absence of unmitigatable surprise.”23 It is particularly difficult to mitigate surprise with closed proprietary software, because the source code, and therefore the ability to identify and address its vulnerabilities, is hidden. “Security through obscurity” is not an effective defense against today’s cybersecurity threats.In this context, open source software can generate better security outcomes than proprietary alternatives. Conventional anti-malware scanning and intrusion detection are inadequate for many reasons, including their “focus on known vulnerabilities” that miss unknown threats, such as zero-day exploits. As an example, a DARPA-funded team built a flight controller for small quadcopter drones based on an open source autopilot readily downloaded from the Internet. A red team “found no security flaws in six weeks with full access [to the] source code,” making their UAV the most secure on the planet.24

Costs of Inaction

The DoD’s quest to maintain its technological superiority rests in large part on its ability to acquire, develop, deploy, and maintain cutting-edge software systems. Global C4ISR networks, precision munitions, drones, and combat aircraft are only as valuable as the data and software that power them. The martial importance of software will only increase as the Department seeks to simultaneously leverage and protect against cyber attacks, big data, artificial intelligence, and robotics in the years to come.

High quality software is also essential to the healthy function of the DoD enterprise, from accounting software to personnel records. In an era of budget uncertainty and decline, as well as ever-growing costs, the DoD needs software systems that manage its bureaucracy efficiently and enable the analyses necessary to develop elegant solutions to intractable management and fiscal challenges.

Despite these pressing needs, the DoD is manifestly not utilizing all the resources and methods available to ensure optimal software outcomes. Open source cannot cure all of the DoD’s software ills. However, it does possess the potential to substantially improve software outcomes for the DoD in the same way it has for civilian organizations around the world, and at a lower total cost than the proprietary and closed systems the Department currently uses. Additionally, open source methods provide benefits uniquely suited to the DoD’s organizational and technical needs.

In the absence of strong, sustained leadership from senior personnel in support of open source software and methods, the DoD will continue to experience unacceptable waste, pointless expense, delayed time lines, and sub-optimal outcomes from its software investments. This path guarantees a slow decline and diminution of U.S. military technical advantage – with the added possibility of periodic catastrophic failures. The U.S. military does not deserve, and cannot afford, such a future.

The full report is available online.

Download PDF

  1. Department of Defense Chief Information Officer, “What is open source software (OSS)?” http://dodcio.defense.gov/OpenSourceSoftwareFAQ.aspx#Q:_What_is_open_source_software_.28OSS.29.3F. ↩
  2. Bob Work, “Deputy Secretary of Defense Speech” (CNAS Defense Forum, Washington, December 14, 2015), http://www.defense.gov/News/Speeches/Speech-View/Article/634214/cnas-defense-forum. ↩
  3. Kristina Wong, “Armed Services chair to propose new defense acquisition reforms,” The Hill, March 15, 2016, http://thehill.com/policy/defense/273006-armed-services-committee-chair-to-propose-new-defense-acquisition-reforms. ↩
  4. Brendan McGarry, “Experts to Study F-35 Software Delays,” Defense Tech, December 26, 2013, http://www.defensetech.org/2013/12/26/experts-to-study-f-35-software-delays/; and Chris Kanaracus, “Watchdog Agency Report Shows Beleaguered State of U.S. Military Software Projects,” PC World, April 2, 2012, http://www.pcworld.com/article/253038/watchdog_agency_report_shows_beleaguered_state_of_us_military_software_projects.html. ↩
  5. Steve Schmidt, “Budget Cuts Even Congress Can Agree On: Software License Optimization,” Breaking Gov, August 14, 2012, http://breakinggov.com/2012/08/14/budget-cuts-even-congress-can-agree-on-software-license-optimiz/. ↩
  6. Tony Scott, “Leveraging American Ingenuity through Reusable and Open Source Software,” the White House Blog, March 10, 2016, https://www.whitehouse.gov/blog/2016/03/09/leveraging-american-ingenuity-through-reusable-and-open-source-software. White House Chief Information Officer, “Federal Source Code Policy,” https://sourcecode.cio.gov/. ↩
  7. Tony Scott, “The People’s Code,” the White House Blog, August 8, 2016, https://www.whitehouse.gov/blog/2016/08/08/peoples-code. ↩
  8. White House Chief Information Officer, “Federal Source Code Policy,” https://sourcecode.cio.gov/. ↩
  9. 44 U.S.C. § 3542, “Definitions.” https://www.law.cornell.edu/us... ↩
  10. “March 2016 Web Server Survey,” Netcraft, http://news.netcraft.com/archives/category/web-server-survey/. ↩
  11. “Smartphone OS Market Share, 2015 Q2,” IDC Research, http://www.idc.com/prodserv/smartphone-os-market-share.jsp; and Steven J. Vaughan-Nichols, “Debunking four myths about Android, Google, and open-source,” Linux and Open Source blog on ZDNet, February 18, 2014, http://www.zdnet.com/article/debunking-four-myths-about-android-google-and-open-source/. ↩
  12. “75% of top 10k websites served by open source software,” Tech Blog on pingdom.com, May 22, 2012, http://royal.pingdom.com/2012/05/22/75-percent-top-10k-websites-served-by-open-source-software/. ↩
  13. Steven J. Vaughan-Nichols, “It’s an open-source world: 78 percent of companies run open-source software,” ZDNet, April 16, 2015, http://www.zdnet.com/article/its-an-open-source-world-78-percent-of-companies-run-open-source-software/. ↩
  14. Steve Lohr, “Some I.B.M. Software Tools to Be Put in Public Domain,” The New York Times, November 5, 2001, http://www.nytimes.com/2001/11/05/technology/05OPEN.html. ↩
  15. Peter Levine, “Why There Will Never Be Another RedHat: The Economics Of Open Source,” TechCrunch, February 13, 2014, http://techcrunch.com/2014/02/13/please-dont-tell-me-you-want-to-be-the-next-red-hat/. ↩
  16. Herb Caudill, “The Revolution will not be Open Source,” DevResults Blog, January 20, 2016, http://blog.devresults.com/the-revolution-will-not-be-open-source/. ↩
  17. Stephen Sanzo, “Snappy Comebacks to Your Boss’s Open Source Software Objections,” Isovera Blog, February 2011, https://www.isovera.com/blog/snappy-comebacks-your-boss%E2%80%99s-open-source-software-objections. ↩
  18. Deborah Gage, “GitHub Raises $250 Million at $2 Billion Valuation,” The Wall Street Journal, July 29, 2015, http://www.wsj.com/articles/github-raises-250-million-at-2-billion-valuation-1438206722. ↩
  19. Cade Metz, “Open Source Software Went Nuclear This Year,” Wired, December 27, 2015, http://www.wired.com/2015/12/2015-the-year-that-open-source-software-went-nuclear/; Cade Metz, “Google Just Open Sourced TensorFlow, Its Artificial Intelligence Engine,” Wired, November 9, 2015, http://www.wired.com/2015/11/google-open-sources-its-artificial-intelligence-engine/; and Elon Musk, “All Our Patent Are Belong to You,” Tesla Blog, June 12, 2014, https://www.teslamotors.com/blog/all-our-patent-are-belong-you. ↩
  20. Steven Melendez, “How Facebook’s Massive Open-Source Push Delivers Better Code and Better Engineers,” Fast Company, January 26, 2015, http://www.fastcompany.com/3038842/how-facebooks-massive-open-source-push-delivers-better-code-and-better-engineers. ↩
  21. David A. Wheeler, “Open Source Software (OSS) and Total Cost of Ownership (TCO)” (Slides prepared for Government Open Source Conference 2011), http://www.dwheeler.com/essays/oss-tco-wheeler.pdf. ↩
  22. Jesús Gil Hernández, “Diseconomies of Scale in Software Development,” Management and Leadership Notes Blog, February 17, 2013, http://jesusgilhernandez.com/2013/02/17/diseconomies-of-scale-in-software-development/. ↩
  23. Daniel E. Geer, Jr., “Cybersecurity and National Policy,” Harvard Law School National Security Journal, January 10, 2011, http://harvardnsj.org/2011/01/cybersecurity-and-national-policy/. ↩
  24. Kathleen Fisher, “Using Formal Methods to Secure More Vehicles DARPA’s HACMS Program,” 19th Association for Computing Machinery Special Interest Group on Programming Languages International Conference, August 2014, https://www.researchgate.net/publication/269206322_Using_Formal_Methods_to_Enable_More_Secure_Vehicles_DARPA’s_HACMS_Program. ↩

Authors

  • Ben FitzGerald

    Former Adjunct Senior Fellow, Defense Program

    Ben FitzGerald is a partner at Lupa, a private investment firm, and a former adjunct senior fellow at the Center for a New American Security (CNAS). At Lupa he leads the firm’...

  • Jacqueline Parziale

  • Peter L. Levin

More from CNAS

View All Reports View All Articles & Multimedia