AI-BOM minimum elements proposal builds on SBOM lessons

Organizations investing in software bill of materials (SBOM) practices are starting to see the payoff as it becomes easier and less of a time sink to chase down what's actually running in production when supply chain incidents make headlines. The only problem is that with AI, the software supply chain visibility goalposts are moving.

AI supply chain attacks are in their infancy, but this spring has given us a preview of what life with AI-embedded software is going to look like. In March, two PyPI releases from LiteLLM were published with malicious code due to a supply chain compromise. This attack cascaded across the AI supply chain to companies like Mercor, an AI data training firm, which in April had its extensive work with Meta suspended due to the exposure of training data.

Meanwhile, in May, a malicious Hugging Face model posing as an OpenAI release managed to rack up 244,000 downloads before being taken down. ReversingLabs presaged this class of attack back in February 2025 with its own research on the nullifAI attack technique, which showed how malicious code hidden in model files could bypass AI platform security scans.

This is just a smattering of the attacks that are unfolding today across the AI supply chain, but suffice it to say that it's no longer enough to know what's in your code. Now organizations also need to account for which AI models are embedded in their systems and the infrastructure around them. This includes not only software elements but also where models came from, what data trained them, and who is responsible for training them.

This is what AI bills of materials (AI-BOMs) are supposed to address. Like SBOMs for software, AI-BOMs should ideally give organizations a structured way to document what's in their AI systems and trace the impact when something goes wrong. But right now, there's no shared understanding of what an AI-BOM should actually contain.

A new policy paper from the Institute for Security and Technology (IST) tries to answer that. "Driving AI Transparency" makes the case for defining AI-BOM minimum elements before requirements start proliferating without a shared standard.

[ See Webinar: How to Make SBOMs Actionable with PURLs ]

Learning from the SBOM playbook

"When we're looking at the specification layer of AI-BOMs, we need to ask, 'Do we all agree what we need to include?' Right now the answer is no, we definitely don't agree what we need," says the report's co-author Nick Leiserson, IST's senior vice president for policy and a former White House official.

The good news is that the AI transparency movement doesn't have to start from scratch. The software supply chain security community already wrote the playbook through years of cross-sector consensus building around SBOM that produced a cohesive view of what software transparency should look like. That work informed regulatory approaches in the U.S. and abroad, and gave organizations a common framework to build on.

No one knows that better than Allan Friedman, who spent more than a decade in federal service building the SBOM movement from concept to policy. As a senior technical advisor for IST, he co-authored the paper with Leiserson to continue what he calls the "inevitable" progress toward AI-BOMs as AI becomes a linchpin of modern software systems.

"SBOM as a concept has taken off, and while we're still rolling out implementation and talking about the details, it is no longer controversial to say we should know what's in our software."
—Allan Friedman

Friedman explained: "You take that movement combined with the overwhelming tidal wave that is AI revolutionizing IT, and you get something that was bound to happen."

At the National Telecommunications and Information Administration (NTIA), Friedman stood up the first SBOM working group. At the Cybersecurity and Infrastructure Security Agency (CISA), he coordinated the global cross-sector community that turned transparency into an expectation. Now he's at IST, and he wants to encourage everyone from policymakers to AI labs to start applying the same playbook established during his years at CISA to drive the development of a more standardized vision for AI-BOMs.

This is why he so strongly believes minimum elements are needed. He says a key part of the early momentum for SBOM came from the 2021 executive order on cybersecurity, which started by defining minimum elements.

"The original executive order explicitly required minimum elements. It said, before we move forward on a requirement, we're going to define it. And of course that is what we pulled in with AI-BOM."
—Allan Friedman

He notes that while it is true that the G7 Cybersecurity Working Group published guidance last year listing 48 fields it called "minimum elements," the document it released explicitly states those elements are not mandatory. He sees this as a great barometer for how serious policymakers are about getting AI-BOMs meaningfully defined, but believes there's more work to do.

Some of the fields suggested in it, like "security controls" and "model input-output properties," still require significant standardization work before organizations could implement them consistently. Meanwhile, while both CycloneDX and SPDX, the two major BOM formats, have developed AI-specific extensions, he explains that the minimum elements specification needs to sit above those formats, defining what information should be captured regardless of how it gets encoded.

IST's proposal for minimum elements starts with the baseline data fields that any AI-BOM should include. For datasets, the paper suggests capturing identity information like name, version, location, and integrity reference, along with governance details like sensitivity classification, licensing, and origin. For models, the suggested fields cover similar ground: name, version, supplier, origin, lineage, license, and pointers to supporting documentation like model cards.

The paper explicitly avoids prescribing fields that would require extensive ontological work to implement. The goal is a foundation that organizations can build on right away. Make it too complicated and it could squash early buy-in from both producers and consumers of AI-BOMs.

"You need to be careful about being too early, pushing the gas too hard. If you do, you end up with fragmentation. And you also might ask for stuff that ends up not being all that useful."
—Nick Leiserson

A vacuum to fill

Both Friedman and Leiserson explain that more than anything their policy paper is meant to be a conversation starter between policymakers and industry. The message IST is trying to bring to policymakers is to set a timeline, scaffold the industry's way to different milestones, and let the technical community define the specifications before mandates start rolling out.

"Please don't start by saying, 'We need an AI-BOM tomorrow,'" Leiserson recommends to policymakers, "because we don't know what that means." Of course, the elephant in the room is the fact that the federal cyber landscape looks very different than it did in 2021.

When SBOM was coming together, CISA served as the convening body that coordinated the global, cross-sector community. It was the independent authority that helped pull together vendors, security researchers, open-source maintainers, and government officials to hash out technical and policy differences. This helped drive the consensus that made the minimum elements stick. "The power of SBOM was in part that there was this neutral ground where everyone felt welcome," Friedman said.

Unfortunately, there's currently no single agency in the federal space serving as that unifying force anymore. The pronounced brain drain at CISA that drove away Friedman and hundreds of experts like him — through reduction in force and a wave of voluntary departures that only intensified with the federal shutdown this year — has left a leadership vacuum. "If the government were able to actually pull together this kind of convening today, that would be wonderful. It's the sort of thing that CISA would have done well in the past," he said.

Without some independent force at the helm, a problem arises due to the dynamics between what Friedman and Leiserson in the paper call the supply side and the demand side of standards development.

The supply side focuses on building the specification itself. It's led by the technical and business stakeholders who come together to get that consensus about minimum elements and all the technical details needed to build tools on top of them. The demand side is driven by the policy and business forces that create market pressure through everything from regulations to procurement requirements that force organizations to use AI-BOMs to track their AI supply chain data. It's IST's position that you need both sides working in tandem to gain meaningful momentum.

"What we need is the glue between the top-down policy and the bottom-up technology, that takes the form of building out shared understandings and appreciation for how it's going to fit into business processes today and what a future of AI transparency is going to look like."
—Allan Friedman

Friedman is concerned that as the political changes slowly unfold for CISA, time is ticking for AI-BOM. As each month goes by without some kind of leadership, the cyber community is going to grow more fractured about AI-BOM minimum elements, use cases, and everything in between. He says that the most expeditious course may be to have a nongovernmental independent organization take up the mantle and start moving forward instead. "If that's not something that can happen in a timely fashion because this really does need to happen quickly, then we think an organization like IST that has a track record for being able to host this that is not seen as overly aligned to one of the two competing data standards and has a pretty deep bench of expertise in AI would be a good fit," he said.

Friedman and Leiserson say that IST is exploring discussions with existing partners across the industry to try to bring resources to bear to keep the ball moving forward for AI-BOM uptake.

What practitioners need to know

Daniel Bardenstein, CEO of Manifest Cyber and a former CISA official who worked with Friedman, sees the IST paper as a starting point for governance conversations that security leaders need to be having now.

"While there are many more risk-centric fields that I've seen included in AI-BOMs, this represents a solid, tightly scoped set of minimum elements that levels the playing field and sets expectations for AI developers," Bardenstein wrote. "This list serves as a framework for government policymakers and industry governance leaders around the world to start enacting AI transparency policies."

For organizations unsure where to begin, Bardenstein's advice is to start with what they already know.

"AI is a subset of software. Ninety percent of AI security is traditional software security. If most organizations just apply what they already do for software security onto AI, they're already ninety percent of the way there."
—Daniel Bardenstein

Friedman suggested that organizations start pressing their suppliers now, before requirements formalize. "Start knocking on the door of frontier labs and saying, 'We're hearing that this is coming, start giving us some of the information.'"

And when the information isn't available, document that too. "Be open and explicit about what you don't know," Friedman said. "We need to document the known unknowns today."

The provenance question is especially acute given how many capable open-weight models originate from vendors that raise concerns in regulated industries. Kriti Tallam, senior member of technical staff at Kamiwaza AI and a contributor to the National Institute of Standards and Technology's AI Risk Management Framework, frames the broader challenge in terms of chain of custody.

"The question is no longer, 'Is this input crossing my boundary from a trusted or untrusted source?' It is, 'Can I verify the chain of custody of every artifact that has shaped this system's behavior?'"
—Kriti Tallam

For most organizations, the honest answer right now is no. The IST paper is an attempt to build the shared foundation that makes the question answerable. Whether policymakers take up the invitation will determine whether AI supply chain transparency follows SBOM's path or fragments into something far less useful.