On Sept. 22, 2022, U.S. Senators Gary Peters (D-MI) and Rob Portman (R-OH) introduced bipartisan legislation to strengthen open source software security: the Securing Open Source Software Act.
If enacted, the legislation would instruct the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to develop a framework for assessing the risk of open source components used by federal agencies. It would also amend the Homeland Security Act of 2002 to formally recognize open source software as part of the nation’s critical infrastructure.
The proposed bill has its roots in the Log4j vulnerability (also known as “Log4Shell”), which caused widespread and significant damage, including to federal systems and critical infrastructure. Although the private sector has steadily increased interest and funding for open source security efforts, Log4j served as a wake-up call of sorts for the federal government.
The Securing Open Source Software Act aims to guard against Log4Shell-like incidents by mitigating risk in systems that use open source and strengthening collaboration between the government and open source communities.
“As we saw with the Log4Shell vulnerability, the computers, phones, and websites we all use every day contain open source software that is vulnerable to cyberattack,” Senator Portman said in a statement announcing the legislation. “The bipartisan Securing Open Source Software Act will ensure that the U.S. government anticipates and mitigates security vulnerabilities in open source software to protect Americans’ most sensitive data.”
Key Provisions in the Securing Open Source Software Act
The proposed legislation includes several new requirements for CISA, the U.S. government’s Cybersecurity and Infrastructure Security Agency. It extends the agency’s current responsibilities to supporting the secure usage and deployment of software, including open source software throughout the software development lifecycle at federal agencies.
These updated duties include:
- Establishing a framework for assessing the risk of open source components; the framework should incorporate best practices from government bodies, private industry, and open source communities
- Coordinating with federal agencies to bolster open source software security
- Serving as a public point of contact regarding open source software security for state, local, and private entities
- Assisting with coordinated vulnerability disclosures for open source software
- Employing individuals with open source expertise and experience
As you might expect, specific elements of the open source risk assessment framework have not been finalized. But, at minimum, the proposed law directs CISA to consider the following factors:
- The security properties of code
- The security practices of code development and deployment
- The number and nature of vulnerabilities in an open source software component
- The breadth of deployment of an open source software component
- The level of risk associated with each open source software component
- The health of the community around each open source software component.
CISA would then use this framework to conduct an assessment of all open source software in use at federal agencies.
Duties and Timelines for Federal Agencies
The Securing Open Source Software Act includes a timeline for CISA to complete the required activities. Key dates are as follows:
- Within one year: Develop and publicly publish the risk assessment framework
- Annually: Update the framework as needed
- Within one year of the publishing date of the framework, and every two years thereafter: Conduct an assessment of open source software components used by federal agencies; the assessment should be based on information such as software bill of materials (SBOMs), software inventories obtained through the CISA, and publicly available information.
- Within one year of the enactment of the legislation, and every two years thereafter: Submit a report to congressional committees regarding their activities on open source software, including the framework and assessments developed under the legislation
Responsibilities for Other Departments
While CISA is tasked with leading most of the activities in the proposed legislation, several other agencies will also pick up additional responsibilities.
For example, the bill would instruct the Director of the Office of Management and Budget (OMB) to issue guidance for CIOs at covered federal agencies (major executive departments such as the Department of Commerce and Department of Defense) regarding the use of open source software. This guidance includes best practices for open source software usage, how to minimize the risks around open source software, and how to contribute to open source projects.
Additionally, the CIO of each covered agency would be directed to establish a pilot open source program office of sorts. These OSPO-type functions would develop policies and processes around using open source, releasing open source, and collaborating with the broader open source community.
What the Securing Open Source Software Act Means for Private Entities
Although the proposed legislation would only directly impact federal agencies, it would still be relevant to the private sector. This is the case for many of the same reasons that the mid-September 2022 self-attestation memo and the 2021 cybersecurity executive order impacted private enterprises.
For one, many of these new and proposed regulations require organizations to provide a software bill of materials (and/or similar software inventory) when selling into the federal government.
Additionally, regulatory action on SBOMs and software transparency are trickling down to the private sector — we’re seeing more and more businesses require SBOM-type documentation as part of the procurement process.
In other words, the public and private sectors are continuing to prioritize software supply chain security. And, this puts a premium on capabilities like SBOM generation, understanding the direct and transitive dependencies in your software, and having effective vulnerability management programs.
Software composition analysis tools like FOSSA play an important role in managing these processes. FOSSA provides a comprehensive inventory of your software dependencies and automates vulnerability management and SBOM creation. For more information on getting started with FOSSA, please reach out to our team.
