The rate of software supply chain attacks has a funny way of keeping pace with the rate at which software is eating the world. From 2019 to 2022, the average yearly rise in attacks exceeded 700%.
Earlier this year, we even saw the first official case of a daisy chain-like effect of one software supply chain attack directly leading to another. Threat actors are using more sophisticated ways of abusing open source ecosystems like GitHub to host seemingly benign files – the names and formats of which raise no obvious red flags and are initially cleared by most antivirus products.
One thing that hasn’t kept pace with rising threats, however, is policy. Governments around the world have struggled to define regulations that accomplish more good than ill for the software industry. Worldwide, there are a patchwork of regulations, but no overarching global strategy to bind it all together. Considering that software is a globally consumed industry, there is a risk that we might soon see a series of balkanized territories churning out confusingly incongruent policies.
Lack of communication with the open source community in particular is a huge culprit here. With open source comprising 80-90% of all modern application code (for reasons including increased productivity and cost efficiencies), governments must take care to protect an ecosystem that has become an increasingly attractive target for malicious attacks.
But how the EU is addressing open source is very different from how the UK or US is dealing with it. And it is the EU’s approach that arguably has the most potential to harm the open source ecosystem. So, let’s take a closer look at the EU’s Product Liability Directive (PLD).
Should all commercial activities indirectly resulting from open source really be held liable?
For one reason or another, that much-needed dialogue between the EU and the open source community doesn’t seem to have transpired. The result is some dangerous language within the PLD that could spell impending dark ages for open source – a closed source era, if you will.
In fairness, the PLD has garnered praise for trying to establish better standards for software and specific criteria for open source software. It rightly calls for software vendors and producers’ comprehensive understanding of their software’s makeup (for example, using a Software Bill of Materials).
It goes one step further by asking for the ability to recall software affected by a vulnerability. This naturally implies vendors will have to actively manage their entire supply chain. Greater accountability for companies making poor choices is something we’ve been missing in policy for a long time.
Unfortunately, the PLD neuters these positives with some pretty ambiguous language that could be seen as unintentionally targeting open source software distributors like Maven Central, PyPi, npm, and even GitHub.
CTO, Sonatype.
At an initial glance, the PLD appears to exempt open source: “In order not to hamper innovation or research, free and open-source software developed or supplied outside the course of a commercial activity should not be covered by this Regulation.” Pretty immediately, the biggest issue here is that there’s no clear definition surrounding what constitutes commercial activity.
The text tries to distinguish between commercial and non-commercial use of open source: “In the context of software, a commercial activity might be characterized not only by charging a price for a product, but also by charging a price for technical support services, by providing a software platform through which the manufacturer monetizes other services, or by the use of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software.”
The problem is the implication that if you’re a developer of a supplier benefiting commercially from OSS, you’re subject to the PLD too. Further down the text (page 43, paragraph 4), there’s talk of distributors of software being held directly liable and in violation of the proposed regulation if their projects are used for commercial purposes.
You can picture a lot of scenarios where seemingly innocent open-source producers could get caught in the storm. GitHub isn’t a ‘product’ per se, but its components are used in software sold for commercial purposes. The same line of thinking can be applied to other repositories like Maven Central, npm, PyPi, and countless others.
Imagine Etsy being held liable for someone selling a head gasket that a car manufacturer decided to put into some insane project causing that gasket to blow. It’s ridiculous in a physical goods world – it’s even more ridiculous in the software world.
Blame the wrong people enough and they might just bail
When the Log4Shell vulnerability was discovered in 2021, it took 24 hours to patch the component. Yet to this day, 30-40% of all downloads continue to be of the vulnerable version. More widely, we see that 96% of the time that a component is downloaded, there’s a safer or better version of that software available. By the PLD’s logic, the producer of the component – not always the software vendor that chose to include it – could be held liable, which makes little sense.
As a result, there’s a very real possibility of many open source projects soon becoming unavailable in the EU due to being held liable for the actions of a consumer down the road. This is not a GDPR situation, where opting out of that legislation meant risking obsolescence for your business; open source producers and maintainers (many of whom contribute for free) can and will opt out of making their stuff available in Europe if they perceive the risk as greater than the reward. This would be disastrous for both the EU and the ecosystem as a whole.
I’m of course not the only person sounding the alarm here. The Eclipse Foundation and 12 other open source organizations already submitted an open letter to the European Commission earlier this year. In it, they warned in stark terms about the PLD’s potentially chilling effect on the EU’s expressed goals for innovation, digital sovereignty, and future prosperity.
Removing the ‘commercial activity’ qualifier from the open source exemption in both the PLD and the Cyber Resiliency Act (CRA) would provide greater clarity to commercial entities that maintain open source projects free of charge, while still requiring companies that directly monetize open source software to comply with the policy.
We need better, more consistent open source activism
Will the European Parliament amend the PLD’s language? Its plans are unclear, but inaction would be catastrophic.
The current proposal steps over a line more clearly defined by legislation in other parts of the world that have presented more thoughtful approaches to the role and value of open-source software.
For example, the UK’s historical approach to open source and software supply chain management can best be described as underwhelming. But earlier this year, it showed promise in its call for views from organizations on software resilience and security. It’s the first time the UK government has so transparently and thoroughly acknowledged the dangers of poor visibility over potentially compromised open source components, as seen in high-profile incidents like the attacks against SolarWinds and Kaseya, the Log4Shell incident, and recent disruption to the NHS’s IT systems.
It rightly calls for a ‘whole-of-society approach’ that will require not just government but the participation of C-Suite executives, developers and suppliers of software, and those who procure and use it. What the final proposed legislation will look like remains unclear, but the UK government should be commended for instigating this dialogue. It’s much harder to course-correct policy after things have already been set in motion.
The US has similarly launched its own National Cyber Security Strategy, which sought guidance from voices across the industry – mine included. The Eclipse Foundation and Internet Systems Consortium, in their letter to the European Parliament on the PLD, recommended looking at the US’s specific and prescriptive guidance as a benchmark. More specifically, it highlighted, “responsibility must be placed on the stakeholders most capable of taking action to prevent bad outcomes, not…on the open-source developer of a component that is integrated into a commercial project.”
Policy on open source should not just be specific and clear. It needs to be consistent globally if we’re to avoid confusion that scares people away from contributing to an open ecosystem that has brought innovation and efficiency to so many parts of the software world.
There’s hope that the open source community can rally together to achieve meaningful change. At this year’s KubeCon + CloudNativeCon, the head of the Linux Foundation Europe, Gabriel Columbro, urged the community to “fix flaws in the EU’s planned Cyber Resiliency Act.” With more events like KubeCon showcasing the growth and impact of open source, we should use these events as platforms to motivate and directly communicate with the open source community on critical topics like the PLD.
One can only assume the PLD has spurred even greater awareness around the need to drive change.
