Open-source software is a collective partnership across the development community that requires both private and public buy-in. However, securing open-source software can be tricky. With so many different people working on the coding, security measures are often overlooked, increasing the chances that a vulnerability will fall through the cracks and be exploited. The Open-Source Software Security Initiative (OS31) aims to provide governance over open-source security processes.

After the Log4Shell vulnerability, securing open-source software became a top priority for the federal government. The goals of this new initiative are:

• Unifying the federal government’s voice on open-source software security
• Establishing a strategic approach for the federal government’s secure use of open-source software and the broader ecosystem
• Encouraging long-term sustained security investment in the open-source software ecosystem
• Engaging and building trust with the open-source software community

Shortly after OS31 was released, various government agencies, including the Office of the National Cyber Director (ONCD) and the Cybersecurity Infrastructure Security Agency (CISA) put out a request for information (RFI) to “invite public comments on areas of long-term focus and prioritization on open-source software security.”

The White House released a summary of the RFI in August 2024. The result offers a broad list of suggestions of areas the respondents want to see prioritized to improve security across the open-source software ecosystem. Here are the top three.

1. Secure open-source software foundations

It appears that one of the top priorities for respondents is setting standards to secure the foundations on which open-source software is built. Securing legacy systems, for example, has long been problematic for developers and IT staff, so it isn’t surprising that the respondents highlighted the need for OS31 to address the security issues that are found in legacy code. One such suggestion around this was to automate “legacy code translation into memory-safe code [which] would create a more secure open-source software ecosystem.”

Securing the open-source software infrastructure is also important to respondents, particularly having a government-dictated set of best practices of package repositories to ensure sustained security improvements. Other suggestions covered the standardization of software bill of materials (SBOMs) as the “bedrock requirement” and having processes in place to use tools designed to create SBOMs during the build process.

The quality of open-source software is critical, especially as it is used across the software supply chain. Both the public and private sectors recognize that a strong foundation for open-source software security is a must to prevent situations like Log4Shell, and the responses in the RFI offer a clear vision of what developers see as needed to create the necessary open-source security framework.

2. Sustaining open-source software communities and governance

Respondents make it clear that they want the federal government to take the lead in the governance of open-source software communities. They want to see open-source move beyond individual volunteer maintenance to a shared responsibility model, stating that this support for the open-source ecosystem is the best way to sustain and secure projects.

Within the open-source community, there is a call for professional training opportunities and maybe even paying independent open-source developers that could lead to more sustainable and consistent coding models. Some respondents called for even greater oversight through a federal Open-Source Program Office (OSPO). According to GitHub, an OSPO manages an organization’s open-source operation and “is responsible for defining and implementing strategies and policies.” RFI respondents believe a federal OSPO would bring continuity of policies across the entire ecosystem.

3. Behavioral and economic incentives to secure the open-source software ecosystem

Following up on the desire to offer pay to independent developers, respondents want to go a step further and have the federal government add legal protections and governance structures, especially for software used in critical infrastructure. Funding and oversight for open-source projects should include identifying and remedying vulnerabilities found in the software.

The logical next step would be a new NIST framework, a Responsible Open-Source Software Consumption Framework, that could stand alone or be included in NIST’s existing Secure Software Development Framework.

Moving forward with securing open-source software

Now that the RFI is complete, the next step is to move forward with plans to improve the security of all technologies used by the federal government. OS31’s action items will include advanced research and development around open-source software security and addressing RFI suggestions such as secure package repositories, more development of SBOMs and building a partnership with open-source communities.