The Cyber Safety Review Board's Log4j report makes 19 recommendations in four groups. Several concern open source: that maintainers join community security programs, that SBOM tooling improve, that investment in open source security increase, and that maintenance support for critical services be piloted. It also asks the government to explore software transparency baselines for federal vendors.
The four themes
The Board groups its work under four headings: address continued risks of Log4j, drive existing security hygiene practices, build a better software ecosystem, and invest in the future.
Items aimed at developers and maintainers
- Recommendation 9: software developers and maintainers should implement secure software practices.
- Recommendation 10: open source developers should take part in community based security initiatives.
- Recommendation 11: invest in training developers in secure software development.
- Recommendation 12: improve SBOM tooling and adoptability.
- Recommendation 13: increase investment in open source software security.
- Recommendation 14: pilot open source maintenance support for critical services.
Items aimed at government
- Recommendation 15: explore a baseline requirement for software transparency for federal government vendors.
- Recommendation 16: examine a cyber safety reporting system.
- Recommendation 17: explore a software security risk assessment center of excellence.
- Recommendation 18: study the incentives needed to build secure software.
- Recommendation 19: set up a working group to improve identification of software with significant risk.
Note the verbs. Most say explore, examine or study. The report points to directions, not mandates.
What a company can do now
You do not need to wait for policy:
- Ask suppliers for SBOMs and keep what they send.
- Produce your own SBOM for each release.
- If your product depends on a small open source project, learn who maintains it and how it is funded.
- Contribute fixes or funding where you can, and give staff time to do so.
- Train developers on secure coding as a routine, not an event.
SBOM caveats
An SBOM lists components. It does not by itself say which vulnerabilities matter. Pair it with a way to check whether the vulnerable code is actually reachable, to reduce noise.
Safeguard's SBOM and dependency scanning and reachability analysis are built for that pairing.
Questions to ask about your top dependencies
For the ten open source packages your product depends on most, ask who maintains each, how many maintainers there are, how recently it was updated, and what you would do if it were abandoned. The answers show where your own risk is concentrated. Where you find a single unpaid maintainer behind something critical, consider funding or contributing, and record a fallback plan.
Try it yourself
Click a package to see where it enters the tree, and note how many components arrive indirectly.
Click through it at your own pace, or open it full screen.
Quick check
Does the report require companies to produce SBOMs?
No. It recommends improving SBOM tooling and exploring transparency baselines for federal vendors.
Who is the Board?
A public and private review body convened under CISA to examine major cyber events.
Sources
Last reviewed: 19 October 2026.
