By David A. Wheeler (The Linux Foundation) and Georg Kunz (Ericsson)
The Open Source Security Foundation (OpenSSF) Best Practices Working Group has released the new guide Simplifying Software Component Updates. This guide gives software producers and consumers practical steps to simplify component compatibility. Applying the principles in this guide will eliminate many vulnerabilities in software. To understand why, it’s necessary to understand modern software development practices.
Modern software systems are mostly reused software. Studies show that, for example, the average percentage of open source software (OSS) in software applications is somewhere between 70% [Black Duck 2025] and 90% [Sonatype 2024], often with thousands of OSS components. Reusing software, instead of rewriting everything from scratch, has made it possible to create far more sophisticated software at an accelerated pace. Reuse can often improve security: if components are developed with security in mind, they’ll often be better analyzed than bespoke software. If a vulnerability is found, the vulnerability can in theory be rapidly fixed through a component update.
Upstream developers typically focus on adding new features, generalizing capabilities, and fixing bugs in newer versions of components. Unfortunately, these newer versions’ interfaces are sometimes unnecessarily incompatible with older interfaces. This leads to many or most of their downstream users being stuck on older versions of the software for long periods or perhaps forever. One study found that 90% of analyzed codebases contain OSS components that are more than 10 versions behind [Black Duck 2025]. When a vulnerability is found—and inevitably one is—the vulnerability is fixed in the “current” component version (upstream), but many users of that software will remain vulnerable because it’s impractical for them to update to the current version.
Decades ago, when applications reused at most a few software components, this could sometimes be addressed by heroic efforts to update the software to use the newer component that provided a different interface. Nowadays this kind of heroic effort to deal with interface changes is completely impractical. When you’re using many components, it becomes increasingly difficult to keep components up to date if their interfaces keep changing.
Backward-incompatible changes are also increasingly problematic because most software components are used indirectly. When there are many layers of dependencies, it takes time for each layer’s updates to trickle up, introducing a sort of “speed of light” rate limit for updating software components. Any delay in updating any intermediate layer impedes updates of all transitive users. For example, [Wetter2021] found in response to the Log4Shell vulnerability that “most artifacts that depend on log4j do so indirectly. The deeper the vulnerability is in a dependency chain, the more steps are required for it to be fixed. […] For greater than 80% of the packages, the vulnerability is more than one level deep, with a majority affected five levels down (and some as many as nine levels down).” The majority of applications contain over 180 dependencies and components [Sonatype 2024], making it a herculean task to track, update, and maintain dependencies. This is one reason why it takes an average of 55 days to remediate 50% of critical vulnerabilities once patches are available, with 8% of the critical vulnerabilities not being addressed within one year [Verizon 2024].
As a result, backward-incompatible changes to an application programmer interface (API) often lead to unaddressed security vulnerabilities.
This issue was identified during the OpenSSF Policy Summit DC 2025 of 2025-03-04. In fact, we know this issue has been repeatedly discussed in various fora. We thought it was time to start addressing this problem.
The basic solution is obvious: we want to strongly encourage component creators to make it easier to update components, in particular, by avoiding backward incompatibility problems wherever practical. Component users also need to make it easier to update components, e.g., by using package managers, having automated tests to verify that software with updated components will continue to work, and avoiding downstream modifications which require adaptation to new versions. Both sides—component creators and component users—have important roles to play. We believe creators and users can collaborate to simplify keeping components up-to-date.
This new guide explains why it’s important to simplify software component updates. More importantly, it provides a variety of specific tips to make this practical for both producers and consumers of software.
For more information, see the new guide Simplifying Software Component Updates.
Join the OpenSSF Best Practices Working Group to provide feedback on this guide or contribute to any of the other efforts of the working group.