Software Supply Chain Security with OCI Artifact Digital Signatures and Kubernetes Runtime Validation

The Challenge of Trust in Container Artifacts

In modern software development, we routinely rely on dozens of container images pulled from public registries. In practice, this means we download third-party compiled code and run it directly on our production servers. The major risk in this convenience is that any attacker can inject malicious code into a popular library, altering the original image without the engineering team noticing immediately. Securing the software supply chain requires ensuring that every executed package is precisely the one generated by the original source code, with zero tampering along the way.

To solve this vulnerability, the industry adopted the OCI (Open Container Initiative) ecosystem, which standardized the format of container images and artifacts. However, merely standardizing packaging does not guarantee the authenticity of the content. This is where digital signatures come in, acting as an inviolable seal locked by asymmetric cryptography. When we sign an image, we generate a mathematical proof that the artifact belongs to a specific key, preventing silent tampering during transport or storage in remote repositories.

Implementing Cryptographic Signatures with Cosign

The Sigstore ecosystem offers modern and transparent tools to sign OCI artifacts, with Cosign standing out for its seamless integration into continuous integration workflows. In practice, the tool uses cryptographic key pairs to bind the container image manifest to an unforgeable digital signature. This process can be executed right after building the artifact, ensuring that no un audited code receives the engineering team's seal of approval before advancing to staging environments.

The signing process in an automated pipeline involves direct commands that record the author's identity in the ecosystem. Below is a practical example of how to sign an image stored in a remote registry using a locally generated private key:

cosign sign --key cosign.key ghcr.io/company/application:v1.2.0

Following the successful execution of the command, the system publishes a signature record tied to the original image in the corresponding OCI registry. Thus, any consumer of the package can validate the authenticity of the tag using the matching public key, ensuring the artifact has not been altered since its original compilation in the development pipeline.

Ensuring Integrity in Kubernetes at Runtime

Signing images during software builds solves only half the problem if the runtime environment fails to validate these signatures before starting pods. Kubernetes, as the standard platform for container orchestration, allows intercepting resource creation requests through admission controllers. In practice, these controllers act like security guards at a building entrance, blocking any attempt to deploy images that lack a valid and trusted digital signature.

To automate this validation, we use tools like Kyverno or Policy Controller combined with the Cosign verifier. When a developer attempts to submit a manifest to deploy a new version of a service, Kubernetes queries the admission controller. If the specified image lacks the expected cryptographic signature, the deployment is instantly rejected, preventing unknown or tampered code from reaching the infrastructure's production nodes.

Verification Architecture and Security Policies

Configuring admission policies requires defining clear rules regarding which keys and certification authorities are accepted in the cluster. In practice, this means creating declarative manifests that inform Kubernetes precisely which repositories require mandatory verification. This decentralized approach allows different teams to manage their own trust domains without compromising the stability or global security of the organization's entire technology stack.

Below we present an example validation policy using an admission controller to ensure that only images signed by a specific key are executed in the cluster:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-oci-signature
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: check-cosign
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/company/*"
          attestations:
            - predType: cosign
              keys:
                publicKeys: |
                  -----BEGIN PUBLIC KEY-----
                  MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...snip...
                  -----END PUBLIC KEY-----

With this policy active, any attempt to bypass the official build and signing process results in an immediate error in the operator's terminal. Kubernetes rejects the pod before it is even scheduled onto a node, shielding the environment against supply chain attacks based on typosquatting or compromised third-party container registries.

Final Considerations on Container Governance

Securing software supply chains in distributed environments is no longer a luxury; it is a critical engineering requirement. Combining digitally signed OCI artifacts with automated runtime verification in Kubernetes elevates an organization's security posture to a mature level. By closing operational gaps between code creation and production execution, we ensure resilience against sophisticated attacks targeting cloud infrastructure.

The success of this implementation relies on continuous automation and the strictness of the policies applied across clusters. When cryptographic verification becomes a native part of the infrastructure lifecycle, teams gain velocity without sacrificing operational reliability. Ultimately, supply chain security transforms blind trust into verifiable mathematical guarantees with every new release.