EVIDENCE TRAIL
Model registry — version pinning, canary, rollback
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. No upstream document names a "model registry" or "canary stage" in exactly those words; the closest explicit endorsements are OWASP ASI04's "pin by content hash and require staged rollout" and MITRE ATLAS AML.M0014's "verify the cryptographic checksum of all AI artifacts."
Last cross-checked against upstream sources: · 7 sources
References
Each entry shows what the source supports and what it does not prove.
OWASP Top 10 for Agentic Applications 2026
§ASI04 Agentic Supply Chain Vulnerabilities — Prevention and Mitigation Guideline 7
"Pinning: Pin prompts, tools, and configs by content hash and commit ID. Require staged rollout with differential tests and auto-rollback on hash drift or behavioral change."
Supports: Verbatim upstream endorsement of version pinning + staged rollout + auto-rollback as the primary supply-chain control in agentic systems. Directly names the three mechanics this control deploys.
Does not prove: Scope is prompts, tools, and configs — not model weights specifically. Helmwart extends the same pin-and-rollback pattern to the model artifact layer.
OWASP Agentic AI — Threats & Mitigations v1.1
§T17 Supply Chain Compromise — Mitigation
"Secure agent ecosystems by digitally signing artifacts, use verifiable SBOMs (AIBOMs, Agent SBOMs), and apply version control with peer review. Enforce strong authentication across the supply chains, restrict untrusted tool installations, and run agents in sandboxed, isolated environments. Continuously monitor for drift or malicious behavior across the supply chain, and red-team agents with simulated supply chain attacks to validate defenses."
Supports: Names digitally signed artifacts, version control, and continuous drift monitoring as the three pillars for supply-chain defence — all delivered by a model registry with signed entries, version pins, and canary monitoring.
Does not prove: Does not mention model registries or canary stages by name. Prescribes the outcome (signed, versioned, drift-detected); the registry is the implementation mechanism.
NIST AI 600-1 — Generative AI Profile (NIST AI RMF)
GOVERN 1.6 — Suggested Action GV-1.6-003
"In addition to general model, governance, and risk information, consider the following items in GAI system inventory entries: Data provenance information (e.g., source, signatures, versioning, watermarks) … Underlying foundation models, versions of underlying models, and access modes."
Supports: Requires that AI system inventories record model versions, signatures, and data provenance — these are the exact fields a model registry stores. Provides regulatory grounding for the registry content.
Does not prove: Names inventory requirements, not the operational enforcement mechanism. Does not specify a canary stage or rollback path.
NIST AI 600-1 — Generative AI Profile (NIST AI RMF)
MEASURE 2.8 — Suggested Action MS-2.8-003 (context: digital content transparency and tamper-proof history)
"Robust version control systems can also be applied to track changes across the AI lifecycle over time."
Supports: NIST explicitly names version control of AI artifacts as a measurement control — the closest the 600-1 profile comes to endorsing registry-based versioning.
Does not prove: Appears as a supplementary note to a transparency action, not a standalone requirement. Applies to content provenance generally, not model weights specifically.
MITRE ATLAS AML.M0014 — Verify AI Artifacts
AML.M0014 description — ATLAS catalogue (sourced from mitre-atlas/atlas-data dist/ATLAS.yaml)
"Verify the cryptographic checksum of all AI artifacts to verify that the file was not modified by an attacker."
Supports: Direct upstream authority for the checksum-at-load step. The registry record is the canonical store of the expected SHA-256; the agent runtime performs the verification named here.
Does not prove: Does not describe the registry structure, version-pinning workflow, or canary stage. Scopes to artifact integrity check only.
MITRE ATLAS AML.M0008 — Validate AI Model
AML.M0008 description — ATLAS catalogue (sourced from mitre-atlas/atlas-data dist/ATLAS.yaml)
"Validate that AI models perform as intended by testing for backdoor triggers, potential for data leakage, or adversarial influence. Monitor AI model for concept drift and training data drift, which may indicate data tampering and poisoning."
Supports: Establishes the behavioural validation requirement that the canary stage satisfies: testing for backdoor triggers and drift before promotion is how a registry canary operationalises this mitigation.
Does not prove: Names validation as a monitoring practice, not as a gate in a staging workflow. Does not specify canary traffic fractions or held-out eval sets.
NIST SP 800-218 — Secure Software Development Framework (SSDF)
Practice PW.4 (Reuse Existing, Well-Secured Software) — Sub-practice PW.4.1 with Examples 3, 4, 5
"PW.4.1: Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks) from commercial, open-source, and other third-party developers for use by the organization's software. … Obtain provenance information (e.g., SBOM, source composition analysis, binary software composition analysis) for each software component, and analyze that information to better assess the risk that the component may introduce. … Establish one or more software repositories to host sanctioned and vetted open-source components. … Maintain a list of organization-approved commercial software components and component versions along with their provenance data."
Supports: SSDF PW.4.1 names software repositories of vetted components + provenance records + approved version lists as the implementation pattern — the exact structure a model registry delivers for AI artifacts.
Does not prove: SSDF was written for software components; model weights are an analogy, not the stated scope. No mention of canary stages or ML-specific drift monitoring.