Beware Of Zombie Code in Your Open-Source

by Fred Bals, senior software security technical writer and researcher within the Synopsys Cybersecurity Research Centre (CyRC)

Highlighting the critical need for improved maintenance practices among users of open source software, the new 2024 “Open Source Security and Risk Analysis” (OSSRA) report catalogues security concerns caused by the significant lag many organisations have in keeping the open source components they use up-to-date. The report reveals a bleak landscape where most commercial codebases contain outdated components, with 91% containing components that were 10 versions or more behind the most currently available version. Additionally, 49% of the codebases contained components with no development activity within the past 24 months.

2.1

Maintenance Matters in Mitigating Zombie Code Risk
Zombie code generally refers to portions of code that are no longer used or necessary for an application’s functionality but that remains within the codebase. There are many different flavours of zombie code, just like in zombie movies (think fast versus slow zombies, or “The Last of Us” fungi zombies versus traditional “Night of the Living Dead” braaains! zombies). Like the fictional undead, zombie code can appear when least expected, causing unforeseen complications. When it comes to open-source consumption, zombie code’s most significant danger is outdated code that has become vulnerable to exploitation.

Whether your organisation develops or uses software, there’s a near certainty that your software includes open source. According to the 2024 OSSRA findings, 96% of audited code contained open source. In some industries (including aerospace to telecommunications), 100% of the codebases contained open source. And in many sectors, significant percentages of the risk-assessed codebases contained high-risk vulnerabilities—including 87% in manufacturing and 50% in the Internet of Things sector.

By not updating an open-source component, consumers expose their applications to potential attacks that could exploit these vulnerabilities, leading to data breaches and other security issues.

With 91% of the risk-assessed codebases found to be using open source far behind the current version, the OSSRA report makes it clear consumers need to do better in keeping their code up-to-date, especially when it comes to popular open-source components. The consequences of using older, more vulnerable versions of open source can be grim. For example, #2 of the top 10 vulnerabilities reported in the 2024 OSSRA report is a cross-site scripting vulnerability that could be used to execute untrusted code. The issue was patched nearly four years ago with jQuery 3.5.0. But as the OSSRA data illustrates, a third of the codebases scanned for security risks were found to be using a jQuery version still open to exploit from that vulnerability.

Beyond security issues, out-of-date open source contributes to overall technical debt—bug and performance improvements missed, and compatibility issues that eventually need to be addressed. Over time, this technical debt can make applications more difficult and expensive to maintain, hindering their long-term viability and effectiveness. Zombie open source can potentially even have an impact on license compliance, as it may be difficult to obtain clarification or support regarding licensing terms for outdated or inactive components.

2.2

Three Steps To Improve Open-Source Maintenance Practices
Based on the OSSRA report’s findings, steps can be taken to improve open-source maintenance practices and mitigate the risks associated with zombie code.

• Implement automated tools: The use of automated tools, such as software composition analysis, can help identify outdated components and vulnerabilities. As the 2024 OSSRA report notes, there are on average more than 500 open-source components in any given application—a practical example of the importance of automated security testing. Manual testing becomes virtually impossible at scale and requires the use of an automated solution. Unlike manual processes, automated open-source testing and management can be executed quickly and consistently, allowing developers to identify issues early in the development process without impacting delivery schedules or productivity.

• Establish regular update cadences: Establishing regular cadences for updating open-source components can prevent the accumulation of outdated and potentially vulnerable zombie code. Set a regular cadence for upgrades, especially if you’re using open-source libraries from popular projects that have frequent maintainer activity.

• Create and maintain a Software Bill of Materials (SBOM): An accurate, up-to-date SBOM that inventories open source components is critical to ensuring that your code remains high quality, compliant, and secure. A comprehensive SBOM lists all the open-source components in your applications as well as those components’ licenses, versions, and patch status. For those without the resources to create an SBOM themselves, or who need to create an SBOM immediately, Synopsys SBOM Services can perform a full security audit of your software and generate an SBOM—valuable for organisations that do not yet have SBOM-generation capabilities and need an baseline SBOM for customer or regulatory compliance.

Remember, just like with fictional zombies, a single zombie open-source component can compromise all your defences and wreak havoc. Organisations that have open source in their software—which, as the 2024 OSSRA report shows, is literally all organisations—should proactively manage open source maintenance risk as a part of their secure software practices. Banishing outdated open-source software needs to be a top priority for every open-source consumer. The first step is examining your maintenance practices to see if they need improvement—before the zombies arrive.