How should security teams scan ML model files before loading them in CI/CD pipelines?

Why This Matters for Security Teams

Model files are not passive assets. In modern CI/CD, a model artifact can trigger deserialization code, unpack nested archives, load embedded tensors, or expose attacker-controlled metadata before any inference ever begins. That makes pre-load scanning a supply chain control, not a formatting check. Guidance from the NIST Cybersecurity Framework 2.0 reinforces the need to protect software and data pipelines before execution, while NHIMG research on the CI/CD pipeline exploitation case study shows how quickly pipeline trust can be abused once untrusted artifacts are allowed to run.

The practical problem is that many teams still treat model ingestion as a harmless import step. That assumption fails when the file format supports pickled objects, embedded scripts, symlinks, oversized payloads, or malicious archive members. Scanning before loading helps catch unsafe serialization patterns and integrity issues while the file is still inert. In practice, many security teams encounter malicious model behavior only after a pipeline runner has already parsed the artifact, rather than through intentional pre-load inspection.

How It Works in Practice

Effective model scanning starts with the same principle used for other untrusted artifacts: inspect first, execute later. The scanner should run offline in the CI job, process the model as bytes, and refuse any load operation until the artifact passes policy. For common ML formats, that means checking file signatures, archive contents, embedded references, and serialization constructs that can execute code during deserialization. Treat the model the way teams treat untrusted code from a third party, not like a CSV.

A robust workflow usually includes four checks. First, validate the file type and container structure so mislabeled archives and polyglot files are rejected. Second, inspect for unsafe opcodes, pickled objects, or other executable serialization paths. Third, scan for unexpected embedded resources such as scripts, binaries, or oversized members that can hide malicious payloads. Fourth, verify provenance and integrity so the model matches the approved source, build, and digest before it reaches training or inference. The Guide to the Secret Sprawl Challenge is useful here because model loading often happens in the same pipelines that also expose tokens, keys, and other secrets.

• Run the scanner before any library call that deserializes the model.
• Block unknown formats by default and allow only the formats the team can inspect.
• Use immutable digests so a passed scan cannot be swapped after approval.
• Fail closed in CI when parsing is incomplete or the file is truncated.

For teams building pipeline controls, the NIST Cybersecurity Framework 2.0 is the right operational anchor because it ties protection and integrity checks to the broader software supply chain. These controls tend to break down when the pipeline relies on custom model formats that the scanner cannot parse safely because the file is effectively opaque at that point.

Common Variations and Edge Cases

Tighter model scanning often increases build friction, requiring organisations to balance deployment speed against the risk of loading a weaponized artifact. That tradeoff is real, especially when teams support multiple frameworks, old serialization formats, or third-party models with no reliable provenance trail. Current guidance suggests prioritising deep inspection for high-risk formats first, then phasing in broader coverage as the scanner matures.

There is no universal standard for this yet, so some teams choose to block only known-dangerous constructs, while others enforce a strict allowlist of model families and trusted exporters. The second approach is safer, but it can slow experimentation and force conversion work for research teams. The first approach is easier to adopt, but it leaves more room for parser edge cases and malformed artifacts.

Reviewing incidents such as the Reviewdog GitHub Action supply chain attack and the Hugging Face Spaces breach helps security teams see the pattern: trust breaks at the artifact boundary, not after deployment. The safer operating model is to scan on arrival, verify provenance, and only then permit deserialization or promotion. That model becomes harder to sustain when researchers can upload arbitrary custom objects or when legacy jobs still depend on formats that mix data and executable state.

Related resources from NHI Mgmt Group

• How should security teams hunt for malicious logic in code repositories and CI/CD pipelines before it reaches production?
• How should security teams handle untrusted Parquet files in data pipelines and CI/CD jobs?
• How should security teams prevent typosquatting risks in package-lock.json files across CI/CD pipelines?
• How should security teams scan obfuscated JavaScript in CI/CD pipelines without blocking legitimate releases?