Safeguard
Supply Chain•

CSRB Log4j review: the organizations that coped knew their inventory

The Cyber Safety Review Board found the best Log4j responders already knew where it ran. What inventory and vulnerability response the Board recommends.

Safeguard Security Team
3 min read

The Cyber Safety Review Board's 2022 report on Log4j found that organizations that responded most effectively understood their use of Log4j and had mature processes for managing assets and risk. Few could do this at the speed required. One federal cabinet department reported 33,000 hours of response work.

What happened

Log4j is an open source Java logging library. A community feature, JNDI lookup support, was accepted in 2013. On 24 November 2021 an Alibaba Cloud security engineer reported a vulnerability in it to the Apache Software Foundation. Another party disclosed it before an upgrade was public, starting a race between defenders and attackers.

The Board notes there was no comprehensive customer list for Log4j, or a list of where it was embedded, which hindered defenders. Additional flaws soon followed, adding confusion and patching fatigue.

What worked

The Board found the best responders could find the software, assess risk and mobilize partners quickly. These capabilities appear in most security frameworks, but few organizations had them ready.

Deploying fixes was itself a risk decision, trading possible disruption against timeliness.

Recommendations on inventory and response

Recommendation 5: invest in capabilities to identify vulnerable systems. Recommendation 6: build the capacity to maintain an accurate IT asset and application inventory. Recommendation 7: have a documented vulnerability response program. Recommendation 8: have a documented vulnerability disclosure and handling process.

The Board also advises preparing to address Log4j vulnerabilities for years to come.

A readiness test

Pick a widely used library you use. Can you list, within an hour, every application and container that includes it, including indirect use through other packages? If the answer is a project, not a query, you have found your gap.

Build the inventory once

  1. Generate an SBOM for each build and store it.
  2. Record container images and where they run.
  3. Include vendor software by asking for SBOMs or version statements.
  4. Make the inventory searchable by package and version.
  5. Rehearse a query like this quarterly.

Defender fatigue

The Board also noted burnout among defenders after sustained crisis response. Having a ready inventory cuts hours from the next event, which is a people issue as well as a technical one.

Click through it at your own pace, or open it full screen.

Safeguard's SBOM and dependency scanning and reachability analysis support this kind of search, and the free scan at https://gold.safeguard.sh/scan shows what a repository contains.

What to do when the next one lands

Start with a query, not a meeting. Search the inventory for the affected package, rank hits by exposure to the internet and sensitivity of data, and decide for each whether to patch, mitigate or accept for now. Record the decision. Communicate on a fixed cadence so leaders and customers hear from you before they ask. The report suggests preparation, not heroics, is what cut response time.

Quick check

Was Log4j exploited more than expected?

The Board found exploitation occurred at lower levels than many experts predicted, though it said the risk persists.

What is the first thing to build?

A searchable inventory of applications and their dependencies, so a question about one library has a fast answer.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.