Blog

There’s at least one thing Republicans and Democrats can agree on in the US Senate: the importance of open-source software in today’s tech world. Seriously. 

As US Senator Gary Peters (D-MI) said last week, “Open-source software is the bedrock of the digital world.“

His partner across the aisle, Rob Portman (R-OH), agreed, saying, “The computers, phones, and websites we all use every day contain open-source software that is vulnerable to cyberattack.” 

Therefore, “The bipartisan Securing Open Source Software Act [PDF] will ensure that the US government anticipates and mitigates security vulnerabilities in open-source software to protect Americans’ most sensitive data.”

This bill proposes that since the Log4j security blow-up in 2021, and its continuing aftershocks, showed just how vulnerable we are to open-source code attacks.

In January, the US Federal Trade Commission warned it would punish companies that don’t fix their Log4j security problems.

The Cybersecurity and Infrastructure Security Agency (CISA) must help “ensure that open-source software is used safely and securely by the federal government, critical infrastructure, and others.”

The US government has long supported open-source software. For example, all the way back in 2000, the National Security Agency helped create Security-Enhanced Linux (SELinux).

Another example from 2016, then-US Chief Information Officer Tony Scott proposed a pro-open-source coding policy that required any “new software developed specifically for or by the federal government to be made available for sharing and reuse across federal agencies.

It also includes a pilot program that will result in a portion of that new federally funded custom code being released to the public.”

The Securing Open Source Software Act, however, moves open source from the realm of policy and regulation decisions into federal law.

This bill will direct the CISA to develop a risk framework to evaluate how open-source code is used by the federal government.

The CISA would also decide on how the same framework could be used by critical infrastructure owners and operators.

According to the Open Source Security Foundation (OpenSSF) in its analysis of the Act, the “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.” 

In short, the CISA would not try to reinvent the wheel, instead using the best of existing open-source security techniques.

This follows in the footsteps of President Joseph Biden’s Executive Order on Improving the Nation’s Cybersecurity, which stated that developers must provide “a purchaser with an SBOM [Software Bill of Materials] for each application.”

The Act will also require the CISA to identify ways to mitigate open-source software risks. To make that happen, it requires the CISA to hire open-source developers to address security issues.

It also proposes that some Federal agencies start Open Source Program Offices (OSPO).

Finally, it will require the Office of Management and Budget (OMB) to fund a CISA software security subcommittee and issue federal guidance on how users can secure open-source software.

People who follow open-source security closely have heard much of this before.

As the OpenSSF noted, “Some of the ideas sound familiar to us — for example, the use of SBOMs, the importance of security practices of development, build, and release processes), and a call for a risk assessment framework [echo] our Risk Assessment Dashboard stream from our Mobilization Plan.”

Surprisingly, the bill misses other points. For example, all software, not just open source, should be checked for potential risk.

As Brad Arkin, Cisco’s SVP and chief security and trust officer, testified to Congress about Log4J: “Open-source software did not fail, as some have suggested, and it would be misguided to suggest that the Log4j vulnerability is evidence of a unique flaw or increased risk with open-source software.”

“The truth is that all software contains vulnerabilities due to inherent flaws of human judgment in designing, integrating, and writing software.”

Still, imperfect as the bill may be, the OpenSSF says it 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.”

The OpenSSF isn’t the only group that’s willing to work with the government to fundamentally improve open-source security but also has concerns. 

Open Source Initiative (OSI) US Policy Director Deb Bryant worries Congress is “building a framework which is targeted to treat open source as a special class of software instead of solving it for all of software.”

Heather Meeker, a well-known open-source lawyer and OSS Capital general partner, more optimistically added, “It’s good to see a bipartisan effort to improve management of security in software infrastructure — including open-source software.

“The private market has long clamored for this improvement, via customer demands and expectations for software and cloud services vendors.”

“But government oversight may help accelerate improvement efforts outside of commercial vendor arrangements, or in situations where vendor market power allows vendors to push back against customer demands.”

Of course, just because a bill reaches Congress doesn’t mean it will become law. Still, its committee advanced the bill to the Senate floor on Sept. 29.

That’s very fast for any bill on any issue. If it makes it through Congress, there seems no doubt that Biden will sign it into law.

With luck, securing open-source software will become the law of the land in 2023.