The Model Has a Supply Chain Too: Securing AI Models Before They Reach Production

Introduction

Most enterprises would never allow an engineer to download an unknown executable from the internet and place it directly on a production server. Mature software delivery processes use source control, artifact repositories, vulnerability scanning, build records, approvals, version pinning, and rollback procedures because software has a supply chain.

AI models have one too.

A downloaded model may include tensor weights, configuration files, tokenizer assets, custom Python code, native extensions, adapters, framework-specific checkpoints, license files, model cards, and scripts that execute during loading. The serving container adds another supply chain containing operating-system packages, Python libraries, CUDA components, inference runtimes, and web-service dependencies. The model may also inherit restrictions or risks from its training data, base model, fine-tuning process, or publisher.

That means downloading a model directly into production is not simply a technical shortcut. It bypasses security review, legal review, provenance validation, compatibility testing, model evaluation, and change control at the same time.

NIST’s AI Risk Management Framework emphasizes that organizations need governance, mapping, measurement, and management processes for AI risk, including third-party systems. NIST’s AI-specific Secure Software Development Framework profile extends secure development practices to AI model producers, AI system producers, and acquirers [2], [4]. The practical implication is straightforward: model intake belongs inside the enterprise supply-chain control plane, not inside an individual data scientist’s home directory.

TL;DR

An enterprise AI model should not reach production because someone found it in a trusted-looking registry, downloaded it successfully, or proved that it can run on a GPU. A production model release needs a controlled intake process that verifies source and publisher identity, preserves license terms, records immutable hashes, detects unsafe serialization, scans the serving stack, validates runtime compatibility, measures quality and safety, and produces an auditable approval record.

The minimum governed release identity is not just a model name. It is the combination of an approved container digest, an approved model artifact or manifest digest, and an approved runtime configuration. NVIDIA NGC, NVIDIA NIM, Harbor, object storage, and internal model registries can support this pattern, but none of them replaces the enterprise decision to approve a specific model for a specific use case.

A private AI platform is not truly private or governed if it cannot control what models enter the environment.

An AI Model Is More Than a Weight File

The phrase “the model” is often used as if it identifies one file and one risk. In production, it usually identifies a bundle of related artifacts and assumptions.

This is why model approval cannot be reduced to a single green check mark. The enterprise needs to know exactly which artifacts were reviewed, how they were combined, and which production use was approved.

A useful release identity is:

Approved AI Release
      = Container Digest
      + Model Artifact or Manifest Digest
      + Runtime Configuration Digest
      + Approval and Evaluation Evidence

Changing any one of those elements creates a new release candidate. A new container with the same model is not the same release. A new model revision inside the same container is not the same release. A different quantization profile, tokenizer, adapter, or serving configuration may also change quality, safety, compatibility, and performance enough to require reevaluation.

Build a Quarantine Boundary Before You Build an Approval Workflow

The first architectural control is separation. Newly acquired models should enter a quarantine environment that production workloads cannot consume directly.

The quarantine boundary can be implemented as a dedicated Harbor project, separate registry, isolated object-storage bucket, restricted model repository, or a combination of these. The exact product matters less than the permissions and trust boundary.

A quarantine service account may ingest artifacts. Security scanners and test pipelines may read them. Reviewers may attach evidence. Production service accounts should not be able to pull from quarantine, and quarantine jobs should not have production credentials.

The reference workflow is:

The workflow is intentionally sequential, but some gates can run in parallel. Security scanning, license review, and initial compatibility analysis can start at the same time. Promotion should occur only after all required gates have produced a pass or an explicitly approved exception.

Required Control Versus Maturity Improvement

This article distinguishes two control levels:

• Required control: A baseline gate that should exist before a model is eligible for production.
• Maturity improvement: An additional control that improves scalability, evidence quality, or defense in depth. A regulated environment or high-impact use case may elevate some maturity improvements into mandatory controls.

The distinction matters because a supply chain that exists only on paper will fail. Enterprises should first establish enforceable minimum gates, then automate and deepen them.

Establish Provenance Before You Evaluate the Model

A model cannot be meaningfully approved until the organization can identify what it received and who supplied it.

Record the Source Class

Every intake record should identify one of these source classes:

• External model registry: An established catalog such as NVIDIA NGC or another approved distribution service.
• Model publisher: A vendor, research organization, or open-source project distributing artifacts directly.
• Internal model producer: A data science, research, or application team that trained, fine-tuned, merged, quantized, or converted the model.
• Derived artifact: An adapter, fine-tune, conversion, quantization, or merged model built from one or more upstream artifacts.

The source class changes the evidence required. An external publisher needs publisher verification and acquisition evidence. An internal producer needs training, transformation, code, and data-lineage records. A derived artifact needs a complete parent chain.

Capture an Immutable Intake Record

At minimum, the intake record should contain:

• model name and declared version
• publisher or producing team
• source registry or distribution channel
• upstream revision, release identifier, or commit when available
• acquisition date and acquiring service identity
• complete file inventory
• cryptographic hash for every file
• aggregate manifest digest
• original license and acceptable-use documents
• model card and technical documentation
• known base models, adapters, conversions, and parent artifacts
• declared framework and format
• intended use and known limitations
• intake owner and business sponsor

Required control: Production approval must not depend on a mutable label such as latest, a model display name, or a registry page that can change after acquisition.

Maturity improvement: Generate a machine-readable AI or machine-learning bill of materials. CycloneDX’s ML-BOM capability is designed to represent models, datasets, training methods, frameworks, configurations, provenance, and related risk information [15].

Verify the Publisher Without Assuming the Registry Guarantees the Model

A reputable registry reduces some acquisition risk, but registry presence is not enterprise approval. Verify that the artifact belongs to the expected publisher or organization, that the publisher account is authentic, and that the release is consistent with the publisher’s documented distribution process.

For high-risk models, publisher verification should include an approved vendor record, contract or subscription entitlement where applicable, known signing identity, support status, and a named escalation path.

If the enterprise cannot establish who produced the model, how it was obtained, or which revision was acquired, the model should remain quarantined.

Complete License and Acceptable-Use Review Before Technical Promotion

A technically functional model may still be unusable by the enterprise.

Model licenses vary widely. Some permit commercial use and modification. Others restrict certain use cases, distribution, hosted access, derivative works, geographic use, or the number and type of users. An acceptable-use policy may impose additional restrictions beyond the copyright license. Adapters and fine-tunes may carry obligations from both the base model and the derived artifact.

The review should answer:

Required control: No model should reach production when no license can be identified, when applicable terms are missing, or when the intended use conflicts with documented restrictions.

Required control: Preserve the exact license and acceptable-use terms that were reviewed. A reference to a current web page is not sufficient audit evidence because terms can change.

Maturity improvement: Normalize license identifiers, policy conditions, and obligations into machine-readable metadata that can be evaluated automatically during intake and deployment.

Legal review is not a checkbox that a scanner can replace. Automated license detection may help locate terms, but counsel or an authorized legal reviewer must resolve ambiguity for the intended business use.

Use Hashes, Signatures, and Immutable Digests Correctly

Integrity controls answer different questions, and confusing them creates false confidence.

• A hash shows whether the bytes changed after the hash was recorded.
• A digital signature connects an artifact or manifest to a signing identity and protects integrity.
• An immutable digest provides a stable deployment reference.
• An approval attestation records that enterprise gates approved a specific artifact for a specific purpose.

A hash does not prove that the artifact was safe when first acquired. A signature does not prove that the model is high quality, legally usable, or compatible. It proves only that the artifact was signed by a key accepted under the trust policy and has not changed since signing.

Recommended Integrity Pattern

The intake pipeline should hash every file before any conversion, extraction, or loading. It should create a signed manifest containing the file inventory, upstream identity, acquisition metadata, and aggregate digest. Original artifacts should remain preserved in quarantine even when the enterprise creates a safer converted copy.

When an upstream publisher provides a signature, verify it against the publisher’s approved trust identity. When the upstream artifact is unsigned, the enterprise can sign its own approval manifest after all gates pass. That enterprise signature means “approved by our process,” not “authored by us.”

Harbor supports signed OCI artifacts through Cosign and Notation, can associate signatures with artifacts, and can enforce content trust for pulls. Harbor also supports tag immutability, while its documentation explicitly notes that the digest remains the reliable reference when tags can move [10], [12].

Required control: Deploy by immutable digest or a version that resolves to an immutable digest under enforced registry policy.

Maturity improvement: Use keyless or hardware-backed signing, centralized trust policies, signed attestations for each approval gate, and transparency logging appropriate to the organization’s threat model.

Treat Model Loading as Potential Code Execution

One of the most dangerous assumptions in model operations is that a model file is passive data.

Some serialization formats can invoke object reconstruction logic during loading. PyTorch’s current torch.load interface includes a weights_only control that restricts what the unpickler can load. Hugging Face’s security guidance warns that malicious pickle content can lead to arbitrary code execution and recommends trusted sources, signed commits, safer formats, and scanning [8], [9].

Required Safe-Loading Controls

Before any model is loaded:

• inspect the file inventory and archive structure without executing the artifact
• reject unexpected executables, native libraries, scripts, symbolic links, and path traversal entries
• identify checkpoint formats that rely on pickle or custom object deserialization
• prefer formats designed to store tensors without arbitrary object execution when the framework supports them
• disable automatic retrieval of remote code or dependencies
• prohibit fallback to unrestricted deserialization for untrusted artifacts
• run required conversion in an ephemeral sandbox with no production credentials
• deny outbound network access during analysis and conversion unless a specific dependency is approved
• mount the original artifact read-only
• run as a nonprivileged identity with restricted filesystem, process, and device access
• retain logs, hashes, extracted metadata, and the converted-artifact digest

A safer serialization format reduces one attack path. It does not prove that the weights are benign, the model behavior is acceptable, or the surrounding files are safe.

When Custom Code Is Unavoidable

Some architectures require custom loader code or framework extensions. That should trigger a higher-assurance path:

• retrieve the code as a separate source artifact
• perform source and dependency review
• build it through the approved software pipeline
• generate an SBOM
• scan the resulting container or package
• sign the build output
• execute it only inside the approved serving image

The model approval should then reference both the model digest and the reviewed code digest. “Trust remote code” is not an enterprise control.

Scan the Serving Container and the Model as Separate Artifacts

Container vulnerability scanning and model security analysis solve different problems.

A container scanner can identify known vulnerabilities in operating-system packages, Python packages, libraries, and some configuration metadata. Harbor can scan artifacts on push and can prevent pulls based on configured vulnerability severity thresholds [11]. It can also integrate with additional vulnerability scanners [16].

That does not mean the model weights were scanned. Opaque tensor data does not have a mature CVE model equivalent to operating-system packages. Model-focused analysis must inspect serialization risk, unexpected files, malware indicators, embedded code, provenance, documentation, and behavior.

Separate Approval Records

Required control: A green container scan must never be treated as model approval.

Required control: A model evaluation pass must never waive container vulnerabilities or unsupported dependencies.

Maturity improvement: Link the container SBOM, ML-BOM, signatures, evaluation report, and runtime configuration through one release record so that an incident can identify every affected deployment.

Validate Compatibility Against the Exact Production Stack

A model that loads in a notebook is not necessarily deployable in the enterprise serving environment.

Compatibility testing should use the exact or representative combination of:

• GPU architecture and available GPU memory
• GPU count and topology
• NVIDIA driver branch
• CUDA and related libraries
• framework version
• inference engine and serving runtime
• model format and precision
• quantization method
• tensor or pipeline parallel configuration
• tokenizer and adapter versions
• operating system and container runtime
• orchestration platform and storage path

NVIDIA NGC and NIM in the Intake Process

NVIDIA NGC can distribute containers and artifacts through API-key-controlled services [14]. NGC is a valid acquisition source, but the enterprise should still capture the exact artifact identity, entitlement, terms, and downstream approval evidence.

Current NVIDIA NIM for large language model documentation describes manifest-driven model downloads, checksum verification, profile downloads, local model stores, and mirroring to supported object storage [13]. These capabilities support a governed supply chain because the enterprise can preload, verify, mirror, and serve approved model artifacts without allowing every production workload to fetch directly from an external source.

The important distinction is:

• the NIM container is the serving software artifact
• the model profile and model artifacts are the model release inputs
• the runtime configuration selects how they run on specific hardware

All three must be pinned and tested together.

Compatibility Gate

A production compatibility report should include:

• tested container digest
• tested model or manifest digest
• NIM model profile or equivalent runtime profile
• tested GPU model and count
• tested driver, CUDA, framework, and runtime versions
• required memory and storage
• cold-start time
• steady-state GPU memory use
• health-check behavior
• request and response compatibility
• known warnings and unsupported features
• expected failure behavior when dependencies are absent

Required control: A model release must pass on production-representative hardware and software. A documentation claim alone is not operational evidence.

Maturity improvement: Maintain an automated compatibility matrix and rerun affected tests whenever the driver, CUDA stack, serving runtime, model profile, or orchestration platform changes.

Put Quality, Safety, Bias, and Performance Behind Explicit Gates

Security and license approval do not prove that a model is suitable for the business use.

NIST’s AI RMF Playbook recommends selecting metrics based on purpose and risk, defining acceptable limits, testing whether the system is fit for purpose, documenting unmeasured risks, monitoring external inputs, and comparing predeployment with postdeployment performance [6]. That is a better enterprise pattern than relying on a public benchmark or publisher claim.

Quality Gate

The quality gate should use a representative evaluation set tied to the actual task. For a retrieval-augmented generation system, this may include answer correctness, groundedness, citation fidelity, refusal behavior, and handling of missing evidence. For classification, it may include precision, recall, false-positive cost, calibration, and subgroup performance.

Safety and Security Gate

The safety gate should test behaviors relevant to the application, including harmful output, prohibited advice, sensitive-data leakage, jailbreak resistance, prompt-manipulation behavior, unsafe tool recommendations, and refusal consistency. The model test does not replace application controls, identity boundaries, retrieval authorization, content filtering, or human approval.

Bias and Impact Gate

Bias testing should use relevant populations, languages, content domains, and failure consequences. Aggregate accuracy can hide material differences. The evaluation record should identify which groups or scenarios were tested, which were not, and what risk remains.

Performance Gate

The performance gate should measure more than tokens per second. It should include:

• cold-start and model-load time
• p50, p95, and p99 latency where applicable
• throughput at target concurrency
• GPU memory consumption
• CPU and system-memory use
• storage read behavior during startup
• failure and recovery behavior under load
• cost or capacity per useful request
• quality degradation caused by quantization or optimization

Required control: Define pass criteria before the final evaluation run. Moving thresholds after results are known turns a gate into a justification exercise.

Required control: Evaluate the combined model and application path for the intended use, not just the base model in isolation.

Maturity improvement: Add adversarial testing, external red-team review, canary deployments, shadow evaluation, continuous regression testing, and postdeployment drift detection.

Promote by Digest, Not by Redownloading or Retagging

Promotion should copy the exact approved bytes from quarantine to the approved internal location. The pipeline should not redownload the model from the external source after review, because the upstream artifact may have changed while retaining the same display name or tag.

The approved location may be:

• a Harbor project containing container images and OCI-packaged model artifacts
• an internal NGC private registry where appropriate
• an immutable object-storage bucket for model manifests and large weight files
• a dedicated model registry with versioned artifacts
• a NIM-compatible local model store or mirrored object store

Harbor does not have to hold every model byte to remain part of the control plane. Large model artifacts may be operationally better suited to object storage or a dedicated model store. The approval registry can still hold the immutable release record, signatures, attestations, and pointers to versioned objects.

Example Approved Model Release Record

The following illustrative YAML shows the fields a policy engine or deployment pipeline could require. It is not a vendor-defined schema. Replace names, versions, policy references, and internal locations with values from your environment.

apiVersion: governance.dtd.internal/v1alpha1
kind: ApprovedModelRelease
metadata:
  name: customer-service-llm-2026-07
spec:
  model:
    publisher: approved-publisher
    upstreamRevision: release-2026-07-15
    artifactDigest: sha256:MODEL_MANIFEST_DIGEST
    format: safetensors
    approvedLocation: models-approved/customer-service/2026-07
  container:
    image: harbor.example.internal/ai-approved/nim-llm@sha256:IMAGE_DIGEST
    sbomDigest: sha256:SBOM_DIGEST
  runtime:
    servingRuntime: nvidia-nim-llm
    modelProfile: PROFILE_IDENTIFIER
    gpuClass: approved-gpu-pool-a
    configurationDigest: sha256:RUNTIME_CONFIG_DIGEST
  approvals:
    securityReview: SEC-2481
    legalReview: LEG-773
    modelRiskReview: AIR-902
    evaluationReportDigest: sha256:EVALUATION_DIGEST
  policy:
    allowedNamespaces:
      - customer-service-prod
    allowedUseCases:
      - internal-customer-support-assistance
    productionApprovalExpires: 2027-01-31
    revoked: false

The model location should be read-only to production. The serving image should be referenced by digest. The evaluation report should be immutable. The expiration date forces review when the model, terms, or operating context may have changed.

A successful policy check should verify that every digest in the deployment request matches the approved record. A failed check should prevent deployment rather than merely generate an alert.

Enforce Controlled Deployment at the Platform Boundary

Governance is not complete when a review board approves a spreadsheet row. The platform must enforce the decision.

For Kubernetes or another orchestrated platform, deployment controls should verify:

• the container is pulled from an approved registry and pinned by digest
• the model is mounted or retrieved only from an approved immutable location
• the release record is active and not expired
• the target namespace, project, tenant, or environment is authorized
• the runtime profile matches approved hardware and software
• required signatures and attestations are valid
• external model-registry egress is denied for production workloads
• the workload identity has read-only access to the approved model
• telemetry records the model, container, configuration, tenant, and deployment identity

The platform should record the effective release identity at runtime. Otherwise, the registry may know what was approved while operations cannot prove what is actually serving requests.

Why Container and Model Approval Must Remain Separate

A combined release record lets operations deploy safely. Separate component approvals let the enterprise respond precisely when one layer changes.

Design Revocation Before the First Production Promotion

Every supply chain eventually needs to stop something that was previously trusted.

Revocation may be triggered by:

• publisher compromise or withdrawn release
• discovered malicious serialization or embedded code
• incorrect provenance
• license or acceptable-use conflict
• critical container vulnerability
• unsafe or biased behavior found after deployment
• compatibility defect
• corrupted internal artifact
• expired approval or unsupported runtime
• regulatory, contractual, or business-policy change

Emergency Blocking Controls

A mature emergency process should be able to:

• mark a model, container, or combined release as revoked by digest
• prevent new deployments through admission or release policy
• prevent new pulls from the approved registry where supported
• identify all running workloads using the revoked release
• stop, drain, or redeploy affected workloads
• roll back to a previously approved release
• preserve the revoked artifact and evidence for investigation or legal hold
• notify owners, security, legal, platform operations, and affected application teams
• record who authorized the revocation and why

Blocking registry pulls is not enough. Nodes may already have image layers cached, and running workloads may continue serving the model. Admission policy stops new workloads; runtime inventory and incident automation are needed to address existing ones.

Rollback Must Restore a Known Approved Pair

Rollback should identify the previous approved combination of container, model, and configuration. Rolling back a container tag while leaving a newer model mounted can create an untested combination. Restoring “the last image” is not the same as restoring the last approved AI release.

Required control: Maintain at least one previous compatible, approved release for critical services.

Maturity improvement: Exercise revocation and rollback as a scheduled control test, including cached artifacts, disconnected sites, and partial platform outages.

Preserve Audit Evidence for Regulated and High-Risk Environments

Regulated environments need more than evidence that a pipeline ran. They need evidence that supports the decision and can be reconstructed later.

Retention must align with legal, regulatory, contractual, security, and records-management requirements. Some revoked artifacts should be blocked from use but preserved for investigation. Immediate deletion can destroy evidence.

An audit package does not create compliance by itself. It gives auditors and risk owners the evidence needed to evaluate whether the enterprise followed its defined controls.

Define Clear Ownership Across the Model Supply Chain

The model-intake process crosses teams that often use different risk languages. Security focuses on code execution and integrity. Legal focuses on rights and obligations. Platform teams focus on compatibility and operations. Data science focuses on model quality. Application owners focus on outcomes.

The process needs explicit ownership.

The same person may perform several roles in a smaller organization, but the decisions should remain distinct. The engineer who wants the model in production should not be the only person deciding that its license, security, and safety are acceptable.

A Practical Minimum Viable Model Supply Chain

Organizations do not need to build a perfect AI governance platform before they can improve control. They do need an enforceable path that replaces unmanaged downloads.

Start with these required controls:

• designate one quarantine location for all new models
• prohibit production workloads from pulling directly from external model registries
• capture publisher, source revision, license, file inventory, and hashes
• scan the serving container and supporting libraries
• detect unsafe serialization and sandbox required loading or conversion
• test the exact model and container combination on representative GPU infrastructure
• define quality, safety, bias, and performance thresholds
• approve and promote exact bytes by digest
• deploy only from approved internal locations
• record container, model, configuration, and approval identities at runtime
• maintain a digest-based denylist and rollback release
• retain evidence for audit and incident response

Then add maturity improvements:

• signed attestations for every gate
• ML-BOM and linked SBOM records
• automated publisher allowlists and policy-as-code
• isolated analysis clusters for untrusted models
• continuous evaluation and drift detection
• canary and shadow deployment patterns
• cross-registry replication of signatures and approval metadata
• automated blast-radius analysis for revocation
• scheduled rollback and emergency-blocking exercises

The objective is not to make model acquisition slow. It is to make trust explicit, repeatable, and enforceable.

Common Failure Patterns to Avoid

Trusting a Popular Registry as the Final Approval Boundary

A registry can provide distribution, identity, documentation, and access control. It cannot know whether the model is legal for your exact use, safe for your application, compatible with your platform, or acceptable under your risk tolerance.

Approving a Model Name Instead of an Artifact

Names and tags are human-friendly, but they can move. Approval must resolve to immutable artifact and configuration identities.

Scanning Only the Container

The container scan does not analyze opaque weights, license rights, model behavior, or unsafe model-loading paths.

Evaluating Only the Base Model

Adapters, prompts, retrieval systems, tool permissions, safety filters, and serving configurations change behavior. Production approval must evaluate the deployed system path.

Converting an Unsafe Artifact and Deleting the Original

Conversion may create a safer serving format, but deleting the original destroys chain-of-custody evidence and makes later investigation difficult.

Using Approval as a Permanent Status

Model approval should expire or be reevaluated when artifacts, runtime dependencies, business use, license terms, threat intelligence, or measured behavior changes.

Relying on Registry Blocking Alone for Revocation

Cached artifacts and running workloads can survive a pull block. Revocation needs deployment inventory and runtime response.

Conclusion

AI models should move through the enterprise the same way other high-impact artifacts do: through controlled intake, evidence collection, independent review, immutable promotion, enforced deployment, monitoring, and revocation.

The core architectural decision is to create a quarantine boundary and make the approved release identity explicit. A production deployment should reference an approved container digest, an approved model or manifest digest, an approved runtime configuration, and the evidence that supports the decision. Container approval and model approval remain separate because their risks and change cycles are different, but they come together in one governed release record.

NVIDIA NGC and NVIDIA NIM can participate in this supply chain. Harbor can provide registry separation, scanning, signatures, immutability, and pull controls. Object storage and model stores can hold large approved artifacts. NIST guidance can shape governance, evaluation, third-party risk, and secure development. None of these components removes the need for an enterprise intake and promotion process.

The practical standard is simple: no model should enter production unless the organization can prove where it came from, what terms govern it, what exact bytes were tested, how it was loaded, which runtime supports it, what evaluation it passed, who approved it, where it is running, and how it will be revoked.

A private AI platform is not truly private or governed if it cannot control what models enter the environment.

External References

• [1] NVIDIA: NGC Catalog
  Canonical URL: https://catalog.ngc.nvidia.com/
• [2] National Institute of Standards and Technology: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
  Canonical URL: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10
• [3] National Institute of Standards and Technology: Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities
  Canonical URL: https://csrc.nist.gov/pubs/sp/800/218/final
• [4] National Institute of Standards and Technology: Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile
  Canonical URL: https://csrc.nist.gov/pubs/sp/800/218/a/final
• [5] National Institute of Standards and Technology: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
  Canonical URL: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
• [6] NIST AI Resource Center: AI RMF Playbook, Measure
  Canonical URL: https://airc.nist.gov/airmf-resources/playbook/measure/
• [7] UK National Cyber Security Centre: Secure Your Supply Chain
  Canonical URL: https://www.ncsc.gov.uk/collection/machine-learning-principles/secure-development/secure-supply-chain
• [8] PyTorch: torch.load
  Canonical URL: https://docs.pytorch.org/docs/stable/generated/torch.load.html
• [9] Hugging Face: Pickle Scanning
  Canonical URL: https://huggingface.co/docs/hub/security-pickle
• [10] Harbor: Sign Artifacts with Cosign or Notation
  Canonical URL: https://goharbor.io/docs/main/working-with-projects/working-with-images/sign-images/
• [11] Harbor: Project Configuration
  Canonical URL: https://goharbor.io/docs/main/working-with-projects/project-configuration/
• [12] Harbor: Tag Immutability Rules
  Canonical URL: https://goharbor.io/docs/main/working-with-projects/working-with-images/create-tag-immutability-rules/
• [13] NVIDIA: Model Download
  Canonical URL: https://docs.nvidia.com/nim/large-language-models/latest/deployment/model-download.html
• [14] NVIDIA: NGC User Guide
  Canonical URL: https://docs.nvidia.com/ngc/latest/ngc-user-guide.html
• [15] OWASP CycloneDX: Machine Learning Bill of Materials (AI/ML-BOM)
  Canonical URL: https://cyclonedx.org/capabilities/mlbom/
• [16] Harbor: Connect Harbor to Additional Vulnerability Scanners
  Canonical URL: https://goharbor.io/docs/main/administration/vulnerability-scanning/pluggable-scanners/

The post The Model Has a Supply Chain Too: Securing AI Models Before They Reach Production appeared first on Digital Thought Disruption.