github.com
AI-exploits
Exploits for MLOps systems, extending beyond inputs provided to LLMs such as ChatGPT
Independent evaluation guide | 6 synced entries
How to evaluate AI supply-chain security tools
Protect model provenance, artifacts, dependencies, signing, and delivery pipelines. Compare selection criteria here, then verify every claim against the linked first-party source.
Decision context
What does supply-chain security tooling need to cover?
AI supply-chain security covers the path from data and training code to packaged models, registries, deployment images, and inference services. Attackers can compromise dependencies, tamper with artifacts, exploit unsafe model formats, poison shared assets, or substitute an untrusted model during delivery. The tools in this category support controls such as model signing, provenance records, artifact inspection, ML bills of materials, and policy enforcement in MLOps infrastructure.
README-synced directory
AI Supply-Chain Security catalog entries
Each listing preserves the neutral description maintained in the Awesome MLSecOps README and links to the resource's first-party source.
github.com
AIsbom
Disassembles Pickle bytecode and parses SafeTensors/GGUF binary headers to detect malware and license risks in ML model files before load. Generates CycloneDX/SPDX SBOMs.
github.com
BomLens
Local-first SBOM generator that builds CycloneDX ML-BOMs for Hugging Face models, with license and known-vulnerability reports
github.com
Model Transparency
Generate model signing metadata for provenance verification
github.com
ModelScan
Protection Against ML Model Serialization Attacks
github.com
Safetensors
Tensor storage format designed to avoid executable deserialization; it does not establish model provenance or behavioral safety
No catalog entries match that search.
Selection framework
How should teams evaluate the options?
Evaluate coverage across the supply chain you actually operate. Distinguish training-code provenance, dataset lineage, base-model provenance, and the identity of a fine-tuning or conversion process: a signed package does not prove that its weights or training data are trustworthy. A useful tool should identify artifacts with stable hashes, integrate with build and registry workflows, and produce evidence that downstream systems can verify. Check support for CycloneDX, SPDX, SLSA, Sigstore, and the model formats your teams exchange. Strong controls also define trust roots for external weights and datasets, key management, exception handling, and incident response. An inventory without verification is useful for visibility, but it does not by itself prevent artifact substitution or malicious loading.
- 01Provenance and signing support
- 02ML-BOM formats
- 03Registry and CI integration
- 04Policy enforcement
Record evidence and limitations for each criterion. A catalog listing is a discovery aid, not a security certification.
Primary references