Securing Open Source in 2025 and Beyond: A Roadmap for Progress

It’s been over three years since Log4Shell, a critical vulnerability in a little-known open-source library, was discovered. With a CVSS score of 10, its relative ubiquity and ease of exploitation singled it out as one of the most serious software flaws of the decade. But even years after it was patched, more than one in 10 downloads of the popular utility are of vulnerable versions. Something is clearly wrong somewhere.

A new report from the Linux Foundation has some useful insight into the systemic challenges facing the open-source ecosystem and its users. Unfortunately, there are no easy solutions, but end users can at least mitigate some of the more common risks through industry best practices.

A Catastrophic Case Study

Open-source software components are everywhere—even proprietary code developers rely on them to accelerate DevOps processes. According to one estimate, 96% of all codebases contain open-source components, and three-quarters contain high-risk open-source vulnerabilities. Given that approaching seven trillion components were downloaded in 2024, this presents a massive potential risk to systems across the globe.

Log4j is an excellent case study of what can go wrong. It highlights a major visibility challenge in that software doesn’t just contain “direct dependencies” – i.e., open source components that a program explicitly references—but also transitive dependencies. The latter are not imported directly into a project but are used indirectly by a software component. In effect, they’re dependencies of direct dependencies. As Google explained at the time, this was the reason why so many Log4j instances were not discovered.

“The deeper the vulnerability is in a dependency chain, the more steps are required for it to be fixed,” it noted.

Sonatype CTO Brian Fox explains that “poor dependency management” in firms is a major source of open-source cybersecurity risk.

“Log4j is a great example. We found 13% of Log4j downloads are of vulnerable versions, and this is three years after Log4Shell was patched,” he tells ISMS.online. “This is not an issue unique to Log4j either – we calculated that in the last year, 95% of vulnerable components downloaded had a fixed version already available.”

However, open source risk isn’t just about potential vulnerabilities appearing in hard-to-find components. Threat actors are also actively planting malware in some open-source components, hoping they will be downloaded. Sonatype discovered 512,847 malicious packages in the main open-source ecosystems in 2024, a 156% annual increase.

Systemic Challenges

Log4j was just the tip of the iceberg in many ways, as a new Linux report reveals. It points to several significant industry-wide challenges with open-source projects:

Legacy tech: Many developers continue to rely on Python 2, even though Python 3 was introduced in 2008. This creates backwards incompatibility issues and software for which patches are no longer available. Older versions of software packages also persist in ecosystems because their replacements often contain new functionality, which makes them less attractive to users.

A lack of standardised naming schema: Naming conventions for software components are “unique, individualised, and inconsistent”, limiting initiatives to improve security and transparency.

A limited pool of contributors:

“Some widely used OSS projects are maintained by a single individual. When reviewing the top 50 non-npm projects, 17% of projects had one developer, and 40% had one or two developers who accounted for at least 80% of the commits,” OpenSSF director of open source supply chain security, David Wheeler tells ISMS.online.

“A project with a single developer has a greater risk of later abandonment. In addition, they have a greater risk of neglect or malicious code insertion, as they may lack regular updates or peer reviews.”

Cloud-specific libraries: This could create dependencies on cloud vendors, possible security blind spots, and vendor lock-in.

“The biggest takeaway is that open source is continuing to increase in criticality for the software powering cloud infrastructure,” says Sonatype’s Fox. “There has been ‘hockey stick’ growth in terms of open source usage, and that trend will only continue. At the same time, we have not seen support, financial or otherwise, for open source maintainers grow to match this consumption.”

Memory-unsafe languages: The adoption of the memory-safe Rust language is growing, but many developers still favour C and C++, which often contain memory safety vulnerabilities.

How ISO 27001 Can Help

As Red Hat contributor Herve Beraud notes, we should have seen Log4Shell coming because the utility itself (Log4j) had not undergone regular security audits and was maintained only by a small volunteer team, a risk highlighted above. He argues that developers need to think more carefully about the open-source components they use by asking questions about RoI, maintenance costs, legal compliance, compatibility, adaptability, and, of course, whether they’re regularly tested for vulnerabilities.

Experts also recommend software composition analysis (SCA) tools to enhance visibility into open-source components. These help organisations maintain a programme of continuous evaluation and patching. Better still, consider a more holistic approach that also covers risk management across proprietary software. The ISO 27001 standard delivers a structured framework to help organisations enhance their open-source security posture.

This includes help with:

• Risk assessments and mitigations for open source software, including vulnerabilities or lack of support
• Maintaining an inventory of open-source software to help ensure all components are up-to-date and secure
• Access controls so that only authorised team members can use or modify open-source software
• Security policies and procedures on the use, monitoring and updating of components
• Supplier relationship management to ensure open source software providers adhere to the security standards and practices
• Continuous patch management to address security vulnerabilities in open-source software
• Incident management processes, including detection and response to vulnerabilities or breaches stemming from open-source
• Promotion of a continuous improvement culture to enhance the effectiveness of security controls
• Training and awareness for employees to understand the risks associated with open-source software

There’s plenty more that can also be done, including government bug bounty programmes, education efforts and community funding from tech giants and other large enterprise users of open source. This problem will not be solved overnight, but at least the wheels have started turning.