A New Take on Software Code Security: The Open Source Consumption Manifesto

Decades ago, Eric S. Raymond, one of open-source's founders, famously coined Linus's Law: "Given enough eyeballs, all bugs are shallow." Makes you feel warm and fuzzy about open-source security, doesn't it? There's a corollary, though. For Linus's Law to work, you need expert eyeballs hunting and hands fixing bugs. Recently, we've been forced to realize we've been flopping at enforcing the law. The Open Source Security Foundation (OpenSSF), with its new working group proclamation, the Open Source Consumption Manifesto (OSCM), wants to prosecute it.

For much too long, we blindly assumed the open-source code was safe. That was so naïve. Sure, most of it was sort of, kind of safe. It's not like anyone was targeting open-source projects with malware. That was Windows' problem. Now, every hacker on the planet is coming for it.

Just ask anyone using popular open-source repertories, such as Node Package Manager (npm) or Python Package Index (PyPI). These codebases are loaded with cryptominers and other kinds of malware.

Or, just keep half an eye open to major software security news headlines such as the Log4j and Log4J Shell. We're a year and a half into the Log4j security mess, and even though the patches are out there, the problems persist.

So, it behooves us to take open-source code consumption security seriously.

Inspired by the Agile Software Development Manifesto, which transformed software development and established a foundation for a more efficient development framework, the OSCM intends to solidify best practices in OSS consumption.

The OSCM, crafted after intensive discussions and insights from many disciplines, aims to address these security gaps. Emphasizing both values and guiding principles, the manifesto strives for secure and responsible open-source software (OSS) consumption.

Among its core tenets, the manifesto urges organizations to:

• Recognize the open-source code consumption's real risks.

• Establish open-source software consumption policies and test them against risk tolerance and other objectives.

• Adopt and refine tooling, best practices, and processes for tracking and enhancing the security of consumed OSS.

Specifically, all software developer organizations, should:

• 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 of 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.gSupply-chain Levels for Software Artifacts (SLSA), Secure Supply Chain Consumption Framework (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.

• 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 are critical to your project to report issues, fix bugs, support development, etc.

• Adopt tooling, best practices, and processes to (1) continuously track, monitor, 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., e Cybersecurity and Infrastructure Security Agency (CISA)'s Coordinated Vulnerability Disclosure (CVD), Vulnerability Exploitability eXchange (VEX), etc.).

That's a lot to take in. It's also, as the OpenSSF End User Working Group will tell you, anything but a final document. They openly invite feedback and participation from the community, urging professionals and organizations to sign the manifesto, suggest changes via pull requests on its GitHub repository and bring about a collective change in how OSS is consumed.

Frankly, while the work needs doing, I think they may be biting off more than they can chew. To successfully accomplish all this would require top-to-bottom commitment to policy changes from open-source communities, foundations, and companies. None of these are known for putting sufficient money, time, or effort into security.

On the other hand, this work isn't just a good idea anymore. It's a necessity. Major security breaches have become commonplace, and companies and the government are waking up and realizing these code problems must be addressed.

In August, at Black Hat 2023, Kemba Walden, the White House Office of the National Cyber Director (ONCD) acting director, said, "95% of our technology relies on open source. How we make it more secure is the fundamental question. How do we influence, encourage, and require memory-safe languages? Help us make smart policies about how to make open-source technology more secure.”

We must answer that call with our own words or the OSCMs. Otherwise, the US Federal government will do it for us via its new Open-Source Software Security Initiative (OS3I). This interagency collaboration aims to create policy solutions and allocate government resources to enhance OSS security.

Who would you rather have deciding? Personally, I'd rather see people who know open source inside out setting the policy. Or, at least be the ones debating and hammering it out, rather than a government bureaucracy.

Noteworthy Linux and open-source stories:

• Good-Bye Kris Nóva

• Debian Linux founder Ian Murdock would have been amazed at its legacy

• OpenTF: Disgruntled HashiCorp Rivals Threaten to Fork Terraform

• A license to trust: Can you rely on 'open source' companies?