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

Why Model Files Need Pre-Load Inspection in CI/CD

Model files are not just blobs of weights. Many are serialized objects, archives, or package-like containers that can carry executable instructions, dangerous object graphs, or embedded dependencies that behave differently once a loader touches them. That is why pre-load inspection matters in CI/CD: the control point has to sit before deserialization, not after deployment, because the load step is where trust is actually granted. For teams that ship models quickly, the practical problem is often not whether a model is mathematically sound, but whether the file format itself can be abused as a delivery mechanism.

Security teams should also separate “model validation” from “file safety.” A model can be accurate, signed, and still unsafe to load if the serialization format allows code execution or if the archive contains unexpected payloads. That distinction is especially important when build systems automatically fetch artifacts from registries, shared storage, or partner pipelines. The right question is not whether the model is useful, but whether the pipeline can safely inspect it before any parser or runtime expands its contents. In practice, many security teams discover unsafe model handling only after a loader has already interpreted the file, rather than through intentional pre-load screening.

For teams that manage model artifacts across ownership boundaries, the same principle overlaps with non-human identity governance because the pipeline account, registry credential, or automation token becomes the trust boundary that approves the file.

What a Safe Pre-Load Scan Actually Checks

A useful scanner does more than look for malware signatures. It should understand the file families your teams actually use and inspect them offline so the scanner itself does not become part of the attack path. For serialized Python models, that means identifying object deserialization risks and unsafe opcodes. For archive-based formats, it means unpacking the container structure, checking for unexpected members, and validating whether nested files match the declared format. For modern model packages, it can also mean checking metadata, references, and embedded resources for signs that the file is doing more than storing learned parameters.

The operational goal is to stop the pipeline before the load step if any of these conditions are present:

• The format requires arbitrary object deserialization.
• The archive contains files that the model format does not need.
• Embedded code, scripts, or loaders appear in a location the build process will trust.
• The file claims one structure but behaves like another when unpacked.
• The scanner cannot reliably parse the specific format, which should be treated as a block condition rather than a pass condition.

Teams should also ensure the scan happens against the artifact as stored, not against a version already transformed by another tool. That distinction matters because some risks only appear in the original packaging. If the scanner must understand multiple formats, the safest pattern is a format-aware, offline inspection stage that produces a clear allow, block, or review decision before any training job, inference job, or CI worker opens the file. Where relevant, OWASP’s Non-Human Identity Top 10 is useful for understanding how automation credentials and machine-to-machine trust can widen the blast radius of a compromised pipeline. This guidance breaks down when teams treat an unsupported format as “just a data file” and allow a generic loader to make the trust decision instead of the scan gate.

Format Drift, False Confidence, and the Cases That Break Simple Rules

Tighter file inspection often increases pipeline friction, so organisations have to balance protection against release speed. That tradeoff becomes sharper when model formats evolve quickly or when data science teams use multiple frameworks that serialize differently. Guidance is not fully standardised across all ML ecosystems, so security teams should label scanner coverage honestly: “supported and inspected,” “supported with partial inspection,” or “not supported and blocked.”

Common edge cases include encrypted model bundles, custom pickling wrappers, and vendor-specific export formats where the file extension does not reveal the real structure. Another recurring issue is partial inspection that checks the outer archive but not the nested object stored inside it. That is not enough when the risky behavior lives one layer deeper. Teams should also be careful with exception handling: a failed parse is often a signal of tampering or unsupported complexity, not proof that the artifact is clean. If the scanner cannot inspect the actual serialization path the loader will take, the right response is to quarantine the artifact, not to trust the fallback.

Risk and Threat Considerations

Model files create a supply-chain exposure because they often cross trust boundaries before the environment that consumes them ever sees them. The main risks are arbitrary code execution through unsafe deserialization, payload smuggling inside archives, and blind trust in artifacts that arrive through automated pipelines.

Failure mechanism: An attacker or compromised upstream process places malicious structure inside a model file, then relies on the loader, unpacker, or conversion step to interpret it. If CI/CD loads the artifact before inspection, the malicious behavior can execute with the privileges of the build agent or connected service account.

Impact: The result can be pipeline compromise, exposure of secrets or credentials available to the build job, poisoned model promotion, or persistence in downstream training and inference environments.

Practitioner Guidance

What to prioritise: Block any model artifact that cannot be inspected in the same format and serialization path the loader will actually use. Unsupported or partially supported formats should be treated as higher risk, not as low confidence passes.

What to verify: Confirm that the scan runs offline, before deserialization, and against the original artifact bytes. Also verify that the scanner checks nested content, not only the top-level container, because many unsafe patterns hide in the second layer.

Decision rule: If a model format permits object loading, dynamic references, or embedded executable content, require a dedicated inspection gate before promotion. If the scanner cannot explain what it inspected, the pipeline should not auto-approve the file.

Practitioner takeaway: The safest pipeline is the one that treats model loading as an authorization event, not a convenience step, because the moment a parser is trusted is the moment an attacker can try to turn artifact handling into code execution.

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?