The Growing Problem of Legacy Open Source

As open source use has gained traction over the years, managing that open source has also evolved. Organizations initially concentrated their efforts on open source license identification—still a key part of any open source management strategy. As open source grew in popularity, a risk beyond license risk emerged: identifying and mitigating known vulnerabilities, another critical factor of responsible open source management.

Today, as Gartner analyst Dale Gardner writes in his paper, “Technology Insight for Software Composition Analysis,” “Mature organizations are expanding open source management

to include assessments of the overall ‘health’ of the software, based on a given package’s provenance and support.”

Open source has not escaped the problem of legacy technology

One of the reasons behind the popularity of open source is that viable open source projects usually have strong communities improving, updating, and patching vulnerability issues as they become known. But many developers don’t bother to initially vet the health of a community before downloading an open source component. And even when a developer takes care to download components from robust open source communities, there’s no guarantee the community will remain active in maintaining that component or the specific version that a developer has downloaded.

Open source has not escaped the problem of legacy technology. In fact, many organizations are startlingly behind in using the latest version of any given open source component. As reported in the 2020 Open Source Security and Risk Analysis (OSSRA) report published by the Synopsys Cybersecurity Research Center (CyRC), 88% of the codebases in the OSSRA audits had open source components with no development activity in the last four years.

All software ages. As it ages, it loses support. With open source, the number of developers working to ensure updates—including feature improvements, as well as security and stability updates—decreases over time. Without the support needed to provide fixes, at some point as an open source component ages, it’s likely to break—or open a codebase to exploit.

Infrequency of updates can lead to security issues that exist in the codebase for more than 20 years, as was the case with PuTTY SSH, an open source network file transfer application. The two-decades-old vulnerability was only spotted in June 2019 and publicly disclosed in September. You might ask how dangerous a vulnerability that remained undiscovered for over twenty years could be, but older open source tools such as PuTTY often have seldom-used features containing vulnerabilities that could allow a malicious actor intent on discovering them to open a codebase to exploit.

The open source community usually issues small updates at a much faster pace than the average commercial software vendor. When these updates contain security updates, companies need to have a strategy to adopt them rapidly. But because open source updates need to be “pulled” by users, an alarming number of companies consuming open source

components don’t apply the patches they need, opening their business to the risk of attack and their applications to potential exploits. Eighty-two percent of the OSSRA report’s 1,253 audited codebases had open source components more than four years out of date.

The “insert and forget” syndrome

Besides adding to security risk, the danger of getting too far behind in versioning is that the simple act of updating to the latest version can introduce unwanted functional changes, such as the disappearance of key features. Development teams may also be concerned that using a newer version of an open source component will require modifying other code, causing a ripple effect that could bring development to a standstill.

But rather than the result of a conscious decision, many of the outdated components in use are the result of an “insert and forget” mindset. Developers typically don’t add version information about a component to the inventory spreadsheet before moving on to other work. Then, as long as the code continues to function as it’s supposed to, it’s ignored and eventually forgotten—until it breaks or is attacked.

The need for a software bill of materials

Whether age or versioning, you can’t address open source legacy issues without an up-to-date, accurate software inventory—a.k.a. a software “bill of materials” or BOM. More than an inventory spreadsheet, a comprehensive software BOM should include all open source components, the versions in use, and download locations for each project in use or in development. The BOM should also include all dependencies, or the libraries your code is calling to, as well the libraries those dependencies are linked to.

The concept of a BOM derives from manufacturing, where the classic bill of materials is an inventory detailing all the items included in a product. In automobile manufacturing, when a defective part is discovered, the manufacturer knows precisely which vehicles are affected and can begin the process of repair or replacement. Similarly, maintaining an accurate, up-to-date software BOM that includes an inventory of third-party and open source components is necessary for organizations to ensure the open source components they’re using are high quality, compliant, and secure. And, as in manufacturing, a complete BOM of open source components allows you to pinpoint problematic components quickly and prioritize remediation efforts appropriately.