Cybersecurity experts agree open-source software (OSS) needs to evolve in some key areas, both concerning how organizations govern the OSS they consume and how the projects themselves are sustained.

The software industry has been leveraging open-source software for decades now, and to great effect. It’s estimated that 80% of modern software is comprised of open-source code. Yet, amid a string of software supply chain vulnerabilities, we’re beginning to see cracks emerge in this important global ecosystem. “We’re collectively waking up to the reality that open-source software isn’t without its risks,” says Chris Hughes, chief security advisor at Endor Labs.

While the argument can be made that openness allows more helpful eyes on software development, it does open the doors to contributors with malicious intent. This was underscored by the thwarted XZ Utils incident, in which a hacker used sly social engineering tactics over years to sneak a backdoor into the ubiquitous data compression library.

The open-source ecosystem has other issues, such as a lack of maintainer equity and relicensing concerns. But, the issue of trust arguably casts the darkest shadow. “The issue of ‘trust’ is a complicated problem to address sufficiently,” says Mehran Farimani, CEO of RapidFort. It’s a problem that must be studied deeply to build tools and processes to rectify weaknesses, he says.

For others, the current trials in open-source shouldn’t overshadow the immense strides the community has made. Instead, they should encourage leaders to double down on protecting this thriving field. “We need to acknowledge these immense benefits and continue to invest in OSS to grow the snowballing gains realized over fifty years of the open source movement,” says Zach Wasserman, co-founder of Fleet.

Responding to known vulnerabilities is a top priority for Brian Fox, Co-founder and CTO of Sonatype and OpenSSF Governing Board Member. “A key area where open source security needs to evolve is in the proactive identification of and action to address vulnerabilities,” he says. Surprisingly, 96% of all known-vulnerable open-source downloads are avoidable, according to Sonatype research. Yet, too many organizations sacrifice security for speed, meaning too many vulnerabilities go unaddressed.

At the same time, organizations can’t be expected to keep up with every single change. “We need to stop ‘everything needs to be patched, now,'” says Vincent Danen, vice president of product security at Red Hat. It’s essential to address critical issues, he says, but the maintenance burdens associated with comprehensive patching of low to moderate CVEs can bring unanticipated risks through constant change.

Much progress has been made with tools for automated CVE detection, reducing some burdens of vulnerability management. Ory Segal, CTO of Prisma Cloud, Palo Alto Networks, also highlights eBPF-based runtime security monitoring capabilities and underscores the need for continuous monitoring and AI-enabled runtime protection. That said, open-source vulnerabilities are a multifaceted issue that will require some shift-left thinking. “There are no shortcuts or silver bullets for solving this problem,” says Segal. “It all boils down to being more proactive and less trusting.”

Others agree that vulnerability management will require a more proactive strategy than a reactive one. “The current approach of fixing vulnerabilities reactively is not sufficient to mitigate threats,” adds Fox. For him, improving open-source security will rely on reliable automation. “Enterprises need the ability to quickly identify affected components and proactively mitigate risk by addressing any known vulnerabilities before they impact the system.”

The XZ vulnerability was only the tip of the iceberg, as more attempts have been reported targeting a popular JavaScript library. “The open nature of these repositories also makes them vulnerable to bad actors intentionally injecting malicious code,” says Fox. Unfortunately, the XZ hack likely was not an isolated incident, and OpenSSF is encouraging maintainers to watch out for similar long-game social engineering takeovers of other popular open-source projects.

Since adversaries are targeting OSS to compromise software supply chains, a greater focus on detecting malicious contributions is warranted. And, verifying contributors must go beyond the typical contributor reputation scoring systems. “Enhancing the security mechanisms to detect and prevent the inclusion of malicious code is paramount for maintaining the integrity and trustworthiness of open source ecosystems,” says Palo Alto Networks’ Segal.

Protecting components from abuse is an issue that’s difficult to solve. Yet, according to Ville Aikas, Founder of Chainguard, there are some proactive measures open-source maintainers can take, like asking questions to fully understand the reasoning behind complex contributions. “All the ‘non-fun’ things about software development are also important, even down to GitHub configurations, which should require reviews and other things,” he says. “If software artifacts are produced, make sure they have provenance attesting to where they came from.” Regarding helpful tools, Aikas points to Sigstore to verify project origins and bincapz to identify malicious behaviors.

Software governance has been a recurring theme recently, and setting guidelines for open-source usage is one way to prevent technology sprawl. “Open source security needs to evolve in the areas of consumption and governance,” says Endor Labs’ Hughes. “We need to implement governance around the OSS components we ingest and integrate into applications and products.” He adds that risk indicators could include the number of maintainers and contributors, repository hygiene, frequency of updates, and vulnerability remediation approaches.

As part of open-source governance, collaboration between open-source foundations and regulators will also be necessary to co-create cohesive cybersecurity processes, says Dirk-Willem van Gulik, VP of public policy and co-founder, Apache Software Foundation. “Software regulation such as the CRA in Europe and CIRCIA in the USA will help the industry in practical ways,” he says.

Yet regulation without enforcement won’t help secure the open-source ecosystem. Fox adds that for these measures to be successful, we’ll need more enforcement mechanisms and consequences for non-compliance to regulations and industry security standards.

Part and parcel of governance is proper inventory management. Yet, since open-source is so pervasively applied, building and maintaining a list of all the packages used can be challenging, says Jeremy Snyder, CEO of FireTail. This is made more difficult without a mature culture around software bill of materials (SBOM) practices.

SBOMs, as defined through standards like CycloneDX and SPDX, can supply comprehensive information about software products, helping to increase transparency and inform security responses. But to achieve these goals, organizations must make their SBOMs “actionable assets” rather than artifacts created purely out of obligation, says Sonatype’s Fox.

“I also suspect we will see a growing trend of consumers calling for increased transparency from software suppliers with regards to the OSS components in products and the associated risks of those components,” says Hughes. At the same time, the onus is on software consumers to make better risk-informed decisions. Organizations should better understand the risks of the components they integrate and empower developers with tools to help them make more informed decisions, he adds.

In addition to SBOMs, some also call for vulnerability management backed by service-level agreements. “By establishing clear SLAs to address identified vulnerabilities, teams can ensure timely responses and resolutions, fostering trust and accountability within the open-source ecosystem,” says Dr. Ratinder Paul Singh Ahuja, CTO and VP of Pure Storage.

Open-source foundations are helping to house core projects and are actively defining triage practices for OSS vulnerabilities. Yet, their efforts can only go so far. “Industry tooling and corporate investment in open source have not evolved in step,” says Apache Software Foundation’s Gulik.

This lack of investment hints at the larger reality — that open-source maintenance, in part, relies upon the contributions from unfunded, often hobbyist workers. “The initial authors may no longer support the project,” says FireTail’s Snyder. “No one supporting the project may be paid for their work, so it’s hard for users to require updates.”

Burnout was partially the reason Jia Tan, the account behind the XZ vulnerability, was able to put heavy pressure on the maintainer to conduct their nefarious efforts. “Security incidents such as XZ are a high-profile symptom of the underlying open source sustainability crisis,” says Chad Whitacre, Head of Open Source at Sentry. “Open source is like a restaurant, and most companies dine and dash.”

Similar to climate pledges, a collective crisis needs a collective response, says Whitacre. To correct the sustainability crisis in open-source, he highlights efforts like tax-based approaches, such as The Sovereign Tech Fund, and revenue-sharing approaches, such as the Ecosystem Sustainability Program (ESP) proposed by OpenJS Foundation. The positive effect of funding on open-source security isn’t just smoke and mirrors. Interestingly, a recent study that analyzed one thousand popular open-source projects found a correlation between higher funding and a better overall security posture for open-source projects.

A 2024 report from Synopsys estimates there are an average of 500+ open-source components per application. Software systems are vast, with an ungodly number of moving pieces, says RapidFort’s Farimani. In this reality, “bugs are just a fact of life and are here to stay,” he says.

Although much progress has been made regarding bug detection systems and bounty programs, errors and zero-day vulnerabilities are bound to slip through the cracks. The state of vulnerabilities requires organizations to make more conscious decisions about the components they take on — a more “risk-informed consumption and use of OSS components,” says Endor Labs’s Hughes.

Yet, according to Red Hat’s Danen, vulnerability remediation shouldn’t live in a vacuum. “Everything is contextual, and security is no different,” he says. Therefore, he reiterates the need to take a risk-based approach. “IT is too complex to patch everything. With a risk-based perspective, we can be better prepared to handle the exploits that have the real potential to impact our operations.”

Other experts feel we need to go a step further down the stack to implement security controls at the hardware level. Gavin Ferris, CEO of lowRISC, recommends foundational security measures grounded in silicon. “A Silicon Root of Trust anchors the chain of trust in the silicon below the OS and ensures the overall reliability of the computing environment,” he says.

96% of over one thousand commercial codebases analyzed in the Synopsys report mentioned above contain open-source software. Since open source is so deeply ingrained into modern software practices, it will take continual efforts to identify threats and protect this complex, intermeshed ecosystem. “Open-source security is evolving rapidly, with a heightened emphasis on fortifying the software supply chain,” says Pure Storage’s Ahuja.