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.
Get Updates on Leading With AI and Data
Get monthly insights on how artificial intelligence impacts your organization and what it means for your company and customers.
Please enter a valid email address
Thank you for signing up
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.
1. “CVE-2021-44228,” Mitre, accessed Dec. 12, 2021, https://cve.mitre.org.
2. M. Sojer and J. Henkel, “Code Reuse in Open Source Software Development: Quantitative Evidence, Drivers, and Impediments,” Journal of the Association for Information Systems 11, no. 12 (March 2010): 868-901.
3. T. Mikkonen and A. Taivalsaari, “Software Reuse in the Era of Opportunistic Design,” IEEE Software 36, no. 3 (May-June 2019): 105-111.
4. D. Goodin, “Malicious NPM Packages Are Part of a Malware ‘Barrage’ Hitting Repositories,” Ars Technica, Dec. 8, 2021, https://arstechnica.com; A. Sharma, “Dev Corrupts NPM Libs ‘Colors’ and ‘Faker’ Breaking Thousands of Apps,” Bleeping Computer, Jan. 9, 2022, www.bleepingcomputer.com; and A. Miller, “State of Open Source Security Report 2020,” PDF file (Boston: Snyk, 2020), https://go.snyk.io.
5. T. Seals, “‘Ripple20’ Bugs Impact Hundreds of Millions of Connected Devices,” Threatpost, June 16, 2020, https://threatpost.com.
6. C. Soto-Valero, N. Harrand, M. Monperrus, et al., “A Comprehensive Study of Bloated Dependencies in the Maven Ecosystem,” Empirical Software Engineering 26, no. 3 (March 2021): 1-44.
7. H. Solomon, “Canadian Websites Temporarily Shut Down as World Scrambles to Mitigate or Patch Log4Shell Vulnerability,” IT World Canada, Dec. 13, 2021, www.itworldcanada.com.