US Army Should Red-Team Open Source Code


The US military regularly engages in red team— looking for weaknesses in its war plans — playing its own members as adversaries. Software security researchers also form a red team, using the same adversary mindset to perform penetration testing and to find and fix software flaws.

Unfortunately, there is one aspect of modern US military operations that has so far escaped this devil’s advocate approach: the open source software that underpins military missions.

The secret of all modern software is that it is most open-source, meaning code created by enthusiasts (and companies) around the world and released for anyone to study and use. Whether it’s your iPhone app, military mission planning software, spy plane computerWhere big data analysis toolit is open source software all the way.

Building applications with open source components reduces time and costs. And by exposing its source code, open source software invites the world to find and even fix the inevitable bugs. But open source software, like all software, has security flaws. Almost a decade ago, the Heartbleed The OpenSSL bug exposed information such as credit card details for almost all web users. More recently, the log4j allows attackers to easily take control of affected computers, ranging from Minecraft servers to software from Apple and Amazon.

It is also true that malicious actors can and do tamper with open source software. Only known cases of open source software supply chain compromise number in the thousands.

Fortunately, the army’s red team instinct can help reduce the threat. First, the US military should undertake a software census to understand the open source software components embedded in the software it uses. A good model is a recent Harvard University-Linux Foundation analysis for legal persons.

Second, the military should redeploy the open source software components on which it has become dependent. The military could fund organizations like the Open Source Technology Improvement Fund who have a history of exactly this type of work. Additionally, the military could assign its own personnel to help with this task, building the software security skills of its own members. The military might even directly help the Open Source Security Foundation with a fledgling related initiative called Alpha-Omega. Alternately, open source software bug bountiespaid for by the military, could inspire security researchers around the world to find and report bugs.

Third, identified security bugs should be patched and fixed quickly. Military members with software expertise can provide bug fixes directly to maintainers of open source software. The military could also directly fund third parties or maintainers to fix bugs. At the very least, security vulnerabilities should be quietly reported to the open source software projects concerned.

Fourth, rinse and repeat. The open source software the military depends on will change. Moreover, open source software projects are constantly evolving, fixing some bugs and inevitably introducing new bugs as well. These facts mean that this whole process must be repeated periodically.

In the wake of log4j, the open source software vulnerability that led one observer to state that “internet is on fire“, the Open Source Security Foundation recently offers red-teaming 200 large open source projects per year at a cost of approximately $40 million per year. For the military, it’s budget dust. In short, the military could reduce security vulnerabilities lurking in its software, improve overall software security for all Americans and humanity, and increase the likelihood of mission success, all with an investment in the open source software red team.

The army tries never to go into battle without putting their plan into red team. It’s time to apply this same technique to open source software.

John Speed ​​Meyers is a Safety Scientist at chain guard. Zack Newman is a software engineer at Chainguard. Jacobo McGuire is a summer policy research intern at Chainguard.


Comments are closed.