When a Python project pulls in torch, transformers, or langchain, does Snyk's software composition analysis (SCA) engine treat it any differently than it would treat requests or lodash? Mostly, no — and that distinction matters more than it sounds. Snyk Open Source resolves AI/ML packages through the same manifest-parsing and dependency-graph pipeline it uses for every other open source library, then checks them against its vulnerability database. In other words, routine SCA scans already cover torch and transformers for known CVEs; what they miss is the AI-specific surface that never appears in a manifest. The AI-awareness people are actually asking about lives in a separate, purpose-built tool called AI-BOM, which Snyk has been shipping out of Snyk Labs and folding into the stable CLI since late 2025. This piece walks through what standard SCA actually does with AI/ML dependencies, where that mechanism stops, and how Snyk's newer static-analysis tooling picks up the rest — models, agents, and Model Context Protocol (MCP) connections included.
What Happens When Standard Snyk SCA Encounters an ML Package?
It gets resolved and scanned exactly like any other dependency, with no special-cased "this is AI/ML" logic in the core path. Snyk Open Source works by detecting the package manager from manifest and lockfile evidence — requirements.txt, pyproject.toml, package.json, pom.xml, go.mod, and equivalents — then building the full dependency tree, direct and transitive, and querying the Snyk vulnerability database for each resolved package-version pair. A line like torch==2.1.0 in a requirements.txt file is handled the same way flask==2.0.1 would be: parsed, versioned, and matched. Snyk supports this resolution across ecosystems including npm, pip, Maven, NuGet, RubyGems, Go modules, Cargo, and Composer, per its own documentation. The reason this feels like "AI/ML detection" in practice is that Snyk's vulnerability database has entries specific to ML tooling — deserialization flaws in torch.load, unsafe YAML loading in ML config pipelines, and advisories against packages like mlflow or transformers — so those packages surface findings without needing a dedicated classifier. Snyk states its database holds several million vulnerability records, more than what it describes as the next-largest public database.
Does Snyk's Core SCA Engine Actually Classify Packages as "AI/ML"?
No, not as a first-class category inside the standard Snyk Open Source product — that categorization is a newer, separate capability. Traditional SCA was built around a fairly stable assumption: packages have pinned versions, predictable release cadences, and a manifest file that names them. Snyk has written publicly that AI-native components break that assumption, since models get updated on what it describes as a weekly cadence or faster, agent frameworks and MCP servers evolve at similar speed, and a lot of AI usage in a codebase never touches a manifest at all — it shows up as an inline API call to openai.ChatCompletion or a Hugging Face pipeline() invocation with no corresponding requirements.txt entry. Standard SCA scans built on dependency trees have no mechanism to see that. That gap is what Snyk's AI-BOM tooling was built to close, and it's worth treating as a distinct product surface rather than an extension of the SCA engine itself.
What Is Snyk AI-BOM, and How Does It Differ From Standard SCA?
AI-BOM is a separate CLI command, snyk aibom, that generates an AI-specific bill of materials by statically analyzing source code rather than only resolving manifests. According to Snyk's documentation, it became available with stable CLI releases starting at version 1.1298.3, with the --experimental flag requirement dropped as of version 1.1304.0. Where snyk test walks a dependency graph, snyk aibom scans source files across Python, Java, JavaScript, and Go looking for AI usage patterns directly in code — imports, API calls, and framework-specific constructs — so it can catch AI components even when there's no manifest reference pointing at them. Output is written in CycloneDX v1.6 JSON, the same industry-standard SBOM format used elsewhere in the supply-chain security ecosystem, with an optional --html flag for a browsable visualization and an --upload flag to persist results to a Snyk organization for tracking over time.
How Does AI-BOM Detect Models, Agents, and MCP Connections Without a Manifest Entry?
It relies on static code analysis to recognize AI-specific patterns in source, not on dependency metadata. Per Snyk's own documentation, AI-BOM identifies four categories of components: models — both closed foundational models such as GPT-4 and open-weight models such as Llama-4, surfaced with model card and license information when available; agents, detected through recognized agent-framework libraries; tools, identified through common tool-calling patterns in code; and MCP servers and clients, recognized both through the official MCP SDK and through other common ways developers wire up MCP integrations. Snyk's Labs writeup on the tool gives a concrete illustration of why manifest-only scanning misses this: an application can call the OpenAI API directly or invoke a Hugging Face model through a few lines of Python with no package reference that names "GPT-4" or "Llama-4" anywhere a traditional SCA scanner would look. Snyk has also described real-world cases in its research where an organization discovered an active MCP server running in production during an unrelated product demo, with no prior AppSec visibility into it — the kind of shadow-AI component that inline static analysis is meant to surface where dependency-tree scanning would report nothing unusual at all.
What Does the AI-BOM Output Look Like and How Is It Used?
It's a CycloneDX-formatted document meant to be consumed like any other SBOM artifact, plus an aibom test step that checks the result against org-level policy. The generated file lists detected components with available metadata — model identifiers, license and supplier information where discoverable, and mapped relationships showing which MCP clients connect to which servers and what tools or resources those servers expose. The --json-file-output flag, added in CLI version 1.1303.0, writes results to a specified file for pipeline consumption, and --upload (paired with a --repo URL) persists the AI-BOM to a Snyk organization so it can be tracked as the codebase changes. Snyk describes aibom test as validating a generated AI-BOM against an organization's configured policies in a single step, which points toward AI-BOM being wired toward governance and drift-detection use cases — flagging when a new model, agent, or MCP connection shows up between scans — rather than functioning as a vulnerability feed the way snyk test does for open source dependencies.
How Safeguard Helps
The distinction Snyk itself draws — dependency-tree SCA on one side, static-analysis-driven AI component discovery on the other — is exactly the seam where AI supply chain risk tends to slip through. Safeguard is built around continuously mapping what's actually running in your software supply chain, including the kind of components that don't announce themselves through a requirements.txt line: embedded model calls, agent scaffolding, and MCP client/server relationships that get wired up in code and then quietly persist in production. That means visibility doesn't depend on whether a given commit happened to declare an AI dependency in a manifest, or on remembering to run a separate AI-specific scan alongside your regular vulnerability checks.
Where standard SCA gives you CVE coverage on the ML frameworks you've pinned, Safeguard extends that same rigor to the AI-native layer sitting on top of them — tracking which models, tools, and external AI services a service actually talks to over time, so a newly introduced MCP connection or an unreviewed agent integration doesn't sit undetected the way Snyk's own research shows can happen. For teams already relying on SCA to keep dependency risk in check, Safeguard's role is to make sure the fast-moving, often manifest-invisible parts of the AI supply chain get the same continuous scrutiny as everything else in the build.