The United States Securing Open Source Software Act: What You Need to Know 

By Mike Dolan, Cailean Osborne, and David A. Wheeler, with contributions from Ashwin Ramaswami

“Open source software (OSS) is the bedrock of the digital world and the Log4j vulnerability demonstrated just how much we rely on it. This commonsense, bipartisan legislation will help secure OSS and further fortify our cybersecurity defenses against cybercriminals and foreign adversaries who launch incessant attacks on networks across the nation.”

– Senator Gary Peters (D-MI), Chair, Senate Homeland Security and Governmental Affairs Committee

What is the Securing Open Source Software Act about?

On 21^st September 2022, U.S. Senators Gary Peters (D-MI) and Rob Portman (R-OH), Chairman and Ranking Member of the Senate Homeland Security and Governmental Affairs Committee, introduced bipartisan legislation, the Securing Open Source Software Act (the “Act”), to help protect federal agencies and critical infrastructure systems by strengthening the security of software.

What is the rationale behind this Act?

The Securing Open Source Software Act is in response to the Log4Shell vulnerability discovered in late November 2021. A subsequent hearing on Log4Shell discussed key findings and learnings, which focused on the practical challenges of security that apply to all software, not just open source.

In a written statement at the hearing, Senator Peters, Chair of the Senate Homeland Security and Governmental Affairs Committee, wrote that the Log4Shell “incident presented a serious threat to federal systems and critical infrastructure companies — including banks, hospitals, and utilities — that Americans rely on each and every day for essential services.” In July 2022, the federal Cyber Safety Review Board called Log4Shell “endemic” and said it would pose a danger for decades.

What will the legislation do?

Open Source Focus for CISA

As introduced, the bill would give new responsibilities to the Cybersecurity and Infrastructure Security Agency (CISA), the federal agency responsible for strengthening cybersecurity and infrastructure protection. The legislation requires CISA to hire professionals with expertise in the open source community “to the greatest extent practicable” and allows CISA to establish a Software Security Advisory Subcommittee, which covers open source security, within CISA’s Cybersecurity Advisory Committee. CISA is an operational component of the Department of Homeland Security (DHS).

Open Source Risk Assessment Framework

CISA would produce an initial assessment framework for handling open-source code risk, incorporating government, industry, and open source community frameworks and best practices from software security. Using this framework, CISA would perform an automated analysis of open source software components used by federal systems no less than every two years. Finally, CISA would establish a pilot program to consider doing a similar analysis for non-federal critical infrastructure systems.

Federal Agency OSPOs

Finally, the Act would establish a pilot program to establish an Open Source Program Office (OSPO) within at least one Federal agency, which would be modeled on existing OSPOs from the private sector, nonprofits, and academia. Additionally, the Office of Management and Budget (OMB) would issue guidance for Chief Information Officers at each Federal agency on how to contribute to and manage risks for open source software, considering industry and community best practices.

For more information, see “Summary of Draft Securing Open Source Software Act of 2022” below.

What are the next steps?

This proposed legislation is the latest signal from Congress around cybersecurity within the federal government. There has been a tremendous focus, starting with the May 2021 White House Executive Order on Improving the Nation’s Cybersecurity and its focus on lifecycle management practices within federal agencies. It’s possible that the bill may be changed further. The proposed legislation will have to pass a vote in the Senate, the House of Representatives, and be signed by the President. The current next step for the legislation is a markup session on September 28, 2022, in the Homeland Security and Governmental Affairs committee.

What’s our take?

It’s very encouraging to see Congress taking affirmative steps to address cybersecurity challenges in the software supply chain. The US Congress’ focus on the critical role open source software plays matches the White House’s focus on these issues. Some of the ideas sound familiar to us – for example, the use of Software Bill of Materials (SBOMs), the importance of security practices of development, build, and release processes (SLSA levels, OpenSSF Scorecards, and the OpenSSF Best Practices badge are indicative industry indicators), and a call for a risk assessment framework echoes our “Risk Assessment Dashboard” stream from our Mobilization Plan. This suggests there are opportunities for OpenSSF to work on this together with government agencies as we would with any other organization. We also like the call for OSPOs to be piloted, as we believe they can play a key role in the secure use of OSS and more contributions upstream. Perhaps most importantly, there is an acknowledgment that there is a need to consider industry and the open source software community.

Surprisingly, some of the points discussed in the Log4Shell hearing are not part of the proposed legislation. For example, the hearing discussed that assessing third-party software should apply to all software (open source or closed source). As Brad Arkin, SVP and Chief Security and Trust Officer at Cisco testified, it would be a mistake to single out open source as a unique source of risk. Mr. Arkin stated: 

“It is, however, incorrect to assume that open source software is uniquely a source of risk. All software has the potential to contain vulnerabilities. All software used in enterprise and commercial products and services requires lifecycle management. Together we need to further improve baselines for software security, including open source software. We collectively need to improve our speed and efficiency at finding and fixing problems when they arise. And together we need to boost our resilience against attacks, particularly as we work to develop, distribute and apply software patches and mitigations.”

The bill’s focus on open source software might cause many to ignore the risks inherent in all software – closed source software is not immune. Singling out open source software could lead to additional costs and mandates for which no funding seems to be explicitly provided. If this has the impact of increasing the cost of adopting or deploying OSS within a government, relative to closed source software, that would be unfortunate. Any mandates or risk assessments should be applied to software no matter the license. The bill also seems to omit the potentially very positive impact that public funding for security work on critical open source would have, as every kind of user would benefit.

The Open Source Security Foundation (OpenSSF) is committed to collaborating and working both upstream and with existing communities to advance open source security for all. We look forward to collaborating with policymakers around the world to improve the security of the software we all depend on.

Summary of Draft Securing Open Source Software Act of 2022

The draft Act was introduced on September 22, 2022. The draft states its purpose is to establish the duties of the Director of the Cybersecurity and Infrastructure Security Agency (CISA) regarding open source software security. CISA is an operational division within the Department of Homeland Security. CISA coordinates as one of the Federal agencies within the scope of the Office of the National Cyber Director (ONCD) and Office of Management and Budget (OMB).

The Act begins by defining terms we in the open source ecosystem may find interest in reviewing:

The Act then lays out the duties of the CISA Director:

1. Outreach, engagement, and coordination with Federal and non-Federal entities to strengthen and support the security of open source software
2. Publicly publish a framework, incorporating government, industry, and open source community frameworks and best practices “for assessing the risk of open source software components, including direct and indirect dependencies.” The framework must incorporate, at a minimum:
   1. the security properties of code in a given open source software component, such as whether the code is written in a memory-safe programming language;
   2. the security practices of development, build, and release processes of a given open source software component, such as the use of multi-factor authentication by maintainers and cryptographic signing of releases;
   3. the number and severity of publicly known, unpatched vulnerabilities in a given open source software component;
   4. the breadth of deployment of a given open source software component;
   5. the level of risk associated with where a given open source software component is integrated or deployed, such as whether the component operates on a network boundary or in a privileged location; and
   6. the health of the community for a given open source software component, including, where applicable, the level of current and historical investment and maintenance in the open source software component, such as the number and activity of individual maintainers.
3. Use the framework to perform a Federal open source software assessment no less than every 2 years. The assessment’s scope will include open source software components used directly or indirectly by Federal agencies based on readily available SBOMs, software inventories, and other accessible data sources. 
   1. The Act directs CISA to automate the assessment “to the greatest extent practicable” and “publish any tools used to conduct the assessment as open source software.”
   2. The Act directs CISA to develop “1 or more ranked lists of components” identified in the assessment, “such as ranked by the criticality, level of risk, or usage of the components, or a combination thereof.”
   3. The Act empowers CISA to facilitate sharing the results and datasets publicly, as appropriate.
4. Perform a pilot study of the feasibility of CISA performing the same framework assessment for critical infrastructure entities (outside the Federal government)

The draft Act adds a subcommittee for “Software security, including open source software security” to the existing Cybersecurity Advisory Committee. The Advisory Committee is tasked to “advise, consult with, report to, and make recommendations to the Director, as appropriate, on the development, refinement, and implementation of policies, programs, planning, and training pertaining to the cybersecurity mission of the Agency.”

The draft Act requires ONCD, OMB, and CISA to issue guidance for Federal agency chief information officers (CIOs) for:

Then the draft Act requires a pilot program to establish an OSPO within at least one Federal agency, that is modeled on OSPOs from the private sector, nonprofits, and academia, to:

1. “support the secure usage of open source software at the covered agency;
2. develop policies and processes for contributions to and releases of open source software at the covered agency, in consultation, as appropriate, with the Offices of General Counsel and Procurement of the covered agency;
3. interface with the open source software community; and
4. manage and reduce risks of consuming open source software at the covered agency.”