Open source software underpins most, if not all, development projects, yet when vulnerabilities in popular and ubiquitous components such as Log4j surface, organizations scramble to adequately understand their exposure and mitigate risk.
Bipartisan legislation introduced last week by Sens. Gary Peters (D-Mich.) and Rob Portman (R-Ohio) called the Securing Open Source Software Act of 2022 may be an important step toward reducing that risk across the federal government. A hearing to consider the bill is scheduled for today.
Key mandates proposed in the act address the challenges agencies have in understanding where and how open source software is used, and provide decision-makers with best practices for secure implementation and monitoring of open source code. The act would require the Cybersecurity and Infrastructure Security Agency (CISA) to develop an assessment framework to help federal agencies understand their risk as it relates to open source usage. The legislation would also require monitoring of how open source is used, publication by the Office of Management and Budget (OMB) of guidance on the secure usage of open source software, and the hiring of experts within the domain.
Claroty endorses the act and believes it would help improve visibility into the use of open source software across the federal government, reduce risk to organizations and agencies, and ultimately lead to a similar template for commercial enterprises.
Beyond the merits of this proposed legislation, we feel the effort will be even stronger when combined with parallel initiatives by the Cybersecurity and Infrastructure Security Agency (CISA) and the rest of the Executive Branch—on their software bill of materials (SBOM) work as seen in Executive Order 14028.
Understanding Exposure Leads to Effective Response
The Log4Shell vulnerability (CVE-2021-44228) uncovered in the popular Log4j Apache logging framework could be trivially exploited to gain remote code execution on affected applications and services. Homeland Security’s Cyber Safety Review Board in July published an extensive review of the Log4j vulnerability and its aftermath, and concluded that organizations that best understood their exposure were most effective in blunting its effects. These, however, were few and far between, the board said in its report.
“However, few organizations were able to execute this kind of response, or the speed required during this incident, causing delays in both their assessment of the risk and in their management of it,” the report said. “When (Apache Software Foundation) made upgrades for Log4j available, deploying them was itself a risk decision, forcing a tradeoff between possible operational disruption and timeliness, completeness, and compensating controls.”
Claroty has reviewed the draft legislation, and we conclude that this act is a measure beneficial to national security, economic security, and public safety. Here are three principles guiding Claroty’s endorsement.
Transparency is First Step to Securing Open Source Usage
Open source software accelerates innovation and minimizes development cost across government and industry. It powers everything from mundane applications to life-saving healthcare devices and industrial automation processes that sustain our way of life. Researchers at Claroty and other cybersecurity companies have demonstrated how open source vulnerabilities can create openings for state actors or criminal organizations to disrupt critical processes or services.
Without transparency into the use of open source software in applications pervasively used by the public sector and privately owned and operated critical infrastructure, the U.S. government does not have sufficient visibility into software and firmware vulnerabilities that could impact national security, economic security and public safety. We believe that the proposed legislation would be an important step forward to gain insight into the use and security of open source software used by the federal government.
CISA Framework Unifies Stakeholders on Open Source Security
The risk framework mandated in the Securing Open Source Software Act will identify and enumerate the dependencies associated with open source software usage. Agencies and other stakeholders will be able to use it in order to understand how to assess and mitigate risks introduced by open source, and ultimately how to govern its usage.
The creation of this single taxonomy (and in concert with other SBOM efforts), Claroty believes, is vital to preventing another mad scramble to identify where the next Log4Shell-like vulnerability is and how to extinguish it. We hope both government and non-government entities will fully implement the framework, and use it as a common language for assessing and communicating the risks associated with open source software.
Visibility into Open Source Usage in Critical Infrastructure Essential
The legislation would direct CISA to assess how and where open source software is used, and determine the feasibility of assessing the risk to U.S. critical infrastructure. Claroty believes both aspects of this assessment are critically important.
First, the federal agency assessment will not only shine a light on how and where open source is deployed and how it introduces risk that impacts national security, but also could influence the private sector and open source ecosystems to mitigate or remediate open source vulnerabilities. As a byproduct, the same software used in the private sector would also be mitigated or remediated.
Despite these benefits, there are unique types of software used in specific industries—such as connected clinical devices in healthcare, or programmable cyber physical systems in industrial operational technology environments—that will not be addressed by the actions to understand the risks associated with the use of open source in federal agencies. To that end, an important aspect of the legislation is the study to understand the risks of open source to critical infrastructure entities.
We believe that such a study will be foundational to understanding the use of common vulnerable open source software across critical infrastructure in both cross-sector and sector specific contexts. This body of work could serve to provide an understanding of common risks and determine targeted and focused investments for substantial gains in critical infrastructure security. One only needs to look at the discovery of the critical Log4j vulnerability in 2021 to understand the risk associated with pervasive open source software vulnerabilities.
Finally, while outside the scope of this legislation, we also believe that legislative actions being contemplated as part of the National Defense Authorization Act of 2023 (NDAA) to require an SBOM for any software sold to the federal government is essential. While the legislation proposed by Sens. Peters and Portman will serve to understand and mitigate the risk of software in federal agencies and the U.S. critical infrastructure, the legislative initiative in the NDAA will serve to reduce the footprint of new vulnerable software introduced into the Federal Government.
