Manage the Risks of Software Reuse

One of the key ways software development organizations drive efficiency is by drawing on libraries of existing, reusable software components when creating their own software products and services. This helps accelerate digital innovation, but the advantages come with a trade-off: Organizations accept, sometimes unknowingly, a degree of risk that can lead to serious cybersecurity issues.

That risk was highlighted in December 2021, when it came to light that a widely used open-source software framework called Log4j contained a critical vulnerability.1 The news made headlines because countless pieces of software deployed in organizations, government agencies, and people’s homes depend on this logging framework for the Java programming language. Security experts found that exploits built on the Log4Shell vulnerability, as it came to be known, could have devastating consequences for companies and individuals. And exposure to that vulnerability was found to be stunningly broad: The code had become embedded in software systems on a grand scale, introducing a serious vulnerability into many critical systems around the world. The Log4j exposure should be a wake-up call to executives to better understand software reuse and how to mitigate the risk of using it in their organizations.

Software reuse originated as an efficiency measure within large software companies and was mostly an internal undertaking involving home-built proprietary components. The advent of the internet and the explosion of open-source software transformed the practice. Today, most software is at least partially built on functionality acquired through external software components. These components are often shared for everyone’s benefit on open-source repositories, such as PyPI for Python, NPM for Node.js, and Maven Central Repository for Java, to name a few.

The main advantage for developers importing components from these repositories is that they do not have to assume ownership of the code or take responsibility for bug fixes or feature enhancements. Rather, they can concentrate on writing their own software while benefiting from the work of other teams of software developers. In addition, it is easier to import an entire package than to cherry-pick specific lines of code that will usually then need to be modified to fit into one’s own source code. A package is self-contained and built as a turnkey solution for reuse that can be treated like a black box by developers.