Tidelift Advisory: US senators introduce the Securing Open Source Software Act of 2022

Last week, United States Senators Gary Peters and Rob Portman introduced the Securing Open Source Software Act of 2022, and referred it to the Committee on Homeland Security and Governmental Affairs. The bill commits the government to even deeper involvement in open source security and resilience issues, but mostly in ways that will be familiar to those who have followed various US government initiatives since Log4Shell.

Milestone findings and definitions

Usually, the “findings” and “definitions” section of a bill is somewhat dull. However, I think in this case it’s worth calling out for two reasons. 

First, if passed, this bill would mark the first time a US federal statute has defined “open source software” (previously only referenced in passing without definition), and the first time a US statute has used either“open source software community” or “software bill of materials.”

Similarly, the findings call out the role of open source, including that a “healthy, vibrant” open source ecosystem is “crucial for ensuring the national security and economic vitality of the United States.”  In some sense, of course, this isn’t very big news—the federal government certainly hasn’t waited for formal definitions to become involved in open source, as we’ve documented previously. At the same time, though, recognition in statute is a bit of a “how far we’ve come” moment—and worth savoring for old open source hands.

Second, as any lawyer will tell you, lots of important details can be hidden in these sections. This is particularly true the first time terms are defined, since those definitions tend to get referred to (or worse, copied and pasted) in later legislation. Three nuanced details are particularly worth noting.

• Definition of open source community: this definition explicitly includes entities that do not “develop, contribute to, maintain, or publish” open source, but who instead “otherwise work to ensure the security” of open source. While open source should strive to encourage participation, if this definition is re-used, it may open the door to lots of consultations with, and tenders to, companies whose primary business is pointing out security issues rather than collaborating with creators to solve them.
• Definition of “open source software”: without getting into the weeds (which could occupy a whole post in and of itself), this definition is both (1) pretty reasonable and (2) distinct from the Open Source Initiative’s definition of open source software. Expect to see a lot of nitpicking over those details.
• Finding of “challenges”: the bill’s findings state that “there exist unique challenges in securing open source software.” While, at Tidelift, we believe that this is true (particularly the challenges of a mostly unpaid maintainer community being asked to keep the world’s software supply chain safe), the text of the bill often deals with issues that aren’t unique to open source. As the bill is revised, it will be important to apply a critical eye and see which parts are truly specific to open source—and which should be applied to all software used by the federal government.

If the bill passes, the Cybersecurity and Infrastructure Security Agency (CISA), under its director (currently Jen Easterly), will take the lead on several new initiatives. In particular:

• Hiring and coordination: The director will do a variety of things to “bolster” and “strengthen” open source security, including coordination with non-federal entities to “ensure the long-term security of open source software” (emphasis ours). This is positive: various parts of the government have been working on this problem already, but it appears that this will create a new institutional center of gravity, staffed specifically with people with open source experience.

• Framework for assessment, including investment: CISA will define, in the next year, a framework “for assessing the risk of open source software components.” For those in this space, all of the listed factors will be familiar and mostly unobjectionable—things like popularity, choice of language, multi-factor authentication, and the like. One factor jumped out as being somewhat new: “the level of current and historical investment… in the … component.” This is terrific, and in agreement with our advice to the federal government last summer about paying the maintainers for their work. However, no budget is allocated—so we’ll be watching with a keen eye to see whether this leads to further federal investment in supporting the work of maintainers who can help improve the resilience of the open source software supply chain. 

• Doing the assessment: In the second year after the bill passes, CISA will actually assess federal usage of open source, based on the framework defined in the first year, as well as usage data collected from across the federal government and “other publicly available information.”  In the third year, this would be repeated for “critical infrastructure entities.” Interestingly, while the government has to openly publish any tools developed to conduct the assessment, the results themselves do not have to be made public—only shared with relevant entities.

• Building out OSPOs: The act requires every major federal department to create “open source functions” explicitly modeled after non-government Open Source Program Offices (OSPOs). While the focus of these new government OSPOs will be security, they are also tasked with “interfacing” with the community and developing policies for agency contributions to open source. This role will not be new at all agencies, but this could be an interesting sea change in terms of their visibility.

Interestingly, the language of the security framework section of this bill would seem to suggest a higher expectation for open source than proprietary software development. For example, the section on the security framework calls out secure properties such as use of memory-safe programming languages, multi-factor authentication, and cryptographic signing. 

All of these should be the norm for all software developers who sell to the federal government, not just open source. (Some parts of the US government, notably NIST, already recognize this, and it would be great if the bill acknowledged it.)

I hope future versions of the bill require these things of proprietary developers as well, and clearly call out the issues unique to open source (including under-investment in hobby projects that become central to our government software supply chain).

Who will be impacted?

• Open source maintainers: As we’ve written about here before, maintainers are going to be increasingly asked to comply with security standards—possibly including those they had very little input on. This bill is the next step in that evolution, and while it does not formally impact maintainers yet, it creates standards that will likely trickle down to them eventually.

• Organizations that sell to the government and use open source: Similarly, companies who sell open-source based software to the US government are not yet directly impacted by this bill. But (assuming it passes) there will be some new data collection efforts (especially in the second year of the bill), and the new assessments will likely complement efforts already underway via the executive branch.

• People with OSPO-related skills: If you have “OSPO” on your resume somewhere, you just got a major new set of job opportunities—perhaps with more stability and flexibility than many private-sector employers! 

Bottom line: achieving better security outcomes will require partnering with open source maintainers

If you work at an organization building applications using open source components, the writing on the wall is clear. Any organization wanting to sell software to the government will eventually need to ensure the open source components they are using in that software meet these expanded government requirements.

And the issue you should be most concerned with is understanding who is on the hook to do the work to ensure the open source components that you use in your applications  meet those standards.

That’s where Tidelift can really help. Tidelift partners with maintainers to ensure their components meet the standards that enterprises expect (many of which are documented in the NIST guidance), now and into the future, and pays them to do this important work.

You can learn more about the Tidelift approach to improving open source software supply chain resilience here or talk to one of our experts live.