Most dependency scanners cover ML libraries well, because those are ordinary packages. Many do not cover model files, which are downloaded artifacts rather than packages. To know what yours sees, scan a test repository that contains both and compare the output with what you planted.
Two different kinds of component
An ML library such as an inference runtime or a tensor framework arrives through a package manager. It has a name, a version, a manifest and, usually, published advisories. A scanner that reads manifests and lockfiles will list it.
A model file arrives differently. It may be committed to a repository, pulled from a public hub at build time, or fetched when the application starts. It has no entry in a lockfile. A scanner that only reads manifests never sees it.
That is the whole gap. It is not that the scanner is bad. It is that the question "what do we depend on?" has a larger answer than the manifest.
What a scanner can honestly do
| Capability | Typical for dependency scanners | Needs extra method |
|---|---|---|
| List ML libraries from manifests and lockfiles | Yes | No |
| Match libraries to published advisories | Yes | No |
| Detect model files by extension or content | Sometimes | Often a separate step |
| Record where a model came from | Rarely | Process or ML-BOM |
| See runtime model downloads | No for static scanning | Runtime inventory or code review |
Static scanning reads files at rest. Anything fetched at runtime needs a different technique, such as searching the code for download calls or recording what the application actually loads in a test environment.
How to check yours in 30 minutes
- Create a branch with one ML library pinned to an older release and one small public model file.
- Run your current scanner and export the result.
- Check whether the library appears, with the right version.
- Check whether the model file appears anywhere, even as a plain file.
- Check whether the scanner can produce an SBOM, and whether that SBOM lists the model.
If the model is missing, you have three options. You can add a separate inventory step, you can extend your SBOM with a machine learning bill of materials entry, or you can adopt a tool that detects model files. CycloneDX describes its AI/ML-BOM as a way to represent models, datasets and configurations, including provenance, so the third option has a standard to build on.
What to do with the answer
Do not panic about the gap. Decide who owns it. A small team can start with a spreadsheet of approved models, with source, version, license and hash, and a rule that nothing outside the list reaches production. See a one page model intake record for a template.
Larger teams should put the check in the pipeline, so that a new model file in a pull request triggers review. Pair that with finding model files in repos and artifact stores.
Safeguard covers SBOM and dependency scanning, including the libraries, and offers asset discovery to help you list what is running. Check the current coverage of any tool, including ours, against your test branch rather than a datasheet. The free scan is at gold.safeguard.sh/scan.
Quick check
Will an SBOM list my models automatically?
Only if the tool generating it detects them or you add them. Many SBOMs are built from manifests, which omit model files unless someone records them.
Is a model file riskier than a library?
It depends on the format. Some formats can run code when loaded. Treat unknown formats as untrusted until you have checked how they are loaded.
Sources
- CycloneDX, Machine Learning Bill of Materials (AI/ML-BOM)
- OWASP Top 10 for LLM and GenAI Apps 2025, LLM03 Supply Chain
Last reviewed: 19 October 2026.
