Which scanner fits your model intake: ModelScan or picklescan
Choose ModelScan when your intake includes Keras H5, Keras V3, TensorFlow SavedModel or other non-pickle formats, because ModelScan reads those files byte by byte for unsafe code signatures without loading them. Choose picklescan when the intake is pickle or PyTorch files and your gate runs on Python 3.11 or newer, since picklescan 1.0.5 requires that version. A team pulling models from several sources needs one gate in front of every load, so start with an inventory: list each model format, each source and each Python interpreter the gate will run on. Make that inventory before you commit to either tool.
Five drivers decide the choice. Formats come first: ModelScan covers PyTorch pickle, TensorFlow SavedModel and Protocol Buffer, Keras H5 and V3, and classic ML files saved with Pickle, Cloudpickle, Dill and Joblib, while picklescan centers on pickle and PyTorch archives and also scans NumPy .npy files when numpy is installed. Python version comes second: ModelScan 0.8.8 supports Python 3.10 up to but not including 3.13, so a team on 3.10 can run ModelScan but not picklescan 1.0.5. Hugging Face handling is third: picklescan can scan a model by repository name with --huggingface, and the supplied ModelScan material does not describe an equivalent mode, so confirm that before you rely on it. Severity reporting and CI exit behavior complete the list: ModelScan ranks findings CRITICAL, HIGH, MEDIUM or LOW and offers nonzero exit codes for pipelines, so confirm how picklescan reports severity and exit status in your version.
Before you decide, run both tools against a sample of your own files, including one file you know is unsafe, and record the output format and exit code each one produces in your pipeline. Hugging Face runs its own pickle import scan on files pushed to the Hub, but its Pickle Scanning documentation says the scan is not foolproof, so keep a local gate regardless of what the Hub reports. If your team can adopt only one tool, pick the one that matches your dominant format, then plan a second check for the formats it does not cover.
Which scanner is the better fit for each intake scenario
This table maps common intake scenarios to the scanner that fits each one, based on the file formats, Python versions and CI behavior each tool documents. Read the middle column first, then check the condition against your own pipeline. The main takeaway is that picklescan suits pickle-centric and Hugging Face name lookups, while ModelScan suits mixed Keras and TensorFlow intake and severity-based CI gates.
| Intake scenario | Better fit | Condition that drives the choice |
|---|---|---|
| PyTorch-only pipeline | picklescan | Intake is limited to pickle-based PyTorch checkpoints and zip archives, and a small MIT-licensed tool is enough. |
| Mixed Keras and TensorFlow intake | ModelScan | You receive Keras H5, Keras V3 or SavedModel files alongside pickle-based models. |
| Scanning Hugging Face models by name | picklescan | Its Hugging Face option scans a model by name, so you can skip a manual download step. |
| CI gating with severity thresholds | ModelScan | It ranks findings CRITICAL to LOW and returns nonzero exit codes; confirm picklescan's output before gating on it. |
| Locked Python 3.13 or newer environments | picklescan | ModelScan 0.8.8 supports Python up to but not including 3.13, while picklescan 1.0.5 needs Python 3.11 or newer. |
| Python 3.10 environments | ModelScan | picklescan requires Python 3.11 or newer, so ModelScan 0.8.8 is the option that runs on 3.10. |
| Classic ML files saved with Joblib, Dill or Cloudpickle | ModelScan | These formats are part of its documented coverage, so one scan can span them alongside other model files. |
| NumPy .npy files in the same intake | picklescan | It scans .npy files when numpy is installed; confirm ModelScan's handling of .npy before relying on it. |
How ModelScan and picklescan read model files differently
ModelScan and picklescan both look for dangerous code in serialized model files, but they start from different assumptions about what a file is and where it lives. The cards below separate those choices so you can map them onto your formats, your pipeline and the machines that run the scan.
Byte-level signature matching
ModelScan reads model files byte by byte and looks for unsafe code signatures instead of loading the file. Because embedded code never runs, the scan can be done on an inspection host that has no ML framework installed. picklescan works at the level of pickle opcodes and globals, so it needs a Python runtime that can parse those structures. Check which layer your intake process trusts before deciding where each scanner sits.
Format coverage beyond pickle
ModelScan covers PyTorch pickle files, TensorFlow SavedModel and Protocol Buffer files, Keras H5 and Keras V3 files, and classic ML formats saved with Pickle, Cloudpickle, Dill and Joblib. picklescan is aimed at pickle files, including PyTorch archives, and scans NumPy .npy files when numpy is installed. If your inventory includes Keras or SavedModel artifacts, picklescan alone leaves those formats uncovered.
Scan time relative to file reads
ModelScan's README says a scan takes about as long as reading the file from disk, because it does not deserialize anything. picklescan parses the pickle stream, so its cost depends on the structure of the file and on how many archive members or remote files it must fetch. Ask your team to time both tools on your largest real artifacts, especially when scans run on every commit or every download.
Sources the scanner accepts
picklescan loads pickles from local files, directories, URLs and zip archives, and can scan a Hugging Face model by name with its --huggingface option. This makes it convenient for ad hoc checks of remote models. ModelScan's documented inputs are model files you point it at, so you will usually fetch artifacts into a controlled staging area first. Decide which path your model intake takes and keep one fetch path so the scanned bytes match the bytes you load.
Python runtime requirements
picklescan 1.0.5 requires Python 3.11 or newer. ModelScan 0.8.8 supports Python 3.10 up to but not including 3.13. The two versions overlap only on Python 3.11 and 3.12, so a shared CI image may force a choice. Confirm the interpreter in your build image before pinning either package, and check whether the scanner runs in the same environment as your model code or in a separate scanning job.
Feature comparison of ModelScan and picklescan
This table compares ModelScan and picklescan on license, latest release, Python support, file formats, Keras and TensorFlow coverage, Hugging Face scanning, severity ratings, CI exit codes and Python API. Where a cell says to confirm, the project documentation does not settle the point, so run a test scan on your own model files before you depend on that capability.
| Capability | ModelScan | picklescan |
|---|---|---|
| License | Apache-2.0 | MIT |
| Latest release in the supplied facts | 0.8.8, released February 18, 2026 | 1.0.5, released July 1, 2026 |
| Python support | Python 3.10 up to but not including 3.13 | Python 3.11 or newer |
| Formats covered | PyTorch pickle, TensorFlow SavedModel and Protocol Buffer, Keras H5 and V3, Pickle, Cloudpickle, Dill and Joblib | Python pickle files, PyTorch zip archives, and NumPy .npy files when numpy is installed |
| Keras and TensorFlow coverage | Keras H5, Keras V3 and TensorFlow SavedModel are listed in the README | Not listed in the supplied facts; confirm against your Keras and SavedModel files |
| Hugging Face scanning by name | Not covered in the supplied facts; confirm in the ModelScan documentation | Scans a model by name with the --huggingface option |
| Severity ratings | CRITICAL, HIGH, MEDIUM and LOW | Reports the dangerous globals it finds; confirm whether it assigns severity levels |
| CI exit codes | CLI returns nonzero exit codes for pipeline gating | Not stated in the supplied facts; confirm exit behavior with a test run that has a flagged file |
| Python API | Python API offered for CI/CD pipelines | Not stated in the supplied facts; confirm whether a Python API is documented before wrapping it |
What each license and edition covers for your team
ModelScan is an Apache-2.0 open-source project from Protect AI. The Apache-2.0 license permits commercial use, modification and internal redistribution, and it includes an explicit patent grant, which many legal teams want to see before adopting a scanner into a regulated build pipeline. Protect AI is the maintainer, so questions about roadmap, releases and security fixes go to the project's GitHub repository and release notes.
- License: Apache-2.0, which you should confirm against the LICENSE file in the repository before you record it in your software bill of materials.
- Maintainer: Protect AI, which also publishes the commercial Guardian product.
- Releases: ModelScan 0.8.8 was released on February 18, 2026, and supports Python 3.10 up to but not including 3.13, so check your interpreter version before you pin it.
- Format coverage: the README lists PyTorch Pickle, TensorFlow SavedModel and Protocol Buffer, Keras H5 and Keras V3, and classic ML formats saved with Pickle, Cloudpickle, Dill and Joblib.
- Cost: no license fee applies to the open-source tool, but your team pays for the engineering time to install, pin, run and update it.
Before adoption, confirm the current release, the supported Python versions and the license file in the repository with your legal and platform teams.
picklescan is an MIT-licensed security scanner by Matthieu Maitre. The MIT license is short and permissive, and it places few obligations on downstream users beyond keeping the copyright and license notice. It is the tool that Protect AI credits as the inspiration for ModelScan, so the two projects share a lineage, but they are separate codebases with separate maintainers and release cycles.
- License: MIT, a permissive license with minimal notice requirements.
- Maintainer: Matthieu Maitre, as the author of the repository and PyPI package.
- Releases: picklescan 1.0.5 was released on July 1, 2026, and requires Python 3.11 or newer.
- Scope: the tool focuses on pickle files and reports the dangerous globals it finds, with support for local files, directories, URLs, zip archives and the
--huggingfaceoption. - Cost: no license fee applies, but your team owns the integration work, version pinning and any changes needed for your Python baseline.
Confirm the current license file and the release history on PyPI and GitHub before you standardize on it, since maintenance commitments are not stated in the supplied facts.
Guardian is the enterprise model scanning product that Protect AI describes as separate from the open-source ModelScan project. Protect AI says Guardian includes newer scanners, broader model support and enforcement for Hugging Face models. Because it is a commercial offering, its license, editions, pricing and contractual terms sit outside the open-source projects and must come from Protect AI directly.
- Newer scanners: Protect AI says Guardian includes scanners that are newer than those in the open-source projects. Ask which scanners are included and how they are updated.
- Broader model support: Protect AI states that Guardian covers more model types than ModelScan. Ask for the exact list of formats in writing.
- Enforcement for Hugging Face models: Protect AI says Guardian can enforce scanning for Hugging Face models. Ask how enforcement is configured and what happens to a flagged model.
- Terms and pricing: these must come from Protect AI, and the supplied facts do not include any price or license term.
- Support: ask whether support, service levels and update channels are included, and whether they are quoted separately.
Request a written description of the editions, deployment options and terms from Protect AI before you compare Guardian with the open-source tools on cost.
What drives the running cost of each scanner
Both scanners are free to download under open-source licenses, so the money goes into the work around them: wiring the gate into CI, keeping Python and dependency versions current, and training people to read findings. The four areas below show who is paid for each piece and what to put in a written quote.
One-time CI gate setup
Wiring either scanner into a pipeline means choosing where it runs, which paths it scans, and how a nonzero exit code blocks a merge or deployment. picklescan is a library-style check you call from your own script, while ModelScan ships a CLI with nonzero exit codes and a Python API, so the integration code differs. Your internal platform team or a services partner pays for this work once, and it should cover scanning model artifacts before they reach loading code, not only on the training host. Ask the quote to name the pipeline stages, the artifact stores and the failure handling.
Pinning and upgrading against Python
Both tools are maintained projects, so the recurring cost is keeping them current with your Python runtime. The supplied facts give ModelScan 0.8.8 with support for Python 3.10 up to but not including 3.13, and picklescan 1.0.5 requiring Python 3.11 or newer. A Python upgrade can therefore force a scanner upgrade or a split between environments. Budget an owner for each release, and ask a partner to state how upgrades, regression tests and rollbacks are handled.
Staff time for severity and triage
ModelScan ranks findings as CRITICAL, HIGH, MEDIUM or LOW, while picklescan reports the dangerous globals it finds. Someone must decide which levels fail a build, which findings are false positives on trusted internal models, and who signs off on exceptions. This is recurring labor that depends on model intake volume and on how many teams pull public checkpoints from the Hugging Face Hub. Ask for named triage roles, a written exception process and the time expected for each review.
Paid support and enterprise tiers
ModelScan is Apache-2.0 open source, and Protect AI describes Guardian as its enterprise product with newer scanners, broader model support and enforcement for Hugging Face models. picklescan is MIT-licensed with no vendor tier described in the supplied facts. If a paid tier is on your shortlist, ask the vendor in writing which scanners, model formats and enforcement features it adds, what support windows apply, and whether it replaces or sits beside the open-source CLI in your pipeline.
Moving a scan gate from picklescan to ModelScan or back
This sequence moves a model intake gate from one pickle scanner to the other without a gap in coverage. It ends with a CI step that fails builds on the right findings and a documented record of what each tool flagged during the parallel run.
Inventory formats and Python versions in the pipeline
The platform or ML engineering lead lists every model format that enters the pipeline, such as PyTorch pickle files, Keras H5 or V3, TensorFlow SavedModel, joblib, dill or cloudpickle artifacts, and NumPy .npy files, along with the Python version each CI runner uses. ModelScan supports Python 3.10 up to but not including 3.13, and picklescan 1.0.5 requires Python 3.11 or newer, so a runner on Python 3.13 or 3.9 rules out one tool or the other until the image changes. The step closes when the list is written down and each format has a named owner and a supported scanner version.
Assemble a known sample set of model files
The security engineer builds a sample set from artifacts the team has already accepted, plus a small set of files that are known to contain unsafe globals, drawn from internal test fixtures or public research samples the team is permitted to store. Keep the clean and the flagged files in separate folders so that results can be checked against expectations. The step closes when the set covers every format from the inventory and the expected result for each file is recorded before any scanner runs.
Run both scanners on the same files
The engineer runs picklescan and ModelScan against the identical sample set using the same working directory and captures the console output, exit codes and any report files for each run. ModelScan reads files byte by byte and does not load them, which makes it safe to run on untrusted samples, but the team should still run both tools inside an isolated runner. The step closes when every file has a result from each tool, stored with the tool version and the Python version used.
Compare findings and severity labels
The security engineer builds a table with one row per file and columns for each tool's verdict, the dangerous globals reported, and the severity. picklescan reports the dangerous globals it finds, while ModelScan ranks findings as CRITICAL, HIGH, MEDIUM or LOW, so the team must decide how each ModelScan level maps to the existing accept or block rules. Document each disagreement and whether it is a gap, a false positive or a labeling difference. The step closes when every disagreement has a recorded decision and the severity mapping is approved by the policy owner.
Update the CI step and exit-code handling
The DevOps engineer adds the new scanner as a parallel CI job that runs on the same trigger as the current gate, then configures the exit-code behavior so that a nonzero ModelScan exit fails the job the same way the existing check does. The engineer also confirms how each tool handles errors, such as unsupported files or parse failures, so that an unreadable file does not pass silently. The step closes when a test commit with a known bad file fails the new job and a clean commit passes it.
Run both gates in parallel
Both jobs run on every model intake for a period the team sets in its change plan, and only the old gate's result blocks merges while the new one reports. The triage lead reviews every disagreement between the two jobs and records whether the new tool caught something the old one missed or the reverse. The step closes when the disagreement log shows no unresolved cases and the triage lead signs off that the new gate's decisions match or improve on the old ones.
Retire the old scan step
Once the parallel run is signed off, the DevOps engineer removes the old picklescan job from the pipeline, deletes its runner dependencies, and makes the new job a required check on the protected branch. The team also updates the scanner version pins and the internal documentation so that the next person knows which tool is in force. The step closes when the old job no longer appears in pipeline runs, the required check is confirmed in the repository settings, and the change record names the approver.
Carry over policy and rebuild triage rules
The intake policy and the approved model list transfer unchanged, because they describe what the organization accepts from which sources, not which scanner runs. The CI configuration, the scanner version pins and the triage rules that map findings to decisions must be rebuilt for the new tool's output and labels. The security lead confirms in writing which items moved as is and which were rewritten, and keeps the same sample set for future regression checks. The step closes when the policy document references the new gate and the triage rules are tested against the sample set.
Where ModelScan and picklescan projects usually run long
The delays that most often stall a ModelScan or picklescan rollout are Python version conflicts, not scanning itself. ModelScan 0.8.8 supports Python 3.10 up to but not including 3.13, while picklescan 1.0.5 requires Python 3.11 or newer. A shared CI image or a single virtual environment built for one tool can therefore block the other. Decide early whether each tool gets its own environment or container, and confirm the interpreter version in your pipeline image before you write the scan step. Pin both versions in your dependency files so a later upgrade does not silently move one tool outside its supported range.
Plan time for triage of findings. Both tools flag pickle opcodes that import dangerous globals, and some legitimate model files (custom layers, preprocessing objects or older checkpoints) will trigger them. Agree in advance who reviews a flagged file, what evidence is needed to accept it, and whether a rejected file is quarantined or deleted. ModelScan ranks findings as CRITICAL, HIGH, MEDIUM or LOW, so a written rule for which severities block a release avoids a debate on every pull request. Record each accepted exception with the file hash so the same finding does not reappear as a new incident.
Mixed inventories also add work. ModelScan covers PyTorch, TensorFlow SavedModel, Keras H5 and Keras V3, and classic ML formats saved with Pickle, Cloudpickle, Dill and Joblib. picklescan centers on pickle files, with NumPy .npy support when numpy is installed. Inventory the formats your teams actually load before choosing, because a scanner that does not read a format leaves that format unchecked. For Hugging Face models, decide whether to scan by name with picklescan's --huggingface option or to download files and scan them locally. Scanning by name is quicker to set up but depends on the tool fetching the files at scan time, while downloading first lets you hash and store the exact artifact you tested. Finally, confirm in each project's current documentation how exit codes behave when findings or errors occur, and whether the Hugging Face Hub runs its own scanning on files you pull, as Hugging Face's pickle scanning documentation describes for the Hub itself.
Questions buyers ask before choosing or hiring help for model scanning
Does ModelScan replace picklescan?
Not automatically. ModelScan is a separate Apache-2.0 project from Protect AI that reads model files byte by byte for unsafe code signatures and covers more formats, including TensorFlow SavedModel, Keras H5 and Keras V3, and classic ML formats saved with Joblib, Dill and Cloudpickle. picklescan is an MIT-licensed scanner focused on pickle files, and it can scan NumPy files and Hugging Face models by name with --huggingface. The practical question is which formats your pipeline actually receives. If every model is a PyTorch pickle that already passes through picklescan, switching has a cost that may not buy coverage. If you also accept Keras or TensorFlow artifacts, ModelScan fills a gap. Many teams run both and compare the findings on a sample of their real intake before deciding.
What does implementing a model scanning gate involve?
The work splits into intake inventory, tool selection, pipeline placement and triage. You list every model source and format, decide where scans run (developer workstation, CI job, or the registry step before deployment), and define what happens on each severity level. ModelScan's README recommends scanning before loading pre-trained models, after training and before deployment, so placement is a design decision with several touchpoints. Effort rises with the number of model formats, the number of repositories and registries, the volume of third-party models, and how many findings need human review. Ask a consultant to document each of these drivers in the written scope before any work starts.
Can our team run picklescan or ModelScan without outside help?
Often yes, for a small and stable set of formats. Both tools are open source and run from the command line, and ModelScan offers a CLI with nonzero exit codes and a Python API. The work that usually needs experienced staff is not installing the tool. It is deciding the policy: which findings block a model, how exceptions are approved, how scan results are retained as evidence, and how the tools are upgraded as formats change. picklescan 1.0.5 requires Python 3.11 or newer, and ModelScan 0.8.8 supports Python 3.10 up to but not including 3.13, so runtime versions are a constraint your platform team must plan around. If you lack capacity to own those decisions, a fixed-scope engagement can document them.
How long does it take to add a model scan to CI?
The duration depends on the drivers rather than a standard figure. Scan time is shaped by model file size and count, because ModelScan reads files rather than loading them, so a scan takes about as long as reading the file from disk. Other drivers are the Python version your runners use, how many pipelines need the gate, whether scan results feed a ticketing or SIEM system, and how much triage process has to be agreed with model owners. Start with one pipeline that handles a single model format, measure your own scan times on representative files, and use those measurements when you estimate the rest of the rollout.
What should we ask a consultant for in a fixed-scope quote?
Ask for a written scope that names the tools, the model formats in scope, the pipelines and registries where scans run, and the exit-code policy that blocks a deployment. Request deliverables such as the pipeline configuration, the triage runbook, the documented upgrade procedure for each tool, and the evidence format for scan results. Confirm which environments are covered (your cloud accounts, data centers or air-gapped networks), who performs handover, and what happens to changes requested after the scope is agreed. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's infrastructure and works from written scope, so ask for the same level of detail from any provider you compare.
Does Hugging Face's own scan make a local scanner unnecessary?
No. Hugging Face scans every file pushed to the Hub with ClamAV and a pickle import scan that lists imports without executing them, and its documentation says the scan is not foolproof. That check runs on the Hub, not on the files your team downloads, copies between buckets, or receives from partners. A local scanner gives you a gate you control, a policy you can audit, and results you can keep as evidence. Hugging Face's scan is a useful additional layer, and the two can be complementary. Confirm with your security team how models enter your environment before deciding whether a local gate is required.
How DeployOpen helps choose, implement or migrate model scanning
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so model file scanning can run where your models are stored and loaded. We start from your model formats, pipelines and existing controls, then agree the scope in writing before any work begins.
How we scope
- Inventory the model formats your teams load, such as PyTorch pickle, Keras H5 or SavedModel files
- Document where scans should run: before download, after training, or before deployment
- Agree in writing whether ModelScan, picklescan or both fit your pipeline and risk tolerance
- Confirm which Python versions your build images support before choosing a tool version
How we build
- Wire the chosen scanner into your CI pipeline so the exit code gates merges or deployments
- Configure severity thresholds and document how CRITICAL and HIGH findings are triaged
- Test the scanner against known-unsafe sample files and clean files in your own environment
- Set up scanning for internal model registries and any approved Hugging Face downloads
How we hand over
- Deliver written runbooks covering install, pinned versions, scan commands and exit code handling
- Document the limits of signature-based scanning and the controls that complement it
- Provide evidence records of scan results that your compliance and security teams can review
- Walk your engineers through triage steps for findings, including false positive review
How we support
- Offer ongoing support, upgrades and re-testing as a retainer after the fixed-scope work ends
- Review scanner releases and Python compatibility changes and plan upgrades with your team
- Re-run the test set when your model formats or loading practices change
