Log4j Highlights the Need for a Software Bill of Materials; Here’s How to Create One

Just days into the new year and the cybersecurity community is already playing catch up thanks to the recent Log4j vulnerability which illuminated major setbacks in how organizations deal with its own software and open-source packages on which its relies on.

In particular, organizations have been caught off guard in auditing its own systems, giving hackers a significant head start to take advantage of the flaw.

Asset inventory is ground zero for cybersecurity control. Even though it’s the most basic thing for an organization to do as a form of inventory, the landscape lacks comprehensive solutions and tools to streamline the process of dependency management, a technique for identifying, resolving and patching dependencies in an application’s codebase.

In most cases, this is because of a conscious choice in our programming languages to prioritize novel features over basic security optimizations such as improving dependency management. Older languages which lacked the awareness of dependency management as a security issue are still in wide use, while newer ones have skirted the issue to varying degrees.

With supply chain attacks on the rise and typosquatting on popular packages increasing, it is more important than ever that companies prioritize dependency management by creating a software bill of materials (SBOM).

An SBOM is a complete catalog of all components, libraries and licenses within an application package, including tools, linked libraries and all installed packages for Docker images.

This isn’t just a “nice to have” but will become a requirement under the latest Executive Order on Improving the Nation’s Cybersecurity.

A fundamental, applicable security control, the SBOM provides a reliable manifest of software and dependencies (both direct and transitive) which allows organizations to identify and resolve issues faster. Here’s how to create one:

Secure C-Suite Buy-In

Before starting development, it’s important to help leaders in an organization understand the inevitability of future widespread security threats. In the same way that major vulnerabilities such as Heartbleed (2014) and Spectre/Meltdown (2018) exposed systemic problems with our cryptography and hardware, Log4Shell is begging us to reckon with our supply chains being impacted by ubiquitous libraries we may not even be aware we depend on.

Download: Your Guide to Business Continuity Planning

A complete, up-to-date and accurate SBOM will reduce the time and resources required to triage risk exposure when future vulnerabilities are discovered. Should leadership need more convincing, it’s helpful to keep in mind that in the CIS benchmark controls, widely considered a highly authoritative standard, inventory of software is second only to hardware.

Start With An Inventory

With leadership on board, the first step to creating an SBOM is listing all in-house software, containers and third-party vendor packages or applications used by an organization.

Often organizations are lacking even a basic list of things they have purchased, developed, or used directly. This step alone is low-hanging fruit and will provide immediate benefits.

Once this is finished, teams can identify direct dependencies, followed by transitive dependencies to round out creating a comprehensive inventory of their software and dependencies.

Choose an appropriate tool for your language

Since Log4j is the topic of the day, I recommend practicing this skill by selecting a Java project using a vulnerable version and generating a dependency manifest to check for Log4j.

Using Google’s Open Source Insights tool, search for a vulnerable version of Log4j and then select a dependent project.

In my case, I was able to build the nacos/client project, generate a list of dependencies as a tree, and (optionally) search for log4j in the list.

This assumes you’re using Maven, but similar workflows exist for Go, Python, and other languages. As always, choose the tool that is built for your language

➜ client git:(develop) mvn dependency:tree | grep log4j

[INFO] +- org.apache.logging.log4j:log4j-core:jar:2.17.0:compile

[INFO] +- org.apache.logging.log4j:log4j-api:jar:2.17.0:compile

[INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.17.0:compile

Don’t Forget Docker Images

While your software may have vulnerable and outdated packages, running in Docker further compounds this issue. Often, images are full of vulnerable system components lurking quietly, waiting to be abused. Even in the case of the most meticulously maintained images, the very latest and freshest of images are stale on arrival.

Consider that the ubuntu:latest image, widely used as a base for other containers, has 97 packages installed by default. At the time of this writing, several were ready for updates.

Further, because of caching and how the standard build process works, you are very likely to be building from an even older base image, magnifying the problem of bloated base images and stale, outdated, potentially vulnerable packages.

While it is entirely possible to audit installed system packages using tools specific to the distribution for that container’s base image, it’s far better security practice to shrink the surface area by opting to use scratch or distroless. This removes all other files (or nearly all in the case of Distroless) and packages, leaving only your application and the bare minimum of things necessary to run it.

You have removed a significant amount of surface area which could have been leveraged against you, making the image far more secure. As an added bonus, the SBOM is now far easier to generate and maintain!

Include Repo Health

An SBOM alone is only the beginning, however. It only provides a manifest of packages as one of potentially many other factors to inform decisions about supply chain security.

In particular, one must consider signals of the overall health of the repository as well as reported vulnerabilities. Who owns it? No, really, who actually owns it? How many contributors are there? How frequently is it updated? Do they have a process for reporting vulnerabilities? Single-developer, poorly supported or funded projects, or projects with poor communication all present additional risk to your organization’s supply chain.

Plan to Update Regularly

Again, an SBOM is only a manifest of packages and dependencies. These must be regularly audited using tools such as Anchore or Snyk to identify vulnerabilities that may not yet be known or are flying under the radar.

A dependency might not meet the qualifications to be reported to the National Institute of Standards and Technology and still present considerable security risks for an organization. Leaders are responsible for thinking critically about the software supply chain and predicting issues that could impact the business in the future.

The ecosystem for auditing dependencies, while undergoing rapid improvements, is still full of sharp edges and potentially difficult problems for teams trying to improve the security of its software supply chain. Asset inventory is the single most fundamental control available to organizations to reduce the risk of vulnerabilities.

Already a promising vector for attackers, supply chain attacks are only going to increase in complexity and become more difficult to defend against, but by being disciplined in the basic controls, we can achieve far better levels of security with lower effort and cost than trying to detect and remediate after an attack has already occurred.