Earlier this month, the White House Office of National Cyber Director (ONCD) released its summary report on the Request for Information (RFI): Open-Source Software Security: Areas of Long-Term Focus and Prioritization, effectively checking off another box on the commitments the Administration made in the National Cybersecurity Strategy. As with prior reports, it’s a consolidation of submissions received, combined with a laundry list of Administration initiatives – of various degrees of implementation and public awareness – and eschews concrete policy recommendations.

The ONCD received 107 comments that it made public. Inevitably, condensing those comments down to 20 pages is a challenge. Below is my take on the report: the good, the not so good, and the puzzling.

I particularly commend the ONCD for recognizing that commenters “emphasized the need to secure open-source software infrastructure, such as package repositories used to distribute open-source software packages to developers.” For some time, it has been recognized that these repositories – also referred to as warehouses – have been a key weak link in the open source software ecosystem. 

The Atlantic Council, among others, documented in their studies on software supply chain attacks that these distribution repositories – more so than the “upstream communities” – are a major focal point of those looking to introduce vulnerabilities. The most notable ones include, for example, the Python Package Index for python software, RubyGems for Ruby software, NPM for Modem, and crates.io for Rust. 

For too long, many of the packages and much of the community code found in repositories have been unsigned and have little information on their provenance, making it challenging to validate that the software found there is authentic, intended for use by the maintainer, legitimate, or safe to use, either as in stand alone or incorporated into a product. 

The good news is that the Cybersecurity Infrastructure and Security Agency (CISA) is emphasizing its work here. This includes, in partnership with the OpenSSF Securing Software Repositories Working Group released in February, the Principles for Package Repository Security framework. It establishes a voluntary security maturity model for package repositories, including actions such as requiring multi-factor authentication for packages. 

At the CISA Open Source Software Security Summit this Spring, the agency announced actions that five of the most widely used package repositories are taking in line with the framework to secure entire ecosystems. Continued focus on this area of demonstrable risk and essential improvement will be critical to our nation’s cyber hygiene. Enhanced efforts are needed earlier in the process to ensure packages can be validated, such as through the default use of cryptographic signatures to validate authenticity, to suppress the ability to publish malicious packages to those repositories. 

By contrast, there is the report’s treatment of comments on moving to memory safe languages. Certainly, there was “widespread support for the use of memory-safe programming languages, particularly when developing new software projects.” But the report’s head nod that “respondents’ preferences on how to encourage the use of memory-safe languages were more varied” fails to capture the breadth of the complexity of the topic.

The Cybersecurity Coalition in its submission, articulated the point succinctly:

“We recognize the benefit of using memory safe programming languages and are supportive of encouraging use of this technology, but mandating the rewriting of code for existing products is complex and must be considered carefully. The digital ecosystem currently relies on trillions lines of code that have not yet been converted into memory safe languages, and we will continue to rely on using both languages to update legacy code, and for interoperability with new. Focusing this initiative on new and emerging products, and providing safe harbor for legacy code, will help mitigate the challenges associated with rewriting memory unsafe language while moving the industry in the desired direction.”

As several commenters noted, the majority of programming languages in use today are technically memory safe. Memory safe languages such as Go, Rust, Python and Java have gained – and will continue to gain – popularity. The central challenge, at risk of boiling it down to its simplicity, is the software written in C, C++, and Assembly.

The vast majority of commenters pointed out that memory safe languages are not a silver bullet. As the National Security Agency (NSA) concluded in its review of memory safe languages, “[e]ven with a memory safe language, memory management is not entirely memory safe. Most memory safe languages recognize that software sometimes needs to perform an unsafe memory management function to accomplish certain tasks.” Moreover, use of a memory safe language does not protect against other vulnerabilities, such as injection flaws, authentication or authorization flaws, among others, that are not memory-related and could be as, if not more, damaging. 

A push to rewrite existing code in memory safe languages will be costly, as many pointed out. But the cost is not just in terms of development financial and human resources. The cost will also be in security risks, both known and unknown. Much of the open source software deemed critical has existed for sufficient time to allow for audits and reviews that, generally speaking, have sufficiently hardened it against a number of vulnerabilities. 

The challenge is that issues often arise with older open source projects and when the code is incorporated into products, services and use cases that may not have been anticipated by the “upstream” developer community. But it is unwise to assume that the answer lies inherently in rewriting new and unscrutinized code that, while perhaps not containing memory-related vulnerabilities, could very well create other vulnerabilities not present in the existing code. 

The fact is that there are growing uses of memory safe languages in development communities, a major step forward in good programming practices. However, it is of no value when hastily implemented by developers lacking the proper training and experience to develop quality software. An experienced and security-focused C++ developer is more likely to produce code of greater efficiency and execution security than an inexperienced Rust developer. It is useful to encourage the use of memory safety in new projects or software where the benefit and risk of newly-written code is better recognized.

In many cases, rather than rewriting existing software in a memory safe language, the disciplined implementation of quality assurance and security testing throughout the development process - including static and dynamic code analysis - will in all likelihood return significantly more value. 

And that leads to my final take on the report, one that puzzles me. The strength of the Administration’s cybersecurity approach is built on the foundations of promoting universal policies like the NIST Secure Software Development Framework (SSDF), a well recognized approach that embodies an excellent set of fundamental, sound and secure software development practices based on established secure software development practice. 

It also advocates widespread use of NIST Guidance on Software Security in Supply Chains as well as adherence to the Cyber Security Framework 2.0. As reflected in the Cyber EO, these are widely recognized and respected software development and management practices that build trust and security if utilized effectively – regardless of development model. A large number of comments made this point.

But there is only one mention of SSDF, and it’s in a very niche context. None of the core tenets of Administration policy are mentioned in the summary of key actions that conclude the report. Yet, even as efforts are made to improve the hygiene of upstream open source software, it is incumbent on any user of open source software – whether a software publisher, cloud service provider or a “DIY” enterprise organization – to engage in secure software development and management practices to help reduce the risk of vulnerabilities in their software, reduce the potential impact of the exploitation of undetected or unaddressed vulnerabilities, and address the root causes of vulnerabilities to prevent recurrences. 

It is important, in my view, to see this report in the context of the latest intense U.S. government focus on open source software – indeed, an episode in the more than 25 year history with it – that was prompted by the notorious Log4j episode. Since the January 2023 White Summit, the Administration has undertaken a number of initiatives touching on open source software: the list of actions taken in the report is detailed. 

Last week, ONCD Director Harry Coker also announced an $11 million initiative – to be funded via the 2021 Bipartisan Infrastructure Law – to gain an understanding of how open source software is used across critical infrastructure and get a handle on the distribution of open-source software components in areas like healthcare, transportation and energy production, eventually allowing the federal government and private sector partners to strengthen national cybersecurity. 

Strikingly, at the same time, the Administration recognizes the broader picture: “We don’t have a cybersecurity problem. We have a software quality problem,” said CISA Director Jen Easterly. That makes more sense. As the Cyber Coalition wrote in its comments last year, the “ONCD should approach this in a holistic manner consistent with the National Cyber Strategy. All software can contain vulnerabilities and be exploited, therefore the focus should be on encouraging secure build environments, secure architectures, and zero trust strategies to help make all critical software more resilient.” 

Mark Bohannon is a Cybersecurity Fellow with the Center for Cybersecurity Policy and Law.