For a decade, "know what's in your software" has meant the SBOM: components, versions, licenses, vulnerabilities. AI systems broke that model, literally. The most consequential thing in an AI system is often the model, and the model is not an ordinary software component.
The Part of the Inventory That Went Dark
A model has its own supply chain. A base model, often pretrained and pulled from a public hub. The data it was trained and fine-tuned on. Its architecture. Its lineage, who produced it, from what. And the format it is serialized in, which turns out to matter more than most teams realize.
Ordinary SBOM tooling was not built to see any of this. It catalogs the libraries and frameworks around the model and stops there. So the model, the single component most likely to be under governance scrutiny, is frequently the one component nobody has inventoried.
What SCIP Now Catalogs
SCIP now recognizes and catalogs the AI/ML model components declared in the SBOMs you ingest, using CycloneDX's machine-learning-model component type. Where the SBOM declares them, it captures the model's architecture, its training-data references, its performance metrics, and its lineage, and lists them in an AI/ML Model Inventory that sits alongside your standard software inventory. The models stop being invisible. They become rows you can search, filter, and report on like anything else in your bill of materials.
The Risk Layer: Not Every Model Format Is Safe
SCIP adds a risk dimension on top of the inventory. It flags AI/ML models serialized in known-insecure formats, legacy pickle-based formats and the like, against safer alternatives, and folds that signal into the same risk scoring it uses for CVE and KEV findings. This matters because an insecure serialization format is not a vulnerability in a dependency; it is a property of the model artifact itself, and loading such a model can mean executing whatever the file author put there. It is a supply-chain risk that lives below the level an ordinary vulnerability scan looks at.
The Honest Scope
Worth stating precisely, because model provenance is exactly the kind of claim worth being careful about. SCIP catalogs the AI-BOM data your SBOMs actually declare. It reads what's present, the model components, their declared lineage and metrics, the serialization format, and surfaces and risk-scores it. It does not independently verify a model's provenance, reach into models your SBOMs don't describe, or establish the origin of training data the SBOM doesn't carry. It operationalizes the part of the AI-BOM problem a well-formed SBOM makes concrete. The fuller discipline, verifying provenance for everything not declared, is still forming.
Why Now
This is not a coincidence of timing. As AI moves under formal governance, the ability to answer "what models are in this system, and what are their properties" stops being a nice-to-have and becomes a procurement and audit requirement. A model inventory keyed to the SBOM you already produce is the concrete artifact that answers it. You generate the SBOM for software reasons already. The AI/ML models inside it are a second use of the same data, with no new collection.
Point SCIP at the SBOMs you already generate and the models inside them become an inventory you can work with. Install from Splunkbase: splunkbase.splunk.com/app/8814
When procurement or an auditor asks for a list of the models in your AI systems, will you be reading it off a dashboard, or reconstructing it by hand?