What’s Wrong with Open Source, and How to Fix It

Phil Muncaster investigates how a multi-stakeholder approach could help to plug some serious open source security gaps

Open source software has eaten the world. There were an estimated 6.6 trillion+ downloads of open source components in 2024. Today, free and open source software (FOSS) powers everything from the mobile devices we carry around with us, to the latest cutting-edge AI tools. However, the industry is also challenged by continued opacity, lack of financial support and aggressive malicious activity. Security risk is everywhere, and as the Log4Shell and xz Utils incidents showed, it could have a significant impact on both the digital and physical world.

This is why the latest report from the Linux Foundation makes for interesting reading. It offers a rigorous analysis of the current open source ecosystem, to help readers understand what type of FOSS is in use today, and how well it is supported and maintained. From this, we can start to work out where the key risks are, and what to do about them.

Shining a light on FOSS

As the report admits, assessing the health of the FOSS ecosystem isn’t easy. Although it’s estimated that as much as 96% of all codebases contain FOSS, there are tens of millions of highly decentralised and distributed projects underway around the world. And as this type of software is often copied and modified, it’s unclear exactly what’s being used, and in what volume. Yet visibility of this sort is the crucial first step towards improving security across the ecosystem.

“The industry is challenged by continued opacity, lack of financial support and aggressive malicious activity”

In this context, Census III of Free and Open Source Software is an invaluable attempt to shine a light on the industry. It’s based on scans of software codebases at thousands of customers of Software Composition Analysis (SCA) vendors like Snyk, Sonatype, FOSSA and Black Duck. There are over 12 million of these data points; providing a useful analysis of how FOSS is used, and where security risk is most pronounced.

A risky business

Among the main cybersecurity risks outlined in the report are:

Reliance on the legacy Python 2 language:

Despite Python 3 coming online in 2008, in some disciplines like data analysis and computer graphics, over a quarter of Python developers use the older version. The report warns that this could result in “potential security risks from backwards incompatibility,” as Python 2 is no longer supported, meaning no more patches are available.

“This exposes systems to known vulnerabilities and reduces overall security,” Snyk head of developer and security relations, Randall Degges, tells Assured Intelligence. “Unsupported software poses a significant risk as security vulnerabilities are no longer addressed. This increases the attack surface for supply chain compromises.”

A lack of standardised naming schema for software components:

The report describes naming conventions for software components as “unique, individualised, and inconsistent”, meaning that initiatives to boost software security and transparency will have limited effect. For example, CVEs can’t be mapped in a machine-processable way to the software containing the vulnerability, meaning CVE users have to guess the affected component.

“Inconsistent naming slows vulnerability tracking and software bill of materials (SBOM) creation efforts,” says Degges. “This hinders automated tools and research efforts from identifying vulnerable components across systems. It reduces visibility into the software supply chain.”

Too few FOSS contributors:

“The perception of open source software as something built and maintained by millions of developers is, unfortunately, mistaken.”

The perception of open source software as something built and maintained by millions of developers is, unfortunately, mistaken. The report finds that only a handful of people most of the time work on any given project. Of the top 50 non-npm projects assessed, 40% had just one or two developers accounting for more than 80% of commits. Fewer contributors may mean security issues being missed during development, and/or not remediated quickly enough.

Individual developer account security challenges:

Many of the Top 500 packages assessed in the report are hosted under individual developer accounts. That’s a potential risk, as they usually have fewer protections associated with them than accounts linked to organisations. They do not have the same “granularity of permissioning and other publishing controls”, meaning code changes are much easier to make. And developers may forget to switch on multifactor authentication (MFA).

The report warns that account takeovers are increasingly common, via techniques like “backdooring” – where attackers insert malicious code into legitimate-looking packages that create a backdoor once the host package is installed.

“A project with a single developer has a greater risk of later abandonment,” OpenSSF director of open source supply chain security, David Wheeler, tells Assured Intelligence. “In addition, they have a greater risk of neglect or malicious code insertion, as they may lack regular updates or peer reviews.”

Legacy software is still everywhere:

Older versions of software packages continue to persist in the FOSS ecosystem. That’s because replacements often contain different APIs, different functionality and/or compatibility bugs, making them less attractive for users. The challenge is that the number of developers working on security and stability updates decreases over time, meaning legacy software is “more likely to break with each passing day”, and contain unfixed vulnerabilities and other issues.

Cloud-specific packages:

“Cloud-specific libraries like boto3 (AWS) and Google Cloud Go are increasingly used, creating dependencies on cloud vendors and potential security blind spots,” says Snyk’s Degges. “An over-reliance on cloud-specific packages introduces vendor lock-in and requires focused security efforts around these ecosystems.”

Memory-unsafe languages:

“Safety vulnerabilities in C/C++ persist. The adoption of Rust, a memory-safe language, is growing, but it still represents a small fraction of overall usage,” explains Degges. “Memory safety vulnerabilities continue to account for a high percentage of software exploits, highlighting the need to transition to safer languages.”

Time to improve open source security

Given the scale of the challenge, enhancing the security posture of the entire FOSS ecosystem won’t be easy. Experts agree that change must be driven by government, large enterprise users and the open source community itself.

“There’s a variety of ways to approach these problems, but they all start with a multi-stakeholder approach. The open source community, alongside government and industry stakeholders, must act collectively to secure this foundational layer of modern technology,” Sonatype CTO, Brian Fox, tells Assured Intelligence.

“On a larger scale, increased funding is crucial to support maintainers and enhance the security of critical projects. Incentives, whether financial or through recognition, can alleviate the pressure on maintainers.”

There’s also a role for governments and organisations in pushing for standardised naming schemas, such as Package URLs (pURLs), to improve supply chain transparency and vulnerability tracking, he adds. But CISOs must also play their part.

“Organisations must reevaluate their approach to open source software usage,” Fox continues. “There has to be improvement in consumption practices and dependency management. Automation is a great tool to lessen the dependency management burden on developers.”

“Collaborative teams are less prone to neglect and benefit from diverse perspectives”David Wheeler

OpenSSF’s Wheeler wants to see faster adoption of memory-safe programming languages like Rust, to reduce vulnerabilities like buffer overflows often seen in C and C++ code.

“Governments and industry stakeholders can support this by funding training programs and encouraging the use of these languages in high-risk areas such as operating system kernels and network-exposed libraries,” he adds. “They could also help ensure memory-safe system programming languages are available for more platforms.”

A shift from single-maintainer projects to more collaborative teams would also reduce security risk and reduce the chance of maintainer burnout, says Wheeler.

“Collaborative teams are less prone to neglect and benefit from diverse perspectives. It can be a challenge to get involved in a project,” he argues. “Organisations like OpenSSF can facilitate this through training, guidance, and tools. We encourage organisations to support critical OSS projects by funding them or having their developers join these projects.”

Finally, greater adoption of SBOMs would help shine a light on code composition and efforts to address vulnerabilities.

“As regulatory requirements increasingly emphasize SBOM adoption, organisations must ensure transparency about their OSS components,” Wheeler concludes. “Adopting standardised SBOM formats can help businesses meet compliance requirements and better mitigate supply chain risks.”

Thanks to the Census III report, the scale of the FOSS security challenge has at least been identified. Now it’s time to do something about it.