When working with free open source software (FOSS) you are used to seeing news of vulnerabilities and malicious packages, but recent events unfolds a new threat to your supply chain: 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 user 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? Bytesafe offers a long-term solution with the Delay Upstreams policy - buying you and the open source community time to react and filter 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. Fueled by the enormous effort spent on patching the numerous log4j vulnerabilities as a prime example of open source developers working excessively without pay.
|
|---|
| Dependency on open source according to https://xkcd.com/ |
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
The Delay Upstream policy as part of the Dependency Firewall enables a custom “buffer” before new versions are allowed in your registries.
By giving millions of open source users a chance to evaluate new releases, you could prevent critical vulnerabilities and malicious packages.
Until the set delay has passed, new versions from public repositories like npmjs, Maven Central and NuGet Gallery are made unavailable to your organization. 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 in Bytesafe is completely customizable per registry in your 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.
When
current time >= publish time + safety delay the new version 1.3.0 will be allowed in your organization and any subsequent fetches will receive the new version.
Looking to secure your supply chain?
Bytesafe offers a dependency firewall that secures private registries for Npm , Maven and NuGet. Allowing organizations to review and make conscious decisions on the dependencies they are using for a secure supply chain.
Read our previous post on staying safe from compromised new versions for more information on balancing flexibility with security, especially for automated environments and decentralized developer organizations.
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.
Thanks for reading!
