When the Log4j vulnerability hit in early December, companies scrambled to figure out which applications and products used the logging library for Java. All of which serves as a reminder that companies need to get a better handle on the software components they use.
Turns out the footprint of Log4j is enormous. IBM, for example, documented more than 80 cloud services and 450 products impacted by the vulnerability. Amazon rolled out patches to more than 40 cloud services, including sensitive applications such as AWS Secrets Manager, AWS Lambda, and AWS Simple Storage Server (S3). Micro Focus had nearly 50 products affected by the bug.
Overall, the average company uses 25 software products known to be vulnerable to Log4j and the Log4Shell exploit, and fixing those issues will be challenging for many of them, Pedro Umbelino, principal security researcher at BitSight, wrote in an analysis in February.
"When patching an impacted application, all of its dependencies may not be obvious," he said. "Transitive dependencies—the dependencies of dependencies—make the situation even harder and patching more difficult. As a result, we believe that Log4Shell promises a patching cycle with a long tail of vulnerable applications—some of which may remain undetected for years."
The vast dependency trees of today's software are one reason that certain libraries and components—mostly published as open-source projects—have such a large impact. In fact, the average software application in 2021 relied on more than 500 open-source components, up from 298 in 2019. In the top four ecosystems—Java, JavaScript, Python, and .NET—3 million active projects currently support 37 million versions of open-source codebases, according to software supply-chain management firm Sonatype.
The failure to keep track of their developers' use of those project versions has left a significant vulnerability surface, said Brian Fox, chief technology officer for Sonatype.
"So many companies don't pay attention specifically to the components that are in the software that they are developing," he said. "Ninety percent of the modern application is third-party code, and most of it open source code. And while people are more aware, the fact remains that organizations don't have any kind of bill of materials for their applications."
While the US government has embarked on initiatives to improve policy around software bills of materials (SBOMs), and efforts such as the Open Source Security Foundation (OpenSSF) are seeking to identity critical infrastructure, companies need to take control of their own software component use. Here's how.
Know what you have
Finding vulnerable components is impossible if you do not know what software libraries and components are being used by your developers. Dependencies tend to hide a lot of vulnerabilities and are increasingly under attack by cybercriminals and nation-state actors, so gaining visibility into the indirect dependencies is extremely important.
Every company should generate an organization-wide SBOM to gain insight into what open-source projects they depend on, how many versions of each project they use, and which steps could have the most impact on minimizing future vulnerabilities.
"We have seen organizations using 81 of the 84 different versions of Spring across their portfolio," Sonatype's Fox said. That means "you are subject to pretty much every vulnerability that affects any version of that component." Once you gain visibility, you need to "determine what technologies you will continue to invest time and resources in, and divest from others," he added.
Reduce your patch surface area
Companies need to reduce the number of choices to some extent, otherwise they are increasing the odds that they will be impacted by a vulnerability, Fox said. While companies need to support innovation by keeping developers unfettered, allowing the volume of component-versions to grow brings complexity and vulnerability, he said.
"Looking at these physical supply chains, they don't let the assembly workers just randomly, willy-nilly, decide what is going into their vehicles," Fox said. So they don't have 800 different starter motors in their portfolio, but they do have relationships with specific vendors. "That's what it will take to solve the problems in software."
In addition, companies should jettison components whose maintainers do not quickly update codebases to fix security issues. The average mean time to update (MTTU) was estimated to be 28 days in 2021, a vast improvement over the 158 days it took to update open-source components in 2018.
Companies, however, should look for projects that perform better than average, because deep dependencies can result in delays to patching, since the software fix has to travel up the dependency chain. The average depth of the Log4j dependency, for example, is five layers, according to Google, meaning that five projects have to patch before a company's developers can update its own applications.
Use frequent threat modeling to understand supply chain weaknesses
In addition to reducing the number of components and the number of versions, and creating an organizational SBOM, companies need to analyze their development process to determine whether they are leaving pathways open to attack, said Yaniv Sayers, senior director and chief technologist of Micro Focus' application delivery management.
New attack vectors, such as dependency confusion, can be used to take advantage of the software ecosystem and compromise corporate applications.
"Attackers are becoming more sinister and sophisticated, actively integrating into the software ecosystem," Sayers said. "The industry and each organization should model their entire value stream to make sure they understand where their threats could come from."
Open the corporate wallet
Finally, organizations should support those projects whose software they use. In 2014, the Heartbleed vulnerability created significant issues for web servers and applications because the vulnerable software, OpenSSL, underpinned much of the encryption on the Internet. At the time, the OpenSSL project received annual donations of only $2,000 and had a single full-time programmer and a scant team of part-timers to maintain the project.
Unless companies support the programmers whose software components they use, the quality of open-source software and development process will remain uneven.
Keep learning
Learn from your SecOps peers with TechBeacon's State of SecOps 2021 Guide. Plus: Download the CyberRes 2021 State of Security Operations.
Get a handle on SecOps tooling with TechBeacon's Guide, which includes the GigaOm Radar for SIEM.
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed on cyber resilience with TechBeacon's Guide. Plus: Take the Cyber Resilience Assessment.
Put it all into action with TechBeacon's Guide to a Modern Security Operations Center.
