Open Source & More - Blog | Tidelift

CISA, CRA, and PLD: some updates on government regulation of open source

Written by Luis Villa | October 30, 2024

With everything going on in open source, it can be hard to keep track of it all. One important trend that often is in the background is government involvement in open source—which is reaching a critical mass. Here’s a quick roundup of some key developments in this area from the last few weeks.

CISA's "bad practices" announcement

For various reasons, including the upcoming election, the US government is not moving quickly on regulating software. However, dedicated public servants continue using the various levers they have to push the industry forward. Earlier this month, that took the form of the Cybersecurity and Infrastructure Security Agency (CISA)’s release of a list of "bad practices" that software developers and companies should avoid. 

While not all of these are specific to open source, two of the bad practices are quite relevant to open source—and likely will require new resources for open source developers. These are the recommendations against using memory-unsafe languages (with stronger language than we’ve seen in the past) and against shipping open source with known CVEs. 

While CISA cannot create binding rules—yet—this definitely suggests that the US federal government will be continuing to push towards strong regulation.

Adoption of the Product Liability Directive (PLD)

On October 10th, the EU adopted the new Product Liability Directive (PLD). The EU’s formal rules on product liability were last updated in 1984. Given all that has changed since then, as you would expect the major change is to expand the scope to include software.

“A product is defective if it ‘does not provide the safety that a person is entitled to expect or that is required’”.

The focus on safety means that the impact on software will be very real, but still somewhat circumscribed—this isn’t for “mere” bugs, for example.

The directive does include a carve-out for open source software, but that carveout is itself limited. In particular the PLD says:

“Where free and open-source software supplied outside the course of a commercial activity is subsequently integrated by a manufacturer as a component into a product… it should be possible to hold that [integrating] manufacturer liable for damage caused by the defectiveness of such software but not the manufacturer of the [original open source] software because they would not have fulfilled the conditions of placing a product or component on the market.”

In other words, manufacturers who put open source into their product in a way that causes safety problems (perhaps, like the memory-unsafe languages and CVEs called out by CISA!) will be strictly liable. Depending on exactly how courts interpret this language, this could be a major sea-change for hardware manufacturers who integrate software into their products—particularly where that software may lead to safety problems, like cars or medical devices.

Under the EU’s governing framework, directives have to be “transposed” into national systems of law (essentially translation plus adaptation to local systems of law). This process is supposed to be completed by the end of 2026, so we’ll likely see the first legislation in 2027. That feels like it is an eternity away for software developers, but given the processes that will be necessary to show conformance, companies should strongly consider starting to comply now.

Adoption of the Cyber Resilience Act (CRA)

On the same day, the EU also passed the Cyber Resilience Act (CRA). Unlike the PLD (which essentially says “don’t screw it up”), the CRA establishes affirmative obligations towards product security for software products sold in the EU.  (Specifically, it applies to any “connected” software but, as we all know, that’s most software now!) This will require software developers and companies to comply with a variety of different checklists of security measures, including the use of SBOMs to track components of software systems.

Like the PLD, the CRA includes a special carveout to protect open source developers. However, open source that is integrated into a product is (like the PLD) fully covered and must comply, and so many open source developers will face pressure to aid that compliance. Thankfully, many open source organizations are working to make this possible, mostly under the umbrella of the Eclipse Open Regulatory Compliance Working Group.

The timeline for the CRA is somewhat tighter than the PLD, with full effect currently scheduled for Q1 of 2027. Again, given the strict requirements, companies should start preparing for compliance now.

How Tidelift can help

Regulation is coming for open source, whether we like it or not. In just the past few weeks, CISA's "bad practices" announcement, the CRA, and the PLD have significant implications for software developers and companies. All of these government actions will have the impact of increasing pressure on organizations using open source to ensure their software supply chain is secure and resilient.

Tidelift can help ensure your organization is ready! We are the only company that partners with open source maintainers and pays them to:

  • Implement industry-leading secure software development practices and validate the practices they follow so organizations can have the same confidence in the security of their open source that they have in their own code.
  • Contractually commit to continue these practices into the future so that organizations can confidently make long term investments in the packages they use.

With Tidelift, organizations can gain confidence in security and resilience of the open source powering their applications so they can ensure their software products stay in compliance with new government mandates.

If you are interested in learning more about how Tidelift can help organizations like your stay in compliance: