Should Model Security Scan Results Travel With the Artifact? Exploring Signed Attestation Approaches
Binding ML security scan results to artifacts as cosign attestations closes a critical gap in model supply chain security.
Most teams store ML model scan results (for pickle vulnerabilities, license issues, data leakage) only in CI logs or dashboards, with no cryptographic link to the deployed artifact — creating a broken audit trail. A practical solution is attaching each scan result as a cosign attestation bound to the OCI artifact's content digest, with cluster policy engines enforcing verification at startup. Three open questions remain: whether re-scans after scanner upgrades should append or overwrite attestations, whether signing responsibility belongs to producers or platform teams, and whether SLSA and in-toto frameworks can accommodate the non-reproducibility and other unique challenges of ML artifacts.
An Overlooked Gap in ML Supply Chain Security
When you run a security scan on a model or Agent bundle — checking for pickle deserialization vulnerabilities, license compliance issues, or data leakage risks — a critical question arises: where do those scan results actually end up?
In most teams' real-world workflows, scan results sit in CI logs or some dashboard, with no verifiable link between them and the artifact actually being deployed. In other words, the model you scanned and the model you deployed cannot be proven — at the system level — to be "the same verified object." This is exactly the thought-provoking engineering question raised on Reddit by a KitOps maintainer and Jozu co-founder.
This gap has well-established solutions in traditional software supply chains, but in the relatively young field of ML artifacts, the practical path remains unclear. Model files are large, use specialized formats (like pickle and safetensors), and have complex dependencies — making security attestation binding and propagation significantly more complicated than with ordinary binary packages.
Turning Scan Results Into Signed Attestations That Travel With the Artifact
The approach proposed in the thread is representative: attach each scan result as a cosign attestation to the OCI artifact, then have the cluster enforce policy checks at startup — rejecting any artifact that lacks the attestations required by policy.
The core logic of this mechanism is to move "security evidence" from external systems (CI logs, dashboards) into the artifact itself. Attestations are cryptographically bound to a specific artifact digest, so anyone can verify before deployment: Has this model been scanned for pickle vulnerabilities? Did the license check pass? Is the signature trustworthy?
This "evidence travels with the artifact" philosophy essentially transforms security from a one-time procedural action into an inseparable property of the artifact. Compared to leaving scan results in the pipeline, it addresses the problems of broken audit trails, environment drift, and deployment trust gaps. The author admits this approach "does work," but it also surfaces several challenges for which there are no ideal answers yet.
cosign is an open-source tool under the Sigstore project, designed specifically for signing, verifying, and attesting OCI container images and artifacts. Its core idea is to store signature information in the same OCI registry as the artifact, cryptographically bound via the artifact's content digest (SHA256) — any change to the artifact's content changes the digest, automatically invalidating the original signature. Attestation is an advanced capability cosign provides: it allows arbitrary structured metadata (such as scan reports, SBOMs, build logs) to be attached to an artifact in signed form, following the in-toto Attestation Framework, and can be automatically intercepted and verified at deploy time by Kubernetes policy engines (such as Kyverno or OPA Gatekeeper). OCI (Open Container Initiative) is the universal standard for container image and artifact distribution — no longer limited to containers, model files, Helm Charts, and more can all be packaged as OCI artifacts and stored in standard registries, which is the infrastructure prerequisite for bringing ML models into the supply chain security ecosystem.
Three Unresolved Engineering Challenges
How should re-scans be handled after a scanner upgrade?
Security scanners continuously update their rule sets and detection capabilities. A model that passes a scan today might expose new risks after a scanner upgrade. So the question becomes: after a re-scan, should you generate a new attestation, or re-sign to overwrite the existing result?
This involves versioning and time-validity of attestations. Keeping historical attestations aids audit traceability but causes metadata to accumulate on the artifact; overwrite-style updates are cleaner but lose the important context of "what a specific version of the scanner found at a specific point in time." The generally sound approach is to append rather than overwrite, recording the scanner version and timestamp in each attestation.
Who should sign — the producer or the consumer?
Another governance-level disagreement is whether signing responsibility should fall on the artifact producer or the platform team consuming it.
Producer signing means "I ran these checks on the model I produced" — naturally tied to source accountability. Platform team signing represents "we independently verified this before onboarding" — more aligned with zero-trust principles. In practice this often isn't an either/or choice; both parties sign their own attestations, forming a multi-party endorsement chain. Different signers answer different questions, and conflating them actually undermines the semantic clarity of the attestations.
Can SLSA and in-toto be applied to ML artifacts?
The author specifically asks whether any teams are using SLSA or in-toto formats specifically for ML artifacts. Both frameworks are widely adopted in traditional software supply chain security, used to describe build provenance and attestation chains.
Migrating them to machine learning scenarios is theoretically feasible and directionally correct — the in-toto attestation framework was designed to be extensible. But the non-reproducibility of model training, the difficulty of hashing datasets, and the unique risks of formats like pickle are all gaps that existing specifications haven't yet fully addressed.
SLSA (Supply chain Levels for Software Artifacts, pronounced "salsa") is a supply chain security framework led by Google and maintained by OpenSSF, defining four progressive levels from L1 to L4. Core requirements include: auditable build processes, verifiable provenance, and tamper-resistant build environments. in-toto is a lower-level attestation framework that allows defining a "layout" for each step in the software lifecycle (code commit, build, test, packaging) and collecting corresponding "link metadata," ultimately forming a complete attestation chain. The two aren't mutually exclusive: SLSA's Provenance format is actually built on the in-toto Attestation specification. The primary challenge in applying this system to ML artifacts is that model training is fundamentally non-deterministic — running the same code with the same data twice may produce different weights, making "reproducible builds" — a core SLSA high-level requirement — difficult to satisfy in ML settings. Datasets are also typically too large and dynamic to hash precisely the way source code can be.
Why This Question Deserves Industry-Wide Attention
As models and Agent bundles increasingly enter production environments, the seriousness of the question "what exactly are you deploying, and is it safe?" continues to grow. Pickle deserialization vulnerabilities can directly lead to remote code execution, license violations can create legal exposure, and training data leakage can trigger compliance violations.
Binding scan results as signed attestations and enforcing verification at the cluster level is a pragmatic path to transforming these abstract risks into enforceable, auditable control points. It draws on mature software supply chain security practices (cosign, OCI, policy engines) while exposing gaps unique to the ML domain.
It's worth noting that the discussion and perspectives above come from a single Reddit thread, and the original poster — as a maintainer of related tooling — openly acknowledges potential bias. Readers should evaluate independently based on their own context. But regardless of which format or signing strategy is ultimately adopted, the core premise that "security evidence should travel with the artifact rather than be scattered across the pipeline" genuinely points to a real and underestimated gap in current ML engineering practice.
Pickle deserialization vulnerabilities deserve a separate note on their severity: Python's pickle format executes arbitrary Python code during deserialization. An attacker only needs to embed a malicious payload in a model file to achieve remote code execution (RCE) on any machine that loads the model — no additional vulnerabilities required. Hugging Face has documented multiple real-world attack cases spread through malicious model files. The safetensors format was designed specifically as an alternative to address this problem — it only stores tensor data and does not support arbitrary code execution. However, a large number of existing models are still distributed in pickle format (.pkl, .pt, .bin), making pre-ingestion static scanning (tools like picklescan) a necessary line of defense. Binding scan results to artifacts as attestations ensures that unscanned pickle models cannot silently make their way into production clusters.
Related articles
Gaussian Process Bandit Optimization: Exploration Strategies and Inference Regret Guarantees
Cumulative regret guarantees in Bayesian optimization fail to reflect final recommendation quality. This article examines a new study that provides inference regret guarantees for Gaussian process bandit optimization through exploration query strategies and fill distance analysis, validated on hyperparameter optimization and control tasks.
The Most Detailed Codex Guide on Bilibili: From Installation to Real-World Practice
The most detailed Codex guide on Bilibili: from app store installation to daily work mode configuration, with a real coffee shop project demonstrating file organization, data extraction, dashboard creation, and other practical tasks. Learn to use Plan Mode and desktop pets to leverage Codex efficiently.
Appearance Compensation in Volume Rendering: Why RGB Accuracy Cannot Guarantee Density Correctness
Volume rendering research reveals that volumetric data perfectly reproducing external RGB views may still contain density errors: appearance compensation can double central density and keep external rays unchanged even when L2 error exceeds 14.52%. Density recovery depends on appearance capacity, spatial resolution, and measurement design.