Protestware and Supply Chain Attacks destroy the trust placed in the community and place the internet at great risk. No one can afford that.

On March 21, President Joe Biden made mention of the rising of a “new world order” and how America had to lead now more than ever. His message was clear – the world is undergoing major upheaval and now is the time to lead by example, demonstrating and proving the efficacy of our values. This also holds true for Open Source software, and maybe the entire internet as well, as we stand on the precipice of either domination or disaster. Forgive me for being so dystopian, but we are at grave risk.

The Open Source ecosystem provides most of the underpinnings of the internet. Open Source also transacts in one primary currency – trust. Not just your typical trust either, but a long held belief in sharing information and helping people in order for the betterment of all. This is the core reason behind sharing code, the belief that sharing and collaborating on it will make the whole far better than the sum of its parts. Once these fundamental beliefs begin to erode, we come to a dangerous point where innovation will be slowed and progress could come to a halt.

For decades those beliefs, and that trust, have held true which helped spur the rapid evolution of technological innovation and helped us all. Now, however, there seems to be a rising tide of actors taking the open source community hostage. One of those actors are perpetrators of what seem to be an endless array of supply chain attacks, where malicious actors are taking advantage of the popularity of open source software to introduce problematic software at some point in the software production cycle. It is then spread amongst that software’s users, and often used to infiltrate an organization, steal sensitive information or mine for cryptocurrency. As one example, it was recently reported that there were 1,300 malicious packages found in npm – that’s a dizzying number.

Those perpetrators may be in it for money, but what is even more troublesome to me is a different sort of actor – the  “protestware” in which developers purposely sabotage their software to send some sort of “message,” be it political or otherwise. One of the core tenets of the open source community is that we trust each other – that my code, no matter how bad of a programmer I admit to being, will never purposely cause damage to yours. Attacks like colors.js/faker.js will cause management within an organization to question their commitment to using open source software. The node.ipc attack, which was purposely made to wipe data off Russian and Belarussian machines, is an even graver escalation of the stakes which can no doubt lead to all out “software nuclear war.”

With so much of our world and lives connected to technology and the internet today, is the collateral damage of such a scenario something which we want to really involve ourselves with? Open source is supposed to benefit mankind, advance humanity and promote progress, not cause it damage. We didn’t get into this game for this, at least I didn’t. If we’re meant to lead a new world order, shouldn’t we be leading with our values instead of devolving into rogue behavior intended to cause damage?

In order to trust, we need to zero-trust

This is the coming of age of open source and how the community responds to this subversion and subterfuge will reflect tremendously upon the benevolent majority of open source developers and how we’ve matured as a community. We must prove how adept we’ve become at tackling these issues, both internal and external, by coming together to provide solutions which enable security throughout the open source supply chain – all the way from code to deployment. Solutions which are smart and scalable to millions of projects. Solutions which will telegraph the confidence we have in our community and processes, so that every government office, every CISO, and every manager everywhere have no compulsion to decide between using open source or a proprietary package.

We already have the technology to do it too – Software Bill of Materials (SBOM) on the development side and the zero trust security model on the deployment and access side. Efforts like the SLSA framework, which incorporates SBOMs as part of its 4-tiered approach to ensuring artifacts are properly accounted for, creating a family tree of a package’s provenance. Projects which allow us to take Supply chain Levels for Software Artifacts (SLSA) a step further and enhance that provenance via immutable storage and third-party cryptographic verifiability.  Projects which aid and assist the maintainers of long-tail of open source projects to easily enhance their security posture without requiring too much of their already stretched too thin time. All of these are focused on ensuring a secure software supply chain.

On the deployment and access side, in a world built around containers and Kubernetes, enabling and encouraging projects to practice Zero-Trust guidelines, such as providing each service minimally and architecting for the concept of least-privilege for users. Embedding comprehensive security monitoring and automation, vulnerability scanning and testing. These tools and processes will allow us to not only create smart solutions, but also act as an example for how such solutions should be architected.

We’ve reached an inflection point and now is our time to show how we stand for our principles and how we plan to lead (the software world). The U.S. Federal government has certainly been paying attention and this is our golden opportunity. To step up from “open source is cool to use because it’s free and works for us” and rise to “open source is a MUST to use, because it’s free, powerful and secure.” Let’s lead this new world order so that others in countries around the world will follow our example.