The fallout from the Log4j vulnerability has prompted bipartisan action by Congress to beef up open source software security. The Securing Open Source Software Act would task the Cybersecurity and Infrastructure Security Agency (CISA) with developing a risk framework to evaluate open source code used by the federal government, and could be passed on to critical infrastructure businesses.
Open source software security unites lawmakers
The bid to improve open source software security is co-sponsored by Republican Rob Portman of Ohio and Democrat Gary Peters of Michigan, who called open source software “the bedrock of the digital world” and noted that it is present in the “overwhelming majority” of computers in use today.
CISA has previously warned that organizations should be expecting to deal with Log4j issues for “a long time,” and the Department of Homeland Security (DHS) recently advised that exploitation of it should be expected for at least a decade. The incident was essentially the perfect demonstration of how serious and damaging open source software security issues can be, impacting a very widely used Java logging tool that is embedded in countless software packages. In March security researchers noted at least three million vulnerable instances in a study, many buried deeply in software and difficult to locate and remediate without a “bill of materials” or similar documentation pointing directly to them.
This is not the first time the government has directly addressed the issue, which first appeared in late 2021. The Federal Trade Commission (FTC) has issued a warning that it intends to fine companies that fail to patch it out and later experience a breach of personal information attributed to it. The FTC cited the Equifax breach of 2017 as a similar example; that too was caused by a known vulnerability in Apache Struts that the credit bureau had failed to patch, and led to a $700 million fine after the sensitive personal information of over 100 million people was stolen.
The federal government has been supportive of open source software use in its agencies for nearly two decades, but has largely left security up to individual departments. The open source software security bill would leverage CISA’s emerging status as the federal security watchdog to have it draft a risk evaluation framework for all agencies. The bill proposes that CISA draw on existing frameworks from “government, industry, and (the) open-source community” and hire open source developers to address and remediate security issues. At this time, any use of this framework by critical infrastructure companies would appear to be voluntary.
The Biden administration has already taken a step in this direction with its recent executive order requiring that open source software used by federal agencies have a “software bill of materials” available. If the bill passes, some federal agencies would be required to form Open Source Program Offices (OSPO) and the Office of Management and Budget (OMB) would be tasked with issuing federal guidance on open source software security.
Tim Mackey, Principal Security Strategist at Synopsys Cybersecurity Research Center, notes that the proposed open source software security bill follows a path that private industry is already taking with software but is not necessarily as comprehensive as is necessary: “Managing open source software is fundamentally different from managing commercial software – whether that software is off-the-shelf or created based on a contract. Properly securing open source software requires an understanding of this and other realities for how open source enters organizations like the US government. The Open Source Software Act of 2022 (S4913) recommends many activities that are traditionally the responsibility of an Open Source Program Office (OSPO). For example, it is the responsibility of an OSPO to determine what open source risks are acceptable for an application and the context in which it’s deployed.”
“While there is much to like in S4913, the fact that there is no mention of how open source software was tested is concerning. There are many software development practices that can create weaknesses in software, and some are programming language dependent. The capabilities of the various testing tools, both commercial and open source, also vary considerably. How well software is tested and what the security targets used during testing are as important in open source as in commercial software,” added Mackey.
Open source software security bill brings needed changes, but has weaknesses
Though the open source software security bill has substantial support, it will face some challenges on its path to adoption.
One is the upcoming midterm elections, which not only draw the full attention of legislators but also cause the legislative schedule to be shortened. The bill is very likely to sit until 2023 before any further progress is made on it, and if previous cybersecurity legislation is any indication it could potentially sit for even longer as other items take priority.
And while open source software security is a very important issue, there is some concern that this will draw government attention exclusively to this element at the expense of addressing needed improvement to commercial products. The biggest security breaches the government has weathered recently were the result of weaknesses in Microsoft Exchange and breach at SolarWinds.
The bill has moved relatively quickly thus far, however, going from committee to the Senate at the end of September. If it passes Congress, President Biden is generally expected to be in favor of signing it into law given the administration’s priority focus on improving the country’s cybersecurity defenses. A series of executive orders issued since 2021 has prompted fairly rapid updates to the defenses of government agencies, critical infrastructure and utility companies.
