Businesses Need SBOMs After Log4j and Faster AI Vulnerabilities

The 2021 Log4j vulnerability exposed how hard it can be to find and fix flaws in widely used software components. Teams scrambled to locate affected applications and apply patches after the Java logging library flaw emerged at the end of 2021. Industry figures have pointed to that incident when urging wider adoption of software bills of materials, or SBOMs.

An SBOM is an inventory of open source and third-party components used in an application. It typically lists supplier and component names, versions, dependency relationships, who produced the SBOM and when, and any known security, legal or quality risks. The document helps security, engineering and legal teams determine whether a newly discovered flaw affects their systems and where the vulnerable component is used.

U.S. and European rules are moving SBOMs into procurement and product requirements. The U.S. Executive Order 14028 on Improving the Nation’s Cybersecurity set requirements for stronger software supply chain security in federal systems and prompted guidance from NIST and the NTIA for agencies and their suppliers. The EU Cyber Resilience Act requires SBOMs for products with digital components sold in the bloc, with full enforcement scheduled for December 2027. The NIS2 directive and national guidance in the U.K., including advice from the National Cyber Security Centre, are also increasing expectations for transparency in software contents.

Modern vulnerability discovery is speeding up, and advanced AI models are accelerating that pace. A major browser project reported using an advanced AI model to find and fix hundreds of bugs, illustrating how models can surface large numbers of issues quickly. Crystal Morin, senior cybersecurity strategist at Sysdig, noted that faster weaponization of vulnerabilities makes visibility into components more important for security teams.

Experts recommend automating SBOM creation and integrating it into the software development lifecycle so the inventory updates when code changes. Dana Simberkoff, chief risk, privacy and information security officer at AvePoint, advised treating an SBOM as a living artifact that updates with each code or patch change rather than a one-time task.

Teams commonly use tools to scan codebases and produce SBOMs. Commercial and open-source products such as Black Duck, Snyk, Mend and FOSSA, along with platform features in GitHub and GitLab that pull from dependency graphs, can generate SBOM outputs. Ritchie Perry, an electronics engineer at ByteSnap Design, recommended spot-checking tool results, particularly for high-risk components, because automated scans do not always capture every dependency correctly.

Ilkka Turunen, field CTO at Sonatype, warned that knowing what internal developers use does not guarantee visibility into vendor or supplier code and urged organizations to require SBOMs from their vendors. He added that SBOMs should be combined with threat intelligence and policy rules and monitored for new vulnerabilities so teams can replace or patch components when needed.

Regulated sectors such as critical infrastructure, government services and emergency systems will face the earliest and strictest SBOM requirements. Companies that supply those sectors or work with larger customers should expect SBOM requests to flow down supply chains. Rules and guidance explicitly reference using SBOMs in procurement and incident response, which will affect how organizations prepare for future vulnerability discoveries.