Federal legislators last week began the process of better securing the open-source software used by government agencies with a new bill titled “Securing Open Source Software Act of 2022.”
Sens. Gary Peters, D-Mich., and Rob Portman, R-Ohio, introduced the legislation that seeks to address open-source software risks in government. The proposed Bill, S. 4913, now awaits action by the Committee on Homeland Security and Governmental Affairs.
The legislation comes after a hearing Peters and Portman convened on Feb. 2 to investigate the Log4j incident that was discovered in December 2021. It directs the Cybersecurity and Infrastructure Security Agency (CISA) to help ensure that open-source software is used safely and securely by the federal government, critical infrastructure, and others.
Peters, chairman of the Homeland Security and Governmental Affairs Committee, convened the February hearing with experts from the cybersecurity industry and research community to examine the recently discovered vulnerability in Log4j. Cybersecurity experts called that breach one of the most serious and widespread ever seen.
Bipartisan Package
At that February hearing, Peters highlighted a landmark, bipartisan legislative package that would enhance the country’s ability to combat ongoing cybersecurity threats against critical infrastructure and the federal government. He specifically referenced potential cyberattacks sponsored by the Russian government in retaliation for U.S. support in Ukraine.
Log4j, which stands for Logging Utility for Java, is part of the open-source Apache Logging Services Project within the Apache Software Foundation. The software includes multiple variations of the Log4j logging framework for different programming deployments and use cases.
The security issue involves remote code execution weakness that allows an attacker to drop malware or ransomware on a target system. This can cause a complete compromise of the network and the theft of sensitive information, as well as the possibility of sabotage.
The vulnerability “leaves everything from our critical infrastructure, such as banks and power grids, to government agencies open to network breaches. The code flaw can have catastrophic impacts on the lives and livelihoods of Americans,” said Peters during his opening statement at the February hearing.
What’s Proposed
The proposed bill establishes the duties of the director of the Cybersecurity and Infrastructure Security Agency regarding open-source software security and other purposes. It justifies the need for adoption on two key factors:
- A healthy, vibrant, and resilient open-source software ecosystem is crucial for ensuring the national security and economic vitality of the United States.
- Open-source software is part of the foundation of digital infrastructure that promotes a free and open internet.
Both the unique strengths of open-source software and inconsistent historical investment in open-source software security created special challenges in securing open-source software, according to the proposed bill. Thus, the federal government should play a supporting role in ensuring the long-term security of open-source software.
The intent of the proposed legislation is to amend certain definitions regarding open-source software and other provisions of the Homeland Security Act of 2002 regarding cybersecurity and government use.
One key factor in the bill is clarifying the meaning and establishment of a Software Bill of Materials (SBOM). A second factor focuses on the duties of the director of the cybersecurity and infrastructure security agency and the specific steps to ensure and regulate cybersecurity efforts.
Insider Views
Managing open-source software is fundamentally different from managing commercial software. It does not matter if that software is off-the-shelf or created based on a contract, according to Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Center.
“Properly securing open-source software requires an understanding of this and other realities for how open source enters organizations like the U.S. government,” he told LinuxInsider.
The Open Source Software Act of 2022 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, he noted.
“While there is much to like in S.4913, 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,” Mackey said in criticizing the proposed legislation.
The capabilities of the various testing tools, both commercial and open source, also vary considerably. How well software is tested and the security targets used during testing are as important in open source as in commercial software, he offered.
Dan Lorenc, co-founder and CEO of Chainguard, found fault with other areas not included in the cyber bill. For instance, the federal government fails to understand how pervasive open-source software is today. That reality brings challenges to regulating something of this scale, almost equivalent to regulating free speech.
“The reality is that open-source software maintainers are already facing a huge burden keeping up with the pace of innovation and productivity that is prioritized across the ecosystem with the increasing need for stronger security protocols,” Lorenc told LinuxInsider.
They need resources and government support more than a forced change through regulation on a piece of paper, he added.
More Concerns Expressed
A bright spot of the current bill is that CISA will be more hands-on with open-source software and hiring talented maintainers. The new hires will have to know this space inside and out, ultimately contributing open-source security solutions built during this process back to the community, according to Lorenc.
Open source is here to stay. Rather than debate its merits, we should look ahead and recognize the unique benefits open source provides and use those to improve the security of our nation’s critical infrastructure,” he suggested.
Another area the legislation does not well consider is SBOM deployment, Lorenc noted. Deployment is very low, and the space is still very early.
“That is only one of the many problems the government will face with identifying a list of critical software. This has been tried a few times in the past in industry and remains a challenge, with the Census II report from Harvard and The Linux Foundation as a recent attempt,” he offered.
The government should prioritize this area by working very closely with industry, he observed. Any list has broader commercial implications, and industry has access to more data today.
“Getting a list of critical software out is doable this year, but an accurate one will be challenging. SBOM tooling is very early days, and most of what is in use today focus on SCA-based methods that only guess what is inside a piece of software,” he explained.
Higher quality SBOM data is needed to truly understand what software is used throughout industries and the federal government. Either way, Lorenc added, the government should be very transparent about the methods used to determine this list. The same goes for the drawbacks and shortcomings of these methods to allow the list to be interpreted correctly by the broader industry.
Loading ...
