ML Vulnerability Scanner Software: Static vs Dynamic Tools

Search for ml vulnerability scanner software and the results blur together two genuinely different product categories: tools that inspect a serialized model file for malicious code before it ever loads, and tools that probe a running model’s outputs for jailbreaks, prompt injection, and data leakage. Buying the wrong one leaves a real gap — a static scanner won’t catch a jailbreak, and a red-team harness won’t catch a booby-trapped pickle file sitting in your Hugging Face cache. That pickle problem gets its own writeup in unsafe model deserialization. Here’s what’s actually available in each category, what it catches, and where it falls short.

Static model-artifact scanners

Most “ML vulnerability scanner” search traffic is really about supply chain risk: someone downloads a .pt, .h5, or .pkl file from a public hub and needs to know it won’t execute arbitrary code on load. This is squarely OWASP’s ML06:2023 AI Supply Chain Attacks category, and it exists because Python’s pickle format — still the default serialization for PyTorch checkpoints — was never designed to handle untrusted input safely.

Protect AI’s ModelScan is the reference open-source tool here. It’s Apache 2.0 licensed, installs via pip install modelscan, and does static byte-level analysis of Pickle, Protocol Buffer (TensorFlow), HDF5, and Keras V3 files without executing them, flagging code paths that could enable credential theft, data theft, or model/data poisoning with CRITICAL-to-LOW severity ratings. Protect AI itself was acquired by Palo Alto Networks in 2025, and the commercial descendant of ModelScan now lives inside Prisma AIRS.

Trail of Bits’ fickling takes a different angle: it’s a decompiler, static analyzer, and bytecode rewriter for pickle streams, released under LGPL-3.0. Instead of just flagging known-bad signatures, it can decompile a pickle file into readable Python, trace execution against an import allowlist, and raise UnsafeFileError at load time when something outside that allowlist tries to run. HiddenLayer sells a commercial equivalent — its Model Scanner covers 35+ model formats including GGUF and safetensors and is integrated into Microsoft’s Azure AI Foundry model catalog, per Microsoft’s own writeup.

None of this is a solved problem. A recent arXiv paper, ShadowPickle, tested three stealthy pickle deserialization techniques — overwriting whitelisted modules like collections.OrderedDict, abusing PyPI packages that support code execution, and smuggling logic through external files packaged alongside a model — against five open-source scanners (PickleScan, ModelScan, fickling, weights-only unpickler, ModelTracer) plus hub-integrated commercial scanners from JFrog, Protect AI, ClamAV, and VirusTotal. The overwritten-module technique alone evaded scanners 63% of the time, and across all three techniques and 15,000 scanner tests, 48.5% went undetected. The practical takeaway: a green scan result is evidence, not proof. Prefer safetensors over pickle wherever the model publisher supports it, and don’t treat any single scanner as a final gate.

Dynamic LLM red-team scanners

The second category tests behavior, not files. These tools send a running model — via API or local weights — a battery of adversarial prompts and score the responses for failure modes like jailbreak susceptibility, training-data regurgitation, toxic output, and prompt injection.

NVIDIA’s garak is the closest thing this space has to a de facto standard. It’s Apache 2.0, installs with pip install -U garak, and its latest release (v0.14.0, February 2026) ships redesigned HTML reporting. Point it at a target with --target_type and --target_name, pick probe modules, and it runs static, dynamic, and adaptive probes covering prompt injection, DAN-style jailbreaks, encoding-based attacks, package hallucination, glitch tokens, toxicity, and data leakage, logging structured JSONL output for diffing across model versions. It works against OpenAI, Hugging Face, Bedrock, Cohere, Groq, and Ollama endpoints, which makes it usable in CI against whichever model you’re actually shipping. Our wider AI supply chain security tool guide places it against the artifact-scanning side.

Microsoft’s PyRIT (Python Risk Identification Tool) is the other major open-source entry, MIT licensed and built specifically to give security teams and red-teamers a scriptable framework for probing generative AI systems for risk rather than a fixed probe library — it’s closer to a testing harness you compose than an out-of-the-box scan-and-report tool like garak. Teams building custom LLM red-team pipelines tend to reach for PyRIT; teams that want a broad, ready-made probe suite tend to start with garak. For deeper coverage of the underlying attack techniques both tools are built to catch, aisec.blog tracks prompt injection and jailbreak research in more depth than a scanner comparison can.

Picking one for your pipeline

For a CI/CD gate on third-party model downloads, run a static scanner — ModelScan or fickling, or HiddenLayer’s commercial platform if you need broader format coverage and a support contract — before any artifact reaches a serving environment. Given the ShadowPickle evasion numbers, pair the scan with a format-level control: reject pickle entirely where a safetensors build exists, rather than trusting the scanner as the only check.

For anything you’re fine-tuning or exposing behind an API, run garak or a PyRIT-based harness before launch and again after every fine-tune, since alignment behavior can regress silently. For the artifact side of the same programme, see malicious model file detection. Neither tool replaces the other — static scanners protect the supply chain, dynamic scanners protect the deployed behavior — and a real ML security program budgets for both plus a place to track findings and disclosures over time. If you’re building that tracking layer, ai-alert.org maintains an incident and CVE feed specifically for ML and LLM vulnerabilities, which is a useful companion to whatever scanner output you’re already generating internally.