OpenSSF created the Open Source Consumption Manifesto (OSCM) with the main objective of enhancing the utilization of open-source software.

Similar to the Agile Manifesto, OSCM is based on core values and comprises 15 guiding principles for using open source. It is designed to be a continuously evolving document, according to the Open SSF. 

Open Source Software (OSS) is a valuable resource that has greatly enhanced efficiency and innovation. However, not all OSS projects are the same. Some are poorly maintained, lack security standards, or carry risks. Just like any software, OSS has its flaws. Despite this, most organizations lack a strategy for consuming OSS effectively, according to the OpenSSF.

Unlike the scrutiny applied to third-party software, OSS often isn’t subject to the same level of evaluation for security, code quality, and licensing. This oversight is concerning since the risks associated with OSS can be significant, according to the OpenSSF End Users Working Group in a blog post. While third-party software is unlikely to contain malicious content, for those unaware of the intricacies of OSS, the moment of download is where risks emerge.

“We have observed that 96% of the time when a vulnerable component is downloaded, there is already a fixed version available, and nearly two years [after] log4shell, 30% of the downloads are of the known vulnerable versions. This is supporting evidence that the large amounts of open source software is consumed without a defined process or awareness,” Brian Fox, co-founder and CTO at Sonatype, told SD Times. 

The OpenSSF End Users Working Group took on the task of manifesting the change they wished to observe. This initiative acted as a seed sown during meaningful discussions. Over time, this seed evolved into what is now the Open Source Consumption Manifesto.

“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,” OpenSSF stated in the blog post. “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.”

One of the key points in the manifesto includes improving open-source consumption via audit and quarantine functionality for components matching known vulnerabilities and malicious packages.

“The only way to counter the intentionally malicious component threat is to have systems in place to monitor what components are being consumed. Pairing that with data and behavioral feeds allows your systems to make real time decisions on if something should be allowed, or quarantined pending deeper analysis,” Fox added. “This can buy time for confirmation of actual malicious intent. I like to compare this to credit card fraud systems that evaluate your transactions in real time and make a judgment call to allow, deny or send you a text to confirm if a transaction is outside of your typical spending patterns.”

To begin their observability journey, organizations should first list their applications based on their importance. Following this, they should compile an inventory of the OSS used within those applications, often done through software bills of materials, and identify the different suppliers. Without these steps, addressing the 96% problem mentioned earlier is challenging. Many development teams currently lack these essential elements, according to Fox. 

Next, it’s advisable to pinpoint instances where you might be employing multiple suppliers for a single function, like using various logging frameworks. Following this assessment, organizations should determine the most suitable suppliers by evaluating their secure software development practices. This evaluation should consider factors such as known vulnerabilities, software age, popularity, average time for fixing issues, and more, he added. 

“Each organization will be different though, and will need to make its own choices based on the analysis above. However, there are some obvious points like finding known critical vulnerabilities in an application that manages PII data would be outside most risk tolerances,” Fox said. “With all of the above, you can build the foundation of an OSS consumption policy. But you’re only part of the way there. That needs to be integrated across the SDLC, from development to CI/CD, and often most importantly, release.”

The full list of points in the manifesto is available here.