Open source leaders recently called for permanent government funding to maintain open source projects. In their eyes, just as government involvement is essential for ensuring the upkeep of the national energy grid, so too is government oversight of open source software.
The reason behind this call to action is the idea that maintenance of open source software is one of, if not the, principal factors in determining open source security. It’s true that maintaining open source projects is essential, and it’s true that maintainers are drastically underfunded. It’s also true that there are clear benefits to funding and government oversight.
But the industry focus we see today on maintainers ignores the evidence at the root of the issue - consumers of open source, not maintainers, are the main problem. And this largely stems from the fact that those consumers have no idea what open source software they’re even using to begin with.
Brian Fox is CTO at Sonatype.
Open source is not the problem…
Let’s start by clarifying something: Big Tech companies are already heavily invested in maintaining open source because it’s in their interest to. Open source software is essential in today’s business environment. It’s also everywhere, in 80-90% of modern enterprise software.
That’s why Big Tech companies have hired maintainers to work on many of the largest open source projects out there. These same companies donate funding to sponsor foundations and non-profits helping to secure many of the world’s most popular open source projects. A few of these foundations include the Linux Foundation, The Apache Software Foundation, The Open Source Security Foundation, the Eclipse Foundation, and many more.
They even collaborate with competitors in the process. There’s no harm to themselves in doing this, because even if Microsoft or Google maintain or contribute open source components to a public repository accessible by rivals, it’s not likely to impact them competitively. Many commonly maintained open source projects focus on important but ultimately benign capabilities like a logging framework - not something that would ever be considered a competitive differential.
Sharing common basic tools benefits the talent pool and enables better innovation. Contribution back upstream even helps reduce downstream defects: by contributing to a project earlier, especially in relation to code quality, you reduce the risk of vulnerabilities later on. All these benefits are why we all fell in love with OSS in the first place.
To be very clear, all this funding and collaboration doesn’t inherently make open source better or more secure, but it does illustrate to those calling for more maintainers that open source already has the backing of private companies.
In fact, even with Big Tech’s involvement, it’s still open season on open source, a notion supported by research findings showing a 742% average rise in software supply chain attacks in the last three years. Why is this happening?
For context, threat actors are becoming more sophisticated in their efforts to abuse open source ecosystems. Seemingly benign files – the names and formats of which raise no obvious red flags, posted on the likes of PyPI and npm – are initially being cleared by most antivirus products, only to wreak havoc once the components have been downloaded into organizations' tech stacks. Earlier this year, we even saw the first official case of one software supply chain attack directly causing another during a breach at VoIP company 3CX.
But the biggest reason for this rise in attacks is this: consumers are the problem. The very people and enterprises consuming open source software are making incredibly poor decisions about what they’re downloading.
To understand this, we need only look back at one of the biggest open source vulnerabilities ever.
Companies don’t know what’s in their software
A critical vulnerability in an extremely popular logging framework, Log4j, sent shockwaves through the open source ecosystem. Experts from across the industry united in the view that the flaw posed the greatest threat to the Internet since a similar vulnerability brought down Equifax in 2017. Such was the concern around the vulnerability that Apache fixed the issue in a matter of days. Despite this, 30-40% of downloads are still of flawed versions more than 18 months later.
And it’s not like it’s just Log4j, because currently, 96% of the time that people download an open source software component, there’s a safer or better version available.
There’s no excuse for this. The reason it keeps happening is that companies consuming open source are not making intentional decisions about what they’re downloading, or who from. Funding will not solve that.
That is not to say funding has no role to play at all. More and better-funded education would alleviate many bad industry practices, but it would take a long time before we see behaviors shift as a result. Organizations can save a lot of time and effort by deploying the right tools to gain better visibility of the open source components that make up their software. This way, when vulnerabilities or malware are flagged, developers can remediate them before bad actors strike, or update to a safer version before ingesting them in their software development life cycle.
Lessons from food hygiene
There’s a mistaken and potentially harmful tendency to think of vulnerable open source in the same way that we might think of an E. coli contamination in lettuce, even though there’s a huge difference between vulnerable open source and malicious open source. E.coli outbreaks are the latter, whereas the former is more akin to peanut allergies.
So, what do we mean by malicious open source? Malicious components are planted by bad actors to intentionally infect software with damaging code. When detected, these are taken down immediately and flagged as harmful. In food terms, a contaminated batch of lettuce that causes someone to become unwell would immediately be removed from the shop floor.
Vulnerable components, on the other hand, might exist in repositories, and probably within organizations’ tech stacks, for years before anyone even realizes they are flawed. To return to the peanut analogy, some people suffer from peanut allergies, which can prove fatal, but for most people, consuming peanuts will have no ill effects. Despite being potentially lethal, peanut factories continue to mass produce their products and most convenience stores and supermarkets continue to stock peanuts. They certainly wouldn’t be removed from the shelf!
This distinction is important because not all vulnerabilities are universally dangerous to everyone. This was even true of the Log4Shell vulnerability. Despite its criticality, there were specific conditions where it wasn’t exploitable. For instance, if it was running on a certain JVM, it could just sit there, inert. That’s because, sometimes, there are mitigating controls, or the affected part of the software isn’t active.
In cases like this, it doesn’t make sense to suggest taking down a component containing a vulnerability from every repository, website or digital product of which it is a part. It’s a weakness, not malware. Manufacturers wouldn’t obliterate a component from the entire supply chain if it worked perfectly fine within a car, but not in a rocket ship. This is how people should think about vulnerabilities within open source software.
Pick better projects
For our industry to improve its software hygiene, developers and businesses must be intentional about which open source projects they download from.
Obviously, you can’t avoid every vulnerability. Any security professional knows that this shouldn’t be a goal anyway. But what developers can do is to deliberately consume those larger projects with the most maintainers and the healthiest ecosystem of contributors. Anyone choosing to consume a project maintained by an anonymous individual who only works on the weekend is acting irresponsibly.
Ultimately, responsible consumption of any open source project comes down to several factors, like who is providing it, how often it is updated or contributed to, what the mean time to remediation looks like, what their vulnerability disclosure process entails, etc. These are the nuances people have to recognize to make ‘intentional decisions.’ Addressing the challenges in open source security and sustainability requires a multifaceted approach that involves better education, responsible consumption, and industry collaboration.
By recognizing the role of consumers in the open source ecosystem and making informed choices, instead of relying wholly on the oversight of maintainers, the industry can strengthen the security and reliability of open source software for the benefit of all.
