
Earlier this month, I attended the UN's AI for Good Summit in Geneva, Switzerland. AI for Good is not a cybersecurity or supply chain conference. It is about applying artificial intelligence toward global good. I went ready to make the case for software bills of materials (SBOM) to an audience that might not see the connection. Instead of resistance, I found quiet validation.
The need for a thorough inventory of software components became apparent to the industry as early as 2004. The term "SBOM" itself did not exist until roughly 2013. In the years since, SBOM has gone from a niche concern to a widely debated best practice, and now, increasingly, to an assumed one.
Kaleidoscope, the academic track at AI for Good, featured 75 papers totaling 514 pages of research. SBOM appeared directly in three of those papers, including a prominent role in Mohamed Shareef's grand-prize-winning paper, "The Amplified Sovereignty Paradox: AI Governance Lessons From Small Developing Island States."
More telling than the direct mentions was the surrounding context. The conceptual issues that give SBOM its purpose, governance, sovereignty, and transparency, were everywhere in the program. Transparency alone appeared 141 times across the Kaleidoscope materials.
The takeaway is a genuinely optimistic one. SBOM is no longer controversial. As the toolkit built for software supply chain security extends into the emerging field of AI supply chain security, SBOM is not a novelty and not a debate item. It is a foundational methodology, an accepted and validated cornerstone of best practice.
That shift is already showing up in policy. CISA's guidance on software bill of materials for AI systems outlines the G7 AIBOM Minimum Elements, extending the same transparency principles that shaped traditional SBOM standards to the components, datasets, and models that make up AI systems.
For organizations building or deploying AI, this means an existing SBOM practice does not automatically translate into AI supply chain compliance. Assessing whether a given SBOM contains AI components, and whether it satisfies G7 minimum requirements, is quickly becoming its own discipline within vulnerability and compliance management. At CyBeats, our SBOM Quality Analysis capability now evaluates SBOMs against the G7 AIBOM Minimal Elements alongside existing standards like CISA Minimum Elements and BSI TR-03183, flagging exactly which elements are compliant and which are missing.
The work is far from finished. New challenges will keep surfacing as AI systems and their supply chains grow more complex.
For those of us who have spent years making the case for SBOM, this summit was a marker worth noting: the argument has largely been won. The task now is implementation, and that starts with treating SBOM data as more than a compliance artifact. Organizations need an SBOM System of Record: a single, authoritative source that tracks components, vulnerabilities, and provenance, including against emerging frameworks like the G7 AIBOM Minimum Elements, across the full software lifecycle, not a static document generated once and filed away.
We shortened our vulnerability review timeframe from a day to under an hour. It is our go-to tool and we now know where to focus our limited security resources next.

SBOM Studio saves us approximately 500 hours per project on vulnerability analysis and prioritization for open-source projects.
