Open Source Security
Is Open Source Activism a Threat?
Breaking open source packages intentionally.
When working with free open source software you are used to seeing news of vulnerabilities and malicious packages, but recent events unfold a new flavour of threats to your supply chain risk buffet: Developer Activism.
By intentionally corrupting the packages you depend on and breaking your builds — the goal is to get acknowledgement for their own agendas. Every dependency you’re using, and you probably have hundreds, is a potential candidate for these “attacks”.
What happened?
On January 8, 2022, the developer of the widely used npm packages `colors` published a new version, colors@1.4.1.
The new version introduced an infinite loop — essentially breaking any application that depends on it. A few days earlier another package from the same maintainer, faker, received a new major version faker@6.6.6 completely wiping the source code from the package — rendering it useless.
What initially was interpreted as a supply chain attack, upon further investigation turned out to be a manifestation aimed towards big companies using FOSS without compensation trickling down to the developers (read the full story here, it’s an interesting read).
An ethically questionable move, causing loads of problems for developers around the globe — although some would argue a maintainer has every right to do whatever he/she wants to do with their code.
How do I mitigate the incident?
Mitigating the issue is straightforward — reverting or pinning dependencies to the previous versions colors@1.4.0 and faker@5.5.3. In addition, in the case of colors, npmjs has removed the corrupt versions, making sure subsequent downloads get a working version.
In the long run, users should look to migrate to alternative libraries, with maintainers that plan to continue development.
What about other similar incidents in the future? One concern is events repeating themselves for other connected OSS projects.
Additionally, these types of actions usually encourage copycats that share the same sentiment.
Wouldn’t it be better to completely avoid corrupted packages, now and in the future? That was one of the topics I and my colleagues at Bytesafe discussed last year, and later designed a feature that offers a long-term solution, we call it Delay Upstreams, which allows you and the open source community time to react and filter such malign behaviour.
Activism — executed like a supply chain attack
The sabotage of colors and faker shines new light on ongoing discussions in the open source community regarding fair compensation to open source maintainers for their work. Fuelled by the enormous effort spent on patching the numerous log4j vulnerabilities as a prime example of open source developers working excessively without pay.
This incident shares several characteristics with recent supply chain attacks ua-parser-js, coa and rc where harmful code propagated to a wide range of popular dependent libraries and unsuspecting users. In those cases, the vessel was account takeover, while in this instance it was by the rightful maintainer.
But any action that intentionally corrupts a package dependency is by nature malicious and should be prevented.
The overall opinion on the incident in the open source community has been divided. Many developers are considerate on the subject of making open source work more sustainable, for an in the end improved community.
But the overall census on the execution is negative, breaking the unspoken trust between developers and wasting resources to set things right, where other options for monetization like software licensing should have been considered.
Regardless of views of the events, one thing is clear: organizations have yet more incentive and proof that they must take action to protect their supply chain from any action that aims to deny your service functionality.
Prevent newly published packages until a safety delay has passed
This pattern of supply chain attacks occurring and being remediated by the open source community quickly, ensures that the problem does not survive too long in the wild. But nevertheless, this of course causes a lot of problems for people that rely on the latest versions to build their applications. We at @bytesafe thought about this and designed a feature we call Delay Upstream.
The Delay Upstream policy as part of the Dependency Firewall enables a custom “time buffer” before new versions are allowed to reach your code.
By giving millions of open source users a chance to evaluate new releases, you could prevent critical vulnerabilities and malicious packages to reach your application. And let’s face it, it’s pretty seldom you need the latest and greatest of all packages immediately available to your application.
Until a set delay has passed, new versions from public repositories like npmjs, Maven Central and NuGet Gallery are made unavailable to you. With Bytesafe automatically selecting other recent and allowed versions for you — to not break your builds.
Customizable delays to match your needs
What the desired “maturity since release” is, differs between organizations. The delay is completely customizable per registry in your Bytesafe workspace.
Adjust it to your needs per ecosystem and enforce a delay of 3 weeks for npm while using 2 months for maven and NuGet — if it’s right for you.
Your organization can find the right balance between delay (security) and access to new functionality.
Looking to secure your supply chain?
Bytesafe offers a dependency firewall that secures private registries for different source code ecosystems. Allowing organizations to review and make conscious decisions on the dependencies they are using for a secure supply chain.
And remember — if you are using an open source library extensively — consider supporting it and its maintainers. Providing a better and safer open source community for all.
More content at plainenglish.io. Sign up for our free weekly newsletter. Get exclusive access to writing opportunities and advice in our community Discord.
