By Brian Fox (Sonatype, OpenSSF GB),  Jeff Wayman (Sonatype), Jonathan Meadows (Chair, OpenSSF End Users WG), Christopher “CRob” Robinson (Chair, OpenSSF TAC) on behalf of the OpenSSF End Users Working Group

By adopting a few common principles, software organizations can achieve real, measurable change in the security and health of their software supply chains. You are invited to adopt the new Open Source Consumption Manifesto (OSCM) developed by the OpenSSF’s End Users Working Group and to sign the Manifesto by adding your name and submitting a PR. The OSCM aims to be a guide to encourage software organizations to take responsibility for their consumption of open source software (OSS) by focusing on activities with the greatest impact and providing a roadmap to implement supply chain security (SCS) best practices. 

The sum is greater than the parts

Over twenty years ago, a group of software professionals met in the mountains of Utah. Representing a wide range of backgrounds, these professionals weren’t there to debate. Instead, they sought common ground.

Something unexpected happened.

Through a collection of self-titled anarchists, they came together to elicit change. The most likely reason? They shared a common goal: challenging current conventions of software development. And it was at this meeting that Agile Software Development was born.

The Agile Manifesto, the main byproduct of that meeting, is unassuming. Despite this simplicity, the subtle nature of the manifesto is its greatest strength. Because of this, it has had a profound impact on every aspect of software development. On the surface, the Agile Manifesto is a collection of core values. Then, in support of those values are twelve guiding principles.

This was intentional.

The group that came together did not set out to create dogmatic standards. The opposite was true. The Agile Manifesto intended to unite and celebrate different approaches. In short, it set out to inspire change without a prescribed process.

Open source software (OSS) consumers need a similar approach. We need our own manifesto.

A new Manifesto

Software supply chain security challenges today, match those of software developers in 2001. Twenty years ago, bureaucracy and an overabundance of processes were strangling innovation. But there wasn’t a general agreement on how to solve that problem.

Today, we’ve reached a consensus on the impact of vulnerable OSS on software supply chains. We don’t need a micro convention in Utah for that. But, while there is agreement on the importance of reducing risk, how to achieve that varies.

Some believe the education of software development teams should be a priority. Others focus on the value of frameworks, best practices, and standards. And as of late, governments have “entered the chat.” Of note, this latter method runs from thoughtful to terrifying.

Aside from some versions of that last one, any of the above are workable methods. The challenge arises in deciding where to start. Some methods may be quick, yet leave some other issues unaddressed. Others may take years and an investment of time that isn’t scalable for every organization. These gaps threaten the very improvement each method seeks to achieve.

We need a simple approach.

So, with reverence to previous trailblazers, you have our deepest respect. And in a form of flattery, we (the End User Working Group at OpenSSF) have created a manifesto of our own.

The Open Source Consumption Manifesto (OSCM) aims to address the gaps mentioned above. But, it is also intended to be a living document. Our goal with the OSCM is to find common ground, to unite many different approaches. Like the Agile Manifesto, the OSCM embraces a set of core values. In partnership with those values are fifteen guiding principles.

Our hope and simple goal: improve open source consumption in every software organization.

Consumption is at the center of it all

OSS is a valuable public good. As such, it has provided tremendous gains in efficiency and innovation. Not all OSS is equal.

For example, some projects may not be well-maintained. Others lack secure software development standards. Even in the best cases, risk still exists. OSS isn’t altogether different from most software; it has defects. Yet, many (most) organizations have no approach or strategy of consumption of OSS.

Today, almost every organization applies standards for software acquisition. Few development organizations would consume software from a third party that wasn’t:

• evaluated for security vulnerabilities,
• vetted for code quality,
• or reviewed by legal for licensing terms.

Unfortunately, OSS is most often not subject to the same level of scrutiny. And, in many ways the risks are even greater. It’s unlikely your third party software could contain a malicious package. But, for the unaware consumer of open source, the point of download represents ground zero.

Why the different treatment?

Maybe they don’t care. Hubris could be a potential culprit as well. Many organizations use contract law to dodge product liability. But the most likely answer—all roads lead to awareness.

An absence of awareness

In many ways OSS suffers from a philosophy that you can never have too much of a good thing. And a decade ago, you could relish in the lack of awareness without much concern. At that time, OSS vulnerabilities didn’t tend to make headlines.

At the end of 2021, everything changed.

Log4j and Log4Shell became a topic de jour at the dinner table and water cooler alike. Software organizations suspended feature work. Developers spent sleepless nights scouring the code base for signs of the vulnerability. But in the wake of huge productivity losses, did anything change?

That depends on how you look at it. The best organizations seized an opportunity to adopt best practices and improve processes. Some organizations addressed Log4Shell, glad to see the whole ordeal behind them. Others, and a number big enough it’s sometimes hard to sleep at night, took a different approach.

In November of 2022, Tenable found 72% of organizations remain vulnerable to Log4Shell. In December of the same year, Wired magazine drew attention to the lack of response as well. And as we drift further from December 2021, it only gets worse. Last month, software developers consumed hundreds of thousands of vulnerable versions of Log4j.

But it’s not “just” about Log4j

Sure, Log4j makes the headlines. But is Log4Shell as bad as the media made it out to be? And what about other vulnerable open source? Maybe the problem is open source itself.

To find an answer to those questions, consider this article from VentureBeat in 2022. It highlights research on the availability of non-vulnerable OSS. That research looked at vulnerable, open source Java components. It found that at the time of download, 96% had a non-vulnerable version available. An article by Dark Reading in February of 2023 compounds the issue. In the article, it suggests as much as half of all applications have a high-risk vulnerability due to OSS.

To make matters worse, this research only covers vulnerabilities. Today’s developers also face threats as great or worse than component choice. Open source consumption risk now includes malicious packages and malware attacks. In quick order, bad actors have shifted left to target open source projects. Attacks like dependency and manifest confusion represent real risks.

The problems described above are not problems with OSS. These are OSS consumption problems. And no amount of incidents like Log4Shell or the next headline will change this.

Time is running out

The security of software supply chains is at a crossroads. The exponential growth in attacks has forced the hand of governments worldwide. In the US, Executive Order 14028 marked a turning point. Increased scrutiny of secure software development practices is the new normal. 

In parallel, governments worldwide have put forward legislation to address similar risks.

In the past, governments tend to be slow and meandering. But, events like NotPetya, Solarwinds, and even Log4Shell have prompted quick action. 

As a result, software organizations now face a changing landscape. High costs and inefficiency associated with vulnerability are the beginning. Increased liability represents the potential for incredible loss.

So why aren’t organizations more intentional on these issues?

Well, it’s cliché, but change is not easy. This is most often due to the required paradigm shift. But, impactful change also requires clear direction. Today’s software organizations have tremendous choices in addressing these issues. A multitude of frameworks, weekly guidance from government organizations, and more. Sometimes too much choice creates paralysis. And it can be hard to get started.

Become the change you want to see

As a Working Group within the OpenSSF, we appreciate the challenge of change. So, we set out to be the change we wanted to see. And that became a seed planted in the fertile soil of the great discussion. A seed that has grown into the Open Source Consumption Manifesto we present today.

The intention of the OSCM isn’t dogma. In fact, we aim for it to be the opposite. It represents an effort from weeks of conversation with input from many disciplines. This resulted in a collaborative collection of best practices forged through experience. And by experience, we mean our own failures and successes. 

The OSCM carries an intention of inclusion. It has changed over the course of our discussions, and we invite your future changes as well. Most of all, we hope the values and principles contained in the OSCM prove helpful. And that it serves as a guide to better open source consumption in your organization.

On behalf of the OpenSSF End User Working Group, we invite you to join us. Below is the “final” draft of the Manifesto (v1.0). We’ve included it here for posterity, but feel free to add comments and suggestions. It will live on (forever) in our GitHub Repo. And finally, as we like to say, “patches welcome.”

The Open Source Consumption Manifesto

We seek to…

1. Prioritize secure consumption of open source components
2. Be aware and considerate of the developer experience
3. Build upon iterative policy-based foundations and best practices

We call on commercial and non-commercial development organizations to…

• Accept open source software consumption as critical to building a secure software supply chain.

• Ensure that open source software consumption is balanced against a defined risk profile which can depend on risk tolerance, regulatory context, etc.

• Recognize potential risks associated with open source consumption, including vulnerabilities, malicious software and component choice.

• Acknowledge that not all vulnerabilities are actively curated, and the scoring systems (such as CVSS used for CVEs) can be a trailing indicator.

• Improve open source consumption via audit and quarantine functionality for components matching known vulnerabilities and malicious packages.

• Focus on tools and processes that support and extend the abilities of development teams/developers to make informed evaluations of consumed open source software.

• Protect software organizations and development teams from malicious software by supporting established security models (e.g., SLSA, S2C2F, etc.) and then applying those models to the consumption of open source.

• Establish an open source consumption policy and regularly test against tolerance for risk, impact on development teams, and other goals.

• Work with teams to design and implement mindful control points for open source consumption throughout the SDLC.

• Adopt tooling, best practices, and processes to (1) continuously track, measure, and improve the security of open source software being consumed, (2) respond to security issues more effectively, and (3) facilitate risk communication to customers/partners through existing channels (e.g., CISA’s CVD, VEX, etc.).

• Adopt and develop open source consumption management tooling and processes that support a recall ability similar to those in other industries.

• Ensure the lifecycle of consumed open source components is appropriately managed and that consuming developer teams use the latest, LTS, or otherwise “supported” releases where practical.

• Engage with the upstream developers of consumed components, especially for components that form a critical part of your project, to report issues, fix bugs, support development, etc.

On behalf of the OpenSSF End User Working group, we invite you to join us in adopting the principles and best practices of the Open Source Consumption Manifesto and help spread the message. If you’re interested in officially signing the Manifesto, feel free to add your name and submit a PR.

About the Authors

Co-founder and CTO, Brian Fox is a Governing Board member for the Open Source Security Foundation (OpenSSF), a member of the Apache Software Foundation and former Chair of the Apache Maven project. As a direct contributor to the Maven ecosystem, including the maven-dependency-plugin and maven-enforcer-plugin, he has over 20 years of experience driving the vision behind, as well as developing and leading the development of software for organizations ranging from startups to large enterprises. Brian is a frequent speaker at national and regional events including Java User Groups and other development-related conferences.

Jonathan Meadows is the chair of the Open Source Security Foundation (OpenSSF) End User Working Group. He is also a Citi Tech Fellow and the Head of Cloud, Application and Software Supply Chain Security at Citi. He is a keen advocate of DevSecOps, Open Source, codified security controls and automated security testing. Jon started the CNCF Financial Services and supply chain working groups where he co-authored the CNCF Supply Chain Best Practices white paper. He actively contributes to the community as a board member for the OpenSSF and chair of the OpenSSF End User Working Group.

Christopher Robinson (aka CRob) is the Director of Security Communications at Intel Product Assurance and Security. CRob is a 43rd level Dungeon Master and a 26th level Securityologist.  He has worked at several Fortune 500 companies with experience in the Financial, Insurance, Legal, Manufacturing, and Medical verticals. CRob has been involved in upstream open source security for a decade, and spent 6 years helping lead the Red Hat Product Security team as their Program Architect. He is a leader within several Open Source Security Foundation (OpenSSF) efforts and is a frequent speaker on cyber, application, and open source security.

Jeff Wayman has spent a decade+ leading digital content and community teams across OSS Security, DevOps, and DevSecOps. In his current role, he guides OSS Security thought leadership and content strategy for Sonatype. Jeff promotes OSS security awareness through his work with the OpenSSF EUWG and his contribution to the Atlantic Council’s Open Source Policy Network. Jeff is pursuing an MBA at the Gies College of Business—University of Illinois|Urbana-Champaign, focusing on Digital Marketing and Strategic Innovation.