Most SBOM tooling still assumes a dependency looks like a line in requirements.txt or pom.xml. AI usage rarely works that way — a developer can call model="gpt-4" in a single line of Python, or pull meta-llama/Llama-4 from Hugging Face at runtime, and no package manifest ever records it. Snyk built snyk aibom to close exactly that gap: a CLI command that scans a local codebase and emits a CycloneDX v1.6 JSON document listing the models, datasets, agents, tools, and MCP servers it finds embedded in source code. This post walks through the publicly documented mechanics — the detection engine, the component categories, and the specific CycloneDX v1.6 structures (machine-learning-model, modelCard, data) that the output conforms to — so security and compliance teams understand what they're actually consuming when someone hands them an AI-BOM.
What Is Snyk AI-BOM, and What Gap Is It Closing?
Snyk AI-BOM is the snyk aibom CLI command, and it exists because traditional SBOMs only capture what a package manager declares. According to Snyk's own documentation, the command "identifies AI models, datasets, and maps the AI supply chain, including connections to external tools and services using the Model Context Protocol (MCP)" for local projects. It requires Snyk CLI version 1.1298.3 or later and an active internet connection, and it currently supports codebases written in Python, Java, JavaScript, or Go. The premise is straightforward: an SBOM built from pip freeze or a package-lock.json tells you nothing about the foundation model a script calls over an API, so a separate, code-aware scan is needed to surface it.
How Does Snyk AI-BOM Find Models That Never Appear in a Manifest?
It works by reading source code semantically rather than parsing dependency files, using Snyk's DeepCode static analysis engine. Snyk Labs describes this as the ability to "detect embedded AI usage in code, even when there's no clear manifest or package reference to guide the scan" — the example given is that invoking a model can be "as simple and opaque as invoking a single API endpoint." Practically, that means a call to an OpenAI GPT-4 endpoint or a Hugging Face AutoModel.from_pretrained(...) line gets flagged the same way a static analyzer would flag a SQL injection pattern: by recognizing the code shape, not by resolving a package coordinate. This is the same underlying engine Snyk uses for its SAST product, repurposed to recognize AI/ML usage patterns instead of vulnerability patterns.
What Categories of AI Components Actually Land in the BOM?
Snyk AI-BOM groups what it finds into five categories: models, datasets, agents, tools, and MCP servers. Models cover both foundational systems (Snyk's documentation cites GPT-4 as an example) and open-source releases (Llama-4 is the example given), and where available the output includes model card data, license, and supplier information. Agents are recognized through common AI-agent framework patterns, tools are identified by standard tool-calling implementations, and MCP servers are detected via the official MCP SDK plus other common construction patterns. The MCP detection is the most structurally interesting piece: rather than flagging a single component, it maps a chain — MCP client to MCP server to the specific tools and resources that server exposes — which is a dependency relationship traditional SBOMs have no vocabulary for at all.
Why CycloneDX v1.6 Specifically, and Not 1.5 or a Custom Format?
Snyk AI-BOM outputs CycloneDX v1.6 JSON because that's the first version of the spec where the AI/ML model card gained environmental reporting on top of the ML-BOM structure introduced two releases earlier. CycloneDX 1.5 was the version that introduced the machine-learning-model component type and the modelCard object in the first place, giving the spec a standard way to describe a trained model as a BOM component. OWASP then released CycloneDX v1.6 on April 9, 2024, and it was subsequently ratified as an Ecma International standard (ECMA-424) on June 26, 2024. Among its additions were environmental considerations for AI/ML model cards — fields for reporting energy usage and CO2 emissions across training and inference — layered onto the existing model-card schema. For a tool whose entire purpose is describing AI supply chain risk, targeting the schema version where the AI-specific fields are most complete, and which is now a ratified international standard, is the practical choice: it maximizes compatibility with downstream SBOM tooling (dependency graph databases, vulnerability scanners, audit platforms) that already parse CycloneDX.
How Does CycloneDX Actually Represent a Model Inside the File?
Each detected model becomes a component object of type machine-learning-model, and per the CycloneDX specification this component type should carry a modelCard sub-object that CycloneDX explicitly says "MUST NOT be specified for other component types." The modelCard breaks into three documented blocks: modelParameters, covering hyperparameters and the model's overall learning approach; quantitativeAnalysis, covering performance metrics; and considerations, covering ethical, bias, and (as of 1.6) environmental factors relevant to the model's construction and use. Datasets referenced by a model — training data mentioned in its model card, for instance — get their own separate component using CycloneDX's data component type, and CycloneDX's dependency graph is what links a data component back to the machine-learning-model component it trained, so a tool consuming the file can trace which dataset fed which model without needing bespoke parsing logic. Because this is all standard CycloneDX rather than a Snyk-proprietary schema, the same JSON file can be ingested by any CycloneDX-aware platform, not just Snyk's own.
What Does the Output Actually Look Like, and How Do You Get It?
Running snyk aibom against a supported project produces a CycloneDX v1.6 JSON file by default, and several flags shape what you get out of it. --html generates a visualizer of the detected components and their relationships instead of raw JSON; --json-file-output (available from CLI v1.1303.0 onward) writes the JSON directly to a file rather than stdout; --upload, combined with --repo, persists the AI-BOM to a Snyk Organization for ongoing tracking; and --org=<ORG_ID> targets a specific organization when a user belongs to more than one. The command returns exit code 0 on success, 2 on a runtime failure, and 3 when it's pointed at a project type it doesn't support — standard CI-friendly exit-code semantics that let the scan gate a pipeline the same way a snyk test vulnerability scan would.
How Safeguard Helps
A CycloneDX v1.6 AI-BOM is only as useful as what happens after it's generated. Safeguard treats an AI-BOM the same way it treats a software SBOM: as an input to continuous supply chain monitoring rather than a point-in-time PDF. That means ingesting the machine-learning-model and data components Snyk (or any other CycloneDX-compliant generator) produces, tracking them over time as code changes, and alerting when a new model, dataset, or MCP server shows up in a build that wasn't there before — the same drift-detection discipline Safeguard applies to open-source dependencies. Because the format is a ratified, vendor-neutral standard, Safeguard doesn't need Snyk-specific parsing: any CycloneDX 1.5+ modelCard, considerations block, or MCP dependency chain feeds directly into policy checks — for example, flagging an unapproved foundation model, an MCP server with no listed supplier, or a model whose considerations field discloses environmental or bias concerns that violate internal AI-usage policy. For teams building SOC 2 or similar audit evidence, that gives compliance and security teams a durable, machine-readable record of exactly which AI components entered production and when, rather than relying on developers to self-report what model they called.