The Cyber Safety Review Board's report on Log4j said many vulnerability response teams often could not identify where vulnerable code was in their systems. It recommended that organizations maintain an accurate IT asset and application inventory, and recommended improving SBOM tooling and adoption. It also noted SBOM limits at the time.
What the report said, in its own terms
The report is the CISA Cyber Safety Review Board review of the December 2021 Log4j event. Three passages matter for incident response.
First, it described a combination of factors: an enormous attack surface, vulnerability response teams that often could not identify where vulnerable code could be found in their systems, and an easily exploited vulnerability.
Second, on SBOMs, it said they theoretically should enable organizations to identify vulnerable components in their environments, but that representative groups using SBOMs reported none had used them to identify vulnerable Log4j deployments. It named limits such as variances in field descriptions, a lack of version information about catalogued components, and a lack of automation on the consumption end.
Third, in its recommendations, it called maintaining an accurate IT asset and application inventory accepted industry-wide cyber hygiene that can help organizations identify affected assets and applications during an incident. It also recommended improving SBOM tooling and adoptability.
What this means in practice
| Report finding | Practical response today |
|---|---|
| Teams could not locate vulnerable code | Store searchable inventories before an incident |
| SBOM field variances | Standardise identifiers, such as package URLs |
| Missing version information | Reject or flag components with no version |
| Lack of automation on the consumer side | Ingest and query SBOMs by tooling, not by hand |
| Inventory as hygiene | Keep an application inventory with owners |
The table is our reading of how those findings map to action, and not text from the report.
What has and has not changed
The report is from July 2022, so it describes conditions then. We cannot say from this source how much has improved since. A reasonable way to find out for yourself is to test your own response with a drill, as in finding a component in 30 minutes.
Using the report with your team
Share the three passages above with engineering and leadership, and ask a simple question: if the same kind of advisory landed today, could we list every affected product by the end of the day? If the honest answer is no, the gaps are usually coverage, depth and versions. The post on SBOM incident readiness metrics turns those into numbers.
Quick check
Did the report say SBOMs failed?
It said SBOMs were limited as designed at the time and that none of the groups it spoke with had used them to find vulnerable Log4j deployments. It also anticipated improvements.
Does the report require organizations to keep an inventory?
It recommends it as good practice. It is a review with recommendations, not a regulation.
Safeguard's asset discovery and SBOM scanning address the inventory gap the report describes.
Sources
Last reviewed: 19 October 2026.
