Supply Chain Security: Why Pinning Versions and Running Your Own Mirror Registry Matters

Module 1 of 20 · Agentic AI Security Curriculum · May 2026

How to use this module

Use it as self-paced study or as instructor-led training. YAML, commands, and policy excerpts are illustrative; map them to your cloud, mesh, identity provider, and agent runtime—substitute your own names, namespaces, and tools while preserving the control intent.

Estimated time: ~35 minutes reading; add time for linked standards and team discussion.

Learning objectives

By the end of this module, you should be able to:

Explain why the software supply chain is a primary risk for agentic AI and tool-calling platforms.
Contrast unsafe practices (public registries, floating tags, loose semver) with production-grade alternatives.
Describe digest pinning, private mirrors, SBOM storage, and container signing in CI/CD.
List secret-scanning practices that reduce credential leakage into repositories.

Prerequisites

None (this is the first module).

Suggested discussion / lab: Pick one diagram in your environment (build, deploy, runtime) and mark where this module’s controls apply; note gaps versus the checklist in the body.

The software supply chain is the single largest and most dangerous attack surface in any production-grade agentic AI and MCP platform. A single compromised dependency, container image, or model weight can give an attacker persistent access to your cluster, your documents, your Memory 2.0 knowledge graph, and your users’ sensitive data.

This module explains why relying on public registries without controls is unacceptable for production deployments that include LLM agents, tools, and sensitive data and shows exactly how to build a secure, mirrored, and verifiable supply chain using Harbor, Cosign, Trivy, Syft, and strict pinning.

The Supply Chain Threat Landscape

Supply-chain attacks have become sophisticated and frequent:Dependency confusion attacks, where attackers publish malicious packages with the same name as your internal ones. Typosquatting and name collisions with popular packages. Compromised official base images on Docker Hub or GitHub Container Registry. Model weight poisoning through malicious Ollama or Hugging Face models containing hidden triggers. Living-off-the-land persistence once inside a container.

In an MCP-based or tool-calling agentic system, the impact is amplified. A compromised tool can execute arbitrary code in the sandbox, access the full document pipeline (Tika → Presidio → Paperless), or exfiltrate data through the intelligent gateway.

Core conclusion: You cannot outsource trust to the public internet. You must control every artifact from source to running pod.

Harbor as the Single Trust Root

A common enterprise pattern is to designate a private registry (for example Harbor, ECR with pull-through cache, or ACR) as the single source of truth for all artifacts: container images, Helm charts, model weight manifests, SBOMs, and Cosign signatures.

Harbor provides a private registry with replication, pull-through caching, built-in vulnerability scanning, and native support for SBOM storage. All production workloads should be configured to pull exclusively from that internal registry.

Key Harbor configuration principles:

Allowlist-only resolution enabled. Replication rules to mirror only approved upstream artifacts. All images and manifests must be signed before being accepted.

Allowlist-Only Resolution and Version Pinning

This is the foundational control.Never do this in production:Pulling directly from Docker Hub, npm, PyPI, or GitHub. Using floating tags such as :latest or :main. Allowing version ranges like ^1.2.0.

Always do this:Use exact digest pinning (e.g., nginx@sha256:abc123…). Or use a pinned version combined with mandatory Cosign signature verification.

Helm umbrella charts, GitOps, or an in-cluster operator often enforce equivalent rules through configuration flags such as:

security:
  supplyChain:
    registryMirror: 'registry.internal.example'
    allowlistOnly: true
    requireDigest: true
    requireCosign: true

Scanning, SBOM Generation, and Signing

Every artifact that enters Harbor must be scanned and accompanied by a Software Bill of Materials (SBOM).

Tools commonly used in hardened CI/CD pipelines:

Trivy: OS and language vulnerability scanning. OSV-Scanner: Ecosystem-specific vulnerability checks. Syft: SBOM generation (SPDX and CycloneDX formats). Cosign: Keyless signing via Sigstore (no long-lived keys to manage or steal).

Typical CI pipeline step:

trivy image --exit-code 1 --severity CRITICAL,HIGH $IMAGE:latest
syft packages $IMAGE:latest -o spdx-json > sbom.spdx.json
cosign sign --keyless $IMAGE@${DIGEST}

All SBOMs are stored alongside their images in Harbor for long-term forensic and compliance needs.

Credential Leak Prevention

Even the best registry is useless if secrets enter the repository.Strong pipelines often use a two-layer defense:Gitleaks as a mandatory pre-commit hook plus CI gate. TruffleHog for full historical repository scans on every push or pull request.

These tools block AWS keys, Vault tokens, database credentials, and other secrets before they ever reach the main branch.

Practical implementation checklist

Mirror only approved upstream artifacts into Harbor on a nightly schedule. Enforce allowlist-only resolution and digest pinning everywhere in Helm charts and the Operator. Require Cosign keyless signing on all images and manifests. Scan every build with Trivy + OSV-Scanner and block merges on critical findings. Store SBOMs with every release for full traceability months later.

Automate as many of these controls as possible in your charts, operators, or policy-as-code repos.

Key Takeaways

Public registries represent an unacceptable risk for production agentic platforms. A private mirror registry (Harbor) with allowlist-only resolution is the foundation of all other security layers. Strict pinning, SBOMs, and Cosign signing turn every artifact into a verifiable, tamper-evident unit. Credential scanning prevents the most common initial compromise vector.

This supply chain foundation is the prerequisite for every subsequent module in this curriculum.

Next module: Building Golden Images – Automated Scanning, Hardening, and Distroless Pipelines.

Commercial training use

You may reuse this curriculum internally or in paid consulting / training engagements. Keep examples aligned to the customer’s actual stack; substitute your own runbooks, tool names, and compliance frameworks (SOC 2, ISO 27001, sector regulators) where cited examples use a reference architecture only.