Skip to main content

OpenSSF Supports White House’s Efforts to Build More Secure and Measurable Software

By February 26, 2024February 27th, 2024Blog

By Dana Wang, Chief Architect, OpenSSF and Omkhar Arasaratnam, General Manager, OpenSSF

The US Office of the National Cyber Director (ONCD) report Back to the Building Blocks: A Path Toward Secure and Measurable Software, was released today. The report provides valuable insights into strategies to improve software security. This paper emphasizes the importance of proactive measures in mitigating vulnerabilities by examining pivotal principles such as memory safety, measurements, and metrics to help enhance software security. The OpenSSF supports efforts like this from the public sector, which improve the security of open source software.

Reducing Surface Area for Security Breaches

One of the principles highlighted in the paper is the imperative of reducing the surface area for potential security breaches. For example, software can be designed to systematically reduce vulnerabilities from memory safety issues. A comprehensive study conducted by Microsoft in 2019 revealed that over 70% of vulnerabilities designated with a CVE were attributable to memory safety issues, underscoring the critical nature of this issue. 

Adopting Memory Safe Programming Languages

The OpenSSF advocates adopting memory safe programming languages, such as Rust, to address the inherent fragility of traditional languages like C and C++ when it comes to memory management. By using memory safe languages, software developers can significantly reduce the risk of vulnerabilities associated with memory safety when developing a brand new project or new components. 

Large scale adoption of memory safe languages is non-trivial. For example, rewriting all the existing C and C++ code is neither economically feasible nor practical, as we mentioned in our response to ONCD’s Request For Information (RFI) on Open-Source Software Security and Memory Safe Programming Languages in 2023. Refactoring from one language to another often introduces new bugs, and the complexities of rewriting source code is just the beginning. After rewriting, deploying the latest software, especially in embedded systems such as those in our critical infrastructure, can be even more complicated, putting critical systems at risk.

OpenSSF recommends taking a risk-based approach towards refactoring the most critical components. OpenSSF has developed the Compiler Options Hardening Guide for C and C++ to help guide developers who can’t easily migrate to memory safe languages.  

Alpha-Omega has funded Prossimo to advance the functionality and performance of the Rustls TLS library and Rust for Linux. Implementing TLS using a memory safe language can avoid critical security issues like the infamous OpenSSL vulnerability Heartbleed. Having Rust as the second supported language for Linux kernel development will allow Kernel contributors to reduce the likelihood of memory safety vulnerabilities within Linux.

Exploring Hardware-Based Approaches

The paper explores the potential efficacy of hardware-based approaches to bolster memory safety. Examples include Instruction Set Architecture (ISA) extensions like Memory Protection Extensions (MPX), Memory Tagging Extension (MTE), and Capability Hardware Enhanced RISC Instructions (CHERI), which complement older hardware methods backed such as enforcing “No eXecute” (NX) attributes on page table entries. These hardware-backed approaches to memory safety have utility in scenarios where newer languages like Rust may have a different breadth of ISA support or shorter history in safety-critical applications, such as critical infrastructure or hard real-time systems, than more established languages like C or C++. 

Analyzing the Security of Software

The paper also addresses the inherent challenges of analyzing software quality through formal methods, static and, dynamic analysis of a codebase. Cryptographic functions are some of the most sensitive code paths in any software. Formal methods have often been applied to cryptographic functions to ensure their robustness. Formal methods allow mathematical proof that the software under evaluation will always securely conduct itself through a thorough analysis of the state machine. While formal methods are excellent at evaluating the security of a very constrained set of functions like cryptography or safety critical code paths, they become unwieldy when analyzing general software functionality. Conversely, static and dynamic analysis, which are more suitable for analyzing general software functionality, may not always consider all state machine conditions or code paths in the analyzed software. 

While excellent progress has been made in recent advancements, we believe initiatives such as the Defense Advanced Research Projects Agency (DARPA) AI Cyber Challenge (AIxCC) will provide revolutionary improvements in the coming years.

Metrics and Measurement

In alignment with our core principles, OpenSSF emphasizes metrics and measurements to empower open source consumers with the requisite information to inform dependency selection. In many ways, open source software is a public good – like water. As organizations consume this public good, it is their accountability to ensure the safety of their “upstream” producers and that their “downstream” products remain safe for consumption. We believe that metrics and measurements can provide an objective means to make safety and security decisions about open source software.

OpenSSF projects such as the Best Practices Badge Program, Scorecard, and GUAC facilitate the measurement and inference of the quality of open source dependencies. At the same time, Allstar enforces security control policies in software repositories. Additionally, the RSTUF project enhances repository resilience against compromise, while sigstore provides cryptographically verifiable proof to validate software provenance.

Advancing Software Security

The paper is an excellent step in advancing software security. Addressing critical issues such as memory safety and advocating for robust measurement practices contributes to the collective pursuit of strong security standards. We agree with the report’s call for further scientific research in measurements and metrics. 

Commercial companies consuming water must monitor their upstream sources and downstream quality using well-known metrics and measurements. We need to be more mature regarding metrics and measurement within security. We applaud ONCD for highlighting an opportunity to research this topic further. We envision a future where software companies will have a standard set of metrics and measures to monitor the security properties of the open source they’re consuming and the security quality of their products. We look forward to leading that journey.

Join Us at OpenSSF

Interested individuals passionate about tackling such challenges are encouraged to join the OpenSSF community and contribute to the advancement of software security. We invite you to join us if you want to work on challenging problems such as memory safety and the metrics and measurement of security properties. Furthermore, you can find us on the road in April at SOSS Community Day North America in Seattle. In October, we’ll be hosting the first-ever SOSS Fusion Conference in Atlanta, and we are now accepting submissions to speak.

This post represents the views of the authors & does not necessarily reflect those of all OpenSSF members.