The role of the Information Security Engineer has shifted fundamentally over the last two years. We are no longer just defending against external hackers trying to breach a perimeter. Instead, we are defending against the complexity of our own velocity. The modern DevOps pipeline is no longer a linear path from a developer’s laptop to a production server. It is a sprawling ecosystem of third party SaaS providers, integrated partner APIs and, most recently, autonomous AI agents capable of writing and committing code at a scale that exceeds human review capabilities.

This acceleration has created a massive gap in trust. When an AI agent suggests a dependency or a third party library is updated automatically, the risk of supply chain attacks increases exponentially. We are seeing a rise in dependency confusion and poisoned base images designed to target automated pipelines. In this environment, implicit trust is a vulnerability. To secure a production environment, we must move toward a zero trust model for artifacts. The only way to achieve this is through a signed development pipeline where the identity and integrity of every container image are cryptographically verified before execution.

The Exploding Risk Profile of AI Powered Supply Chains

The introduction of AI into the software development lifecycle (SDLC) introduces a paradoxical risk. While AI agents increase productivity, they often lack the security intuition of a senior engineer. An AI agent might pull a library that looks functional but contains a known vulnerability or, worse, a backdoor. If your pipeline automatically builds and deploys any image that passes a basic unit test, you have created a high speed highway for malicious activity to enter your production cluster.

Furthermore, the supply chain is only as strong as its weakest link. Most organizations rely on public registries like Docker Hub or GitHub. While these are convenient, they are outside your administrative control. A compromised public image can be injected into your environment unnoticed. This is why a protected promotion driven pipeline is not just a luxury but a requirement for any organization handling sensitive data. By implementing an internal-gated process, you ensure that no code reaches production without passing through a set of security checkpoints and receiving a digital seal of approval.

Designing the Protected Promotion Pipeline

The goal of a protected pipeline is to isolate the environment where images are built from the environment where images are run. This is achieved through a promotion model. Instead of pushing one image to a single registry, we utilize separate stages: a development register for experimentation and a protected production registry for deployment.

In this architecture, an image is born in the development registry. It undergoes static analysis, vulnerability scanning and QA testing. Once it satisfies all security policies and operational checks, it is signed by a trusted internal authority using a developers private key. Only after the signature is attached is the image promoted to the protected production registry. The production Kubernetes cluster is then configured to reject any image that lacks this specific cryptographic signature.

Architecture Diagram: Promotion Driven Pipeline

Below is the logical flow of the secure promotion process.

The Security Stack: Harbor, Cosign, and Kyverno

To build this system, we integrate three industry standard tools that work in tandem to create a closed loop of trust.

Harbor: The Secure Fortress

Harbor is more than just a registry. It acts as the central source of truth for your artifacts. Unlike simple registries, Harbor provides built-in vulnerability scanning via  Trivy or Clair and allows for project level isolation. By setting up separate projects for Dev and Prod, you can apply strict Role Based Access Control (RBAC), ensuring that only a dedicated CI/CD service account can verify & push images to the production project.

Cosign: The Cryptographic Seal

Cosign, part of the Sigstore project, is the tool used to sign and verify container images. Instead of relying on complex GPG keys, Cosign simplifies the process by storing signatures directly in the registry alongside the image. This means the signature travels with the artifact. When an image is signed, it creates a mathematical proof that the image was indeed produced by your trusted pipeline and has not been altered since the sign off.

Kyverno: The Gatekeeper

The final layer of defense is Kyverno. While Harbor stores the signature and Cosign creates it, Kyverno enforces the policy within Kubernetes. As a mutating and validating admission controller, Kyverno intercepts every request to create a pod. It checks the image against a public key. If the image in the request does not have a valid signature from your internal authority, Kyverno blocks the deployment entirely, returning an error. This prevents “shadow IT” or manual overrides from bypassing your security pipeline.

Implementation Guide: Setting Up the Infrastructure

Setting up this ecosystem requires a coordinated effort across your infrastructure and CI/CD teams. Follow these high level steps to establish the baseline.

First, deploy Harbor, or another artifact registry that supports cosign, in your environment. Ensure you enable the vulnerability scanning feature and create at least two separate projects: one for development (dev-repo) and one for production (prod-repo). Configure the prod-repo to be read only for the Kubernetes cluster and only grant write to your signing service account.

Second, generate your Cosign key pair. The private key must be stored in a secure vault such as Secrets Manager, HashiCorp Vault, or GitHub Actions Secrets. Never store this key within the image or in plain text. The public key will be needed by Kyverno to verify the signatures.

Third, install Kyverno into your Kubernetes cluster using Helm. Once installed, you must create a ClusterPolicy that specifies which images must be signed and which public key should be used for verification. This policy effectively locks the door to your cluster.

Automated Workflow: GitHub Actions Example

To make this process seamless, it must be automated. Below is an example of a GitHub Action workflow that builds an image, pushes it to Harbor, signs it with Cosign, and promotes it to the protected registry.

name: Secure Build and Promote

on:
  push:
    branches: [ main ]

jobs:
  build-and-sign:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Login to Harbor
        uses: harbor/setup-action@v1 # Hypothetical wrapper for docker login
        with:
          registry: harbor.internal.company.com
          username: ${{ secrets.HARBOR_USER }}
          password: ${{ secrets.HARBOR_PASSWORD }}

      - name: Build and Push to Dev
        run: |
          docker build -t harbor.internal.company.com/dev-repo/app:${{ github.sha }} .
          docker push harbor.internal.company.com/dev-repo/app:${{ github.sha }}

      - name: Install Cosign
        uses: sigstore/cosign-installer@main

      - name: Sign Image
        run: |
          cosign sign --key ${{ secrets.COSIGN_PRIVATE_KEY }} harbor.internal.company.com/dev-repo/app:${{ github.sha }}

      - name: Promote to Production Registry
        run: |
          # This step pulls from dev and pushes to protected prod registry
          docker pull harbor.internal.company.com/dev-repo/app:${{ github.sha }}
          docker tag harbor.internal.company.com/dev-repo/app:${{ github.sha }} harbor.internal.company.com/prod-repo/app:${{ github.sha }}
          docker push harbor.internal.company.com/prod-repo/app:${{ github.sha }}
          
      - name: Sign Production Image
        run: |
          cosign sign --key ${{ secrets.COSIGN_PRIVATE_KEY }} harbor.internal.company.com/prod-repo/app:${{ github.sha }}

Final Thoughts on Pipeline Integrity

Moving to a signed, promotion driven pipeline is a significant shift, but it is the only way to mitigate the risks inherent in modern AI empowered development. By utilizing the CNCF landscape of tools like Harbor, Cosign and Kyverno, you transform your security posture from reactive to proactive.

You are no longer hoping that your images are safe because they passed a scan. Instead, you are knowing they are safe because they carry a cryptographic proof of origin and compliance. In an era where AI can generate code faster than we can audit it, the signature is the only source of truth that matters. For those looking to dive deeper into policy as code, I recommend exploring the Cloud Native Computing Foundation Introduction on Policy as Code. Additionally, consider further reducing the risk of artifact pollution by restricting access to the registry & CI/CD with certificate based device trust or a device access gateway.

Continued Learning and Certification

The Cloud Native foundation also has full training and certification coarse for Kyverno, known as the Kyverno Certified Associate (KCA); which is also part of Golden Kubestronaut program.