The U.S. Department of Defence CIO urged the Department to prefer open source over proprietary solutions.
On 24 January 2022, the U.S. Department of Defence (DoD) Chief Information Officer John Sherman released internally (and published two days later) a Memorandum for the Senior Pentagon Leadership, the Commandant of the Coast Guard, the Commanders of the Combatant Commands, the Defence Agency and the DoD Field Activity Directors. Particularly, it provides the Department of Defence with new guidelines on software development and open source software, addressing the opportunities and challenges that open source can represent for the public sector, and how the latter should interact in this regard.
Such a memorandum needs to be interpreted in light of the new DoD Software Modernisation Strategy, recently announced on 8 February by Danielle Metz, Deputy CIO for Information Enterprise and Jason Weiss, DoD Chief Software Officer. The new Strategy indeed underscores the need for the public sector to be provided with innovative, secure and resilient software, and “acknowledges that the ability to quickly deliver the resilient software at the speed of relevance, whether through reuse, acquisition or custom development, must also become prevalent”. In this context, the new memorandum runs alongside the Strategy as it states that open source software “forms the bedrock of the software-defined world and is critical in delivering software faster”, and calls the Department to clearly define “how, where, and when it participates, contributes, and interacts with the broader OSS community”.
Specifically, the new guidelines on software development and open source software attached to the memorandum first and foremost require the Department to follow an "adopt, buy, create" approach when procuring software solutions, preferentially adopting existing government or open source software solutions before turning to proprietary systems, and only creating new non-commercial software when there are no other off-the-shelf solutions available or fit for purpose.
Additionally, the guidelines lay out the main challenges connected with the use of open source software, and the governance model to cope with such issues. If program managers are in charge of the suitability of off-she-shelf components and open source software, they have to seek for guidance from support engineers, authorising officials, and the agency CIOs when faced with new challenges, which mostly gravitate around potential supply chain risks and key innovation unlawful disclosure. In both cases, what is crucial is the establishment of both a careful supply chain risk management (SCRM) approach for open source to detect cyber threats as well as a modular, open-systems approach (MOSA) that protects innovative components as separate modules.
Overall, the main sources of threat and security-related challenges for the public sector regarding open source software are listed (and potentially solved) as follows:
- Long-term support of the software: the health assessment of open source projects has to go through a risk factors analysis that scans the stability and the activity status of the software, to ensure that the project is up and running and has a community behind for audits and updates;
- Trusted sources: the trustworthiness of the source of a code should always be verified. A rigorous software assurance approach, alongside dynamic code analyses and penetration testing after integration of the updated versions, will help program managers to assess who is behind a code. In this, the guidelines require to keep a high preference for consortiums or commercial entities rather than an untrusted individual;
- Dependencies: software is often dependent on subcomponents, (e.g. plug-ins, libraries, extensions, etc.). Program managers should thus perform assessments of such subcomponent dependencies when considering the security risks linked to the software main components, as well as evaluate any legal issues regarding such subcomponents licences;
- Component Security: open source software is claimed to be more secure in such guidelines, for it provides program managers with an open development process that can better assess security risks compared to a closed one. There are several tools available in an open source software project to run security checks, ranging from transparent reporting of security vulnerabilities, to history of security reviews and timely vulnerability remediation, as well as cyber testing (e.g. third-party audits, tests, etc.) and problems-addressed;
- Component Integrity: considering the importance of software integrity for open source systems, since they “are more subject to the creation and distribution of modified, possibly-untrusted versions, given the availability of source code”, the guidelines recommend the program managers to actively maintain cryptographically-protected integrity verification for released code, scripts, configuration files, and associated documentation to reduce security risks;
- Influence of Foreign Governments: a general risk with software is represented by those suppliers of information technology and services who have information obligations to foreign governments and foreign law enforcement agencies. In this, the guidelines recognise that open source guarantees an exemption from such risks, even though program managers should still be aware of potential infiltration on open source projects by foreign governments.
This is not the first effort that the Department of Defence takes in favour of open source software. Since 2017, DoD has been publishing open source projects through the initiative Code.mil, which strives to enhance open collaboration with the developer community around the world on DoD open source projects. More information available on GitHub.