← Domains & pillars

SecurityView domain

APRF-24

Supply Chain Integrity

Prove provenance and integrity of models, containers, MCP servers, and AI dependencies.

Purpose

Ensure model artifacts, inference images, tools, MCP servers, and third-party AI dependencies are authenticated, reviewed, and verifiable—applying SLSA-style integrity to the AI stack.

Mandatory checks

Gate controls. Each check is pass/fail via artifact + pass condition. Expected from the annotated capability level when the system meets the minimum criticality tier.

  • SCI-M1L3 · DefinedTier 2 · ProductionhybridE3

    Production model and container artifacts shall have verified provenance/integrity—proven by signature, attestation, or digest verification with unverified pulls blocked, not by digest pins in Dockerfiles alone.

    Artifact
    Signature / attestation / provenance / checksum verification config (cosign, Notation, SLSA, OCI, or equivalent); Digest or signature verification logs for production model/container pulls in the sample window; Proof unverified pulls are blocked (admission policy, registry policy, or deploy gate; measuredAt ≤90 days)
    Pass condition
    Provenance/integrity verification is configured for production model and/or container artifacts (signature, attestation, OCI provenance, and/or checksum/ digest); 100% of production model/container pulls in the sample window verify against expected digest or signature; unverified pulls are blocked (measuredAt ≤90 days). If no production model or container artifacts are pulled, score NOT_APPLICABLE.

    Why this control exists

    Threat map

    Ensure production AI artifacts come from a verified source and have not been tampered with.

    Threats mitigated

    Supply Chain CompromiseData and Model PoisoningUnsafe Code Execution

    Protects

    ModelsInfrastructureRuntime

    MITRE: ATLAS AML.T0010 · ATLAS AML.T0058 · ATLAS AML.T0018.002 · ATLAS AML.T0076 · ATLAS AML.T0109 · ATT&CK T1195 · ATT&CK T1195.002

    Model weights are executable artifacts that can carry embedded malware or behavioural backdoors which evaluation will not surface. Verified provenance and integrity is the only reliable control against substituted, poisoned, or rug-pulled artifacts.

    Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.

  • SCI-M2L3 · DefinedTier 2 · ProductionhybridE3

    Production external AI tools, MCP servers, agent plugins, and high-impact integrations shall be inventoried with version pins, named owners, and recurring review—proven by an inventory covering those surfaces with 0 unpinned “latest”/floating entries, not by CI Action SHA pins or package lockfiles alone.

    Artifact
    Inventory of production external AI tools, MCP servers, agent plugins, and high-impact integrations with version pins, owners, review dates ≤180 days, and 0 unpinned latest/floating entries (measuredAt ≤90 days)
    Pass condition
    100% of production external AI tools, MCP servers, agent plugins, and high-impact integrations have version pin + owner + review date ≤180 days; 0 unpinned “latest” (or floating) entries in production (inventory evidence measuredAt ≤90 days). If none of those surfaces exist in production, score NOT_APPLICABLE.

    Why this control exists

    Threat map

    Ensure every external tool, MCP server, and plugin in production is known, pinned, and reviewed.

    Threats mitigated

    Supply Chain CompromiseTool AbuseUnauthorized Tool UsePrompt Injection

    Protects

    ToolsExternal SystemsRuntimeData

    MITRE: ATLAS AML.T0010.005 · ATLAS AML.T0104 · ATLAS AML.T0110 · ATLAS AML.T0011.002 · ATLAS AML.T0099 · ATLAS AML.T0109 · ATT&CK T1195

    MCP servers and agent plugins execute with the agent's privileges and can silently redefine their own tool descriptions after installation. Inventory, version pinning, and pre-production review counter poisoned and rug-pulled tools, which are the primary agentic supply-chain techniques.

    Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.

  • SCI-M3L3 · DefinedTier 2 · ProductionhybridE3

    Production AI artifacts—including language dependencies, OCI/container images, serverless packages, and model-serving runtimes—shall be scanned for vulnerabilities before promotion, with organization-defined critical findings blocking deploy unless waived with owner and expiry—not by scanning app deps while skipping inference servers or CUDA stacks.

    Artifact
    Vulnerability scanner config + promote-path critical block (org policy) + retained scan results with 100% coverage and 0 skipped scans for production AI artifacts (measuredAt ≤90 days); critical waivers with owner + expiry ≤14 days
    Pass condition
    100% of production AI artifacts in the sample window (language dependencies, OCI/container images, serverless packages, and model-serving runtimes including inference servers and accelerator libraries in scope) were vulnerability-scanned with no skipped scans; findings that are critical per organizational policy block promotion unless waived with named owner and expiry ≤14 days; scan results are retained (evidence measuredAt ≤90 days). If no production AI artifacts are built or deployed, score NOT_APPLICABLE.

    Why this control exists

    Threat map

    Block deployment of AI artifacts carrying known exploitable vulnerabilities.

    Threats mitigated

    Supply Chain CompromiseUnsafe Code ExecutionPrivilege Escalation

    Protects

    InfrastructureRuntimeModels

    MITRE: ATLAS AML.T0010 · ATLAS AML.T0049 · ATT&CK T1195 · ATT&CK T1190 · ATT&CK T1068

    AI runtimes pull large, fast-moving dependency trees that include deserialization-prone model loaders and inference servers. Scanning gates keep known-vulnerable components out of production and shrink the exploitable surface.

    Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.

  • SCI-M4L5 · OptimizingTier 3 · Mission CriticalhybridE3

    Production deployment policy shall enforce blocking of unsigned, unapproved, and revoked-signature AI artifacts on the deploy path—proven by policy plus deny/verification logs, not by signing in CI or digest pins alone. Applies via Kubernetes admission, pipeline gates, cloud deploy policies, artifact registry rules, or AI-platform promote gates—not Kubernetes-only.

    Artifact
    Deployment policy configuration (admission, pipeline, cloud deploy policy, registry, or AI-platform gate) + deny/verification logs for unsigned, unapproved, and revoked/untrusted signatures (measuredAt ≤90 days)
    Pass condition
    Production deployment policy is enforced on AI artifact deploy/promote paths; unsigned artifacts are blocked; unapproved artifacts are blocked; revoked or untrusted signatures are rejected; deployment or admission deny/ verification logs prove enforcement (measuredAt ≤90 days). If no production AI artifacts are deployed (models/containers/serverless AI packages), score NOT_APPLICABLE. Required from capability Level 5 (advanced mandatory)—not a Tier 2/Core baseline.

    Why this control exists

    Threat map

    Enforce at the deployment boundary that only approved, signed AI artifacts can run.

    Threats mitigated

    Supply Chain CompromiseData and Model PoisoningInsider Misuse

    Protects

    ModelsInfrastructureRuntime

    MITRE: ATLAS AML.T0010 · ATLAS AML.T0058 · ATLAS AML.T0076 · ATT&CK T1195 · ATT&CK T1195.002

    Provenance checks and scanning only reduce risk if the deploy path actually refuses artifacts that fail them. Admission enforcement is what makes the preceding supply-chain controls non-optional rather than advisory.

    Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.

Evidence required

  • Artifact signing/verification configuration
  • MCP and tool inventory with review records
  • Image/model scan reports for production releases
More detailPhilosophy, failures, practices, validations, examples, crosswalks, and evolution

Engineering philosophy

An AI system is only as trustworthy as the artifacts it loads. Unsigned weights, unverified MCP hosts, and opaque tool catalogs are supply-chain defects, not product features.

Why it matters

Poisoned models, compromised MCP servers, and tampered tool plugins bypass application-layer controls and can exfiltrate data or execute attacker-chosen actions at scale.

Common failures

  • Downloading open-weight models from unverified mirrors without checksum or signature verification
  • MCP servers installed without source review or pinned versions
  • No SBOM/MBOM for inference images and agent runtimes
  • Fine-tuned adapters pulled from untrusted registries into production

Severity & risk

Severity
critical
Impact if violated
Risk level
high
Typical residual risk (impact × likelihood)

Engineering best practices

  • Prefer private registries for production models and adapters
  • Treat MCP hosts as supply-chain surfaces equal to npm/PyPI packages
  • Separate build and serving identities; never use developer credentials in prod pulls
  • Record provenance in release evidence packs

Automatic validations

  • CI verification of artifact digests against expected values
  • Admission controller or gateway denials for unsigned artifacts
  • SBOM generation and CVE gates on AI images

Manual validations

  • Source review for new MCP servers and tool plugins
  • Periodic audit of model download sources

Examples

  • Inference pods only pull images signed by the org signing key
  • An MCP catalog requires peer review and a pinned commit before agents can call it

References

Crosswalks

Show 15 peer mappingsexpand
  • Secure & Resilient Secure and Resilient

    NIST AI Risk Management Framework · aligns-with

  • Annex A AI system controls (selected themes)

    ISO/IEC 42001 · partial

  • LLM03 Supply Chain

    OWASP Top 10 for Large Language Model Applications · supports

  • C3.1 Model Authorization & Integrity

    OWASP AI Application Security Verification Standard (AISVS) · supports

  • C6.1 Model Artifact Integrity

    OWASP AI Application Security Verification Standard (AISVS) · supports

  • C6.2 AI BOM & Supply Chain Monitoring

    OWASP AI Application Security Verification Standard (AISVS) · supports

  • L1 Foundation Models

    CSA MAESTRO (Multi-Agentic Threat Model) · supports

  • L4 Deployment & Infrastructure

    CSA MAESTRO (Multi-Agentic Threat Model) · supports

  • CC9 Risk Mitigation

    SOC 2 Trust Services Criteria · evidence-for

  • Security Security

    AWS Well-Architected Framework · aligns-with

  • Level 1 Build process documented

    SLSA (Supply-chain Levels for Software Artifacts) · partial

  • Level 2 Hosted build + signed provenance

    SLSA (Supply-chain Levels for Software Artifacts) · aligns-with

  • Level 3 Hardened builds

    SLSA (Supply-chain Levels for Software Artifacts) · partial

  • Provenance Artifact provenance

    SLSA (Supply-chain Levels for Software Artifacts) · supports

  • Verify-on-deploy Verification before use

    SLSA (Supply-chain Levels for Software Artifacts) · supports

Future evolution

Portable MBOM formats and cross-vendor attestation for hosted and self-hosted models.