What It'll Take to Make AI BOMs Usable in a Modern Security Program

How to Make AI BOMs Usable in a Modern Security Program

Newsletter Sign-UpNewsletter Sign-UpCybersecurity TopicsRelated TopicsApplication SecurityCybersecurity CareersCloud SecurityCyber RiskCyberattacks & Data BreachesCybersecurity AnalyticsCybersecurity OperationsData PrivacyEndpoint SecurityICS/OT SecurityIdentity & Access Mgmt SecurityInsider ThreatsIoTMobile SecurityPerimeterPhysical SecurityRemote WorkforceThreat IntelligenceVulnerabilities & ThreatsRecent in Cybersecurity TopicsEndpoint SecurityChina's Webworm Uses Discord, Microsoft Graphs to Hack EU GovernmentsChina's Webworm Uses Discord, Microsoft Graphs to Hack EU GovernmentsbyAlexander CulafiMay 22, 20264 Min ReadApplication SecurityGitHub Confirms Breach, 4K Internal Repos StolenGitHub Confirms Breach, 4K Internal Repos StolenbyAlexander CulafiMay 20, 20263 Min ReadWorld Related TopicsDR GlobalMiddle East & AfricaAsia PacificLatin AmericaSee AllThe EdgeDR TechnologyEventsRelated TopicsUpcoming EventsPodcastsWebinarsSEE ALLResourcesRelated TopicsResource LibraryNewslettersPodcastsReportsVideosWebinarsWhite Papers Partner PerspectivesDark Reading Resource LibraryCyber RiskCybersecurity OperationsCybersecurity AnalyticsHow ToNews, news analysis, and commentary on the latest trends in cybersecurity technology.What It'll Take to Make AI BOMs Usable in a Modern Security ProgramFive ways CISOs can prepare for consuming AI bills of materials and influence the direction of how they're generated.Ericka Chickowski, Contributing WriterMay 20, 20269 Min ReadSource: nastassia via Adobe Stock PhotoThe standards for artificial intelligence bills of materials (AI BOMs) are maturing, and the tools are rapidly emerging. But industry watchers say that most vendors and software development teams can't yet deliver an AI BOM when asked. And most security teams wouldn't know what to do with it if they got one. Of course, the evidence is mostly anecdotal. AI BOMs are so nascent that there are no great numbers to show the state of AI BOM operationalization today. But Optero's "2026 Risk Intelligence Report" found that while 85% of organizations have integrated AI into core operations, only 25% have comprehensive visibility into how AI is being used. Considering also that software bills of materials (SBOMs) are still only spottily operationalized after years of industry advocacy, it's easy to infer that a long road lies ahead before security leaders can reap the actual benefits from AI BOMs.The good news for security leaders is that it's not going to take a wholesale reinvention of processes to dig into the work of generating and consuming AI BOMs. Ecosystem momentum is building  to make this practical at scale. And practitioners can iterate a lot from what they've learned from the AppSec and software supply chain work they've ideally done for a while, says Daniel Bardenstein, co-founder of Manifest Cyber, a supply chain security platform.Related:Is 2026 the Year AI Bills of Materials Get Real?"To be honest, I think the bar is a lot lower than it might seem," he says. "AI is a subset of software, at least that's what many of us believe, and 90% of AI security is traditional software security. So if most organizations just apply what they already do for software security onto AI, [then] they're already most of the way there."That last 10% is tricky, though, and AI BOMs specifically have a host of new considerations to address that are outside the bailiwick of even the most salty security veteran. Here's what experts say CISOs need to start thinking about and planning to turn AI BOMs into meaningful operational tools.The First Step Starts With ScopingBefore you can document your AI systems, you need to know what AI systems you have. This sounds obvious, but as Optero's data suggests, many organizations aren't able to do this yet. When most practitioners think about shadow AI, they're primarily worried about unauthorized tools brought into environments without approval. But the elephant in the room is that many authorized pieces of software now have AI embedded in them, with no visibility into what or how it has been deployed. Added to that are in-house development projects that may include approved models but don't actually track how things change as they're tuned and trained for daily use.  Related:What Will Make AI BOMs Real?"If I'm taking that approved model and passing it off to some people who are fine-tuning those models and customizing it with my own internal data sets, unless I'm capturing that somewhere, I've now just created shadow AI," Bardenstein says. "Someone in some business unit created a fine-tuned model, and we don't know the story about who built it, how, and where it's actually deployed."So CISOs need to start by asking and answering some important scoping questions, which will help map every AI component that needs to be represented in a BOM: what you're building internally, what's embedded in software you're buying, and what data is being used to train or customize any of it."The first step is to identify what your AI supply chains look like," Bardenstein says. "What are the things you need to represent as a bill of materials?"This means identifying where internal data is being used to customize models. And it means getting vendors to disclose what models are embedded in the software the organization is buying.Roadmap for ActionabilitySecurity teams that generate AI BOMs and file them away are missing the point. The same goes for teams that request them from vendors and never look at them again. The real payoff for AI BOMs will come from how the documentation plugs into security and governance workflows.Take incident response. CISOs should be building processes and integrated systems that can help them quickly move when a vulnerability is disclosed in a specific model version, figuring out each system that uses it. For this to work, security teams need to integrate AI BOM data into their existing asset management and incident response workflows. The platforms that handle security incident and event management, asset management, and governance, risk, and compliance need to speak AI BOM natively. Emerging AI security posture management (AI-SPM) tools and DevSecOps platforms with MLOps integrations are likely to become the primary management layer for AI BOMs, but the traditional security platforms for incident response and compliance will still need to ingest this data and interact with it regularly to truly gain the ability to act on it.Bardenstein describes what an action-based implementation would look like around a component governance process. One of Manifest's customers was facing eight-week approval cycles when business units wanted to use new models from Hugging Face. Every request required legal, compliance, and AI review boards to manually evaluate whether a model was safe and trusted enough to use. They had to wade through qualitative documentation, such as model cards and data cards, to answer that question."We got them down to a few clicks and a few minutes," he says, explaining that the difference-maker was in the structured data provided by the AI BOM. Whereas model cards are PDFs that someone has to read and interpret, AI BOMs are machine-readable data that governance tools can ingest automatically to flag issues like licensing risks or known vulnerabilities.  This is the direction that CISOs planning on consuming AI BOMs should be taking their roadmaps. CISOs working on generating AI BOMs should also keep this in mind so they can better support their customers with the kind of structured, machine-readable documentation that security and governance platforms can actually ingest.Data Provenance: The New PerimeterOne of the thorniest problems in AI supply chain security is that the threats don't always look like traditional attacks. A model can be compromised long before it ever reaches an organization's environment through poisoned training data that shapes its behavior in ways that are nearly impossible to detect after the fact.Research published in October 2025 by Anthropic, the UK AI Security Institute, and the Alan Turing Institute found that just 250 poisoned documents can backdoor a large language model of any size. The traditional network perimeter can't intercept an attack that arrives encoded in training data months before the model is deployed.This is why provenance documentation matters so much. An AI BOM that lists model architecture and training framework — but can't prove where the training data came from — isn't going to help security teams understand whether they can trust the model's behavior. And an AI BOM that documents all of this but can't itself be verified is just a self-reported claim. As researchers from a new project called AIBoMGen recently noted in a paper this January, "Without mechanisms to ensure the integrity and authenticity of the documented information, AI BOMs cannot effectively support compliance and security."This creates what amounts to a zero-trust problem for content, says Krti Tallam, senior member of technical staff at Kamiwaza AI and contributor to NIST's AI Risk Management Framework."The question is no longer, 'Is this input crossing my boundary from a trusted or untrusted source?'" she says. "It is, 'Can I verify the chain of custody of every artifact, data, model, prompt, tool, embedding, that has shaped this system's behavior?'"The practical answer to that question is beefing up cryptographic signing and attestation for components in AI BOMs and for the BOMs themselves. For security leaders consuming AI BOMs, this starts with looking for cryptographic hashes of datasets and verified model signing. Unverifiable provenance should be treated as a risk signal. For those generating AI BOMs internally, the model registry can serve as the access control layer, where models without verified provenance don't get deployed to production.Fortunately, the industry scaffolding for this is starting to firm up. The NSA and seven allied agenc