The recent Log4j vulnerability has exposed systemic problems in how businesses, and the community at large, audit their software.

Early indications show the Log4j vulnerability was being weaponized and exploited days before the news broke about its existence. Organizations needed to take action immediately to find all instances of the vulnerability in linked libraries, but most had no clear overview of where such instances existed in their systems. Google’s own research showed that more than 8% of all packages on Maven Central have a vulnerable version of Log4j in their dependencies, but of that group only a fifth declared it directly. This means that around 28,000 packages on Maven Central are affected by these bugs while never directly declaring or using Log4j.

Finding all instances of vulnerable dependencies and confirming patch levels can be a daunting task, even for software you completely control and develop in house. Identifying it in your vendors can be even more difficult. Oftentimes, these vendors have just as murky an idea of their own dependencies.

Like any other IT assets such as servers, laptops, or installed applications, having an accurate inventory of your software and dependencies (both direct and transitive) is an essential, and arguably the most fundamental, security control you can apply. Businesses cannot secure what they are not aware of. How do companies begin to take control of the growing complexity of dependencies? By auditing and automating dependency graphs, beginning with direct dependencies and expanding to the transitive ones, often referred to as a software bill of materials (SBOM).

While there is nuance to the discussion about what an SBOM should be and contain, for the purposes of this article, we will simply refer informally to an SBOM as a manifest of all components and libraries packaged with an application, along with their licenses. This includes tools and linked libraries. If you are delivering a Docker image, it should also include the list of all installed packages.

Getting serious about your software supply chain