Introduction

Modern businesses rely on an interconnected web of third party vendors and open source software to operate efficiently. This reliance introduces a severe vulnerability known as the supply chain attack. A supply chain attack occurs when threat actors infiltrate a primary target by first compromising a less secure partner or service provider.

Cybercriminals exploit the implicit trust placed in these external entities rather than launching a direct assault on a hardened corporate network. Attackers can simultaneously breach countless downstream clients by simply corrupting a single widely used software update or hardware component. This post examines the fundamental mechanics of supply chain attacks to illustrate how they bypass traditional security perimeters and why organisations must urgently reevaluate their third party risk management strategies.

Recent headlines provide a stark warning about the escalating scale and sophistication of these threats. In early 2026 the cybersecurity community witnessed a severe compromise involving the widely used Trivy vulnerability scanner. Threat actors infiltrated the software distribution ecosystem and pushed malicious payloads through legitimate update channels. This allowed them to extract sensitive cloud credentials and breach infrastructure serving numerous entities across the European Union.

These incidents highlight a chilling reality. When adversaries compromise a trusted third party or an automated integration they can bypass the most rigorous internal security controls and turn a single routine update into a gateway for widespread disruption.

Securing the Pipeline with Cosign and Kubernetes

Integrating Cosign into a Kubernetes workflow represents a shift from reactive security to proactive enforcement. Cosign, part of the Sigstore project, simplifies the process of signing and verifying container images. By cryptographically binding a signature to an image manifest within an OCI registry, it ensures that the code running in production is exactly what the build system produced.

In a professional environment, this verification is often handled by an Admission Controller within the Kubernetes cluster. A policy engine like Kyverno makes this straightforward, allowing you to define image signature verification rules as native Kubernetes resources. However, relying solely on runtime checks can sometimes be too late in the lifecycle. Many organisations now implement "Shift Left" security by enforcing these policies directly at the registry level using enterprise grade tools such as Harbor.

1apiVersion: kyverno.io/v1
2kind: ClusterPolicy
3metadata:
4  name: verify-image-signatures
5spec:
6  validationFailureAction: Enforce
7  background: false
8  webhookTimeoutSeconds: 30
9  rules:
10    - name: check-signature
11      match:
12        any:
13        - resources:
14            kinds:
15              - Pod
16      verifyImages:
17        - imageReferences:
18            - "ghcr.io/your-organisation/*"
19          # Automatically converts tags to digests for immutability
20          mutateDigest: true
21          # Enforces that a digest must be present
22          verifyDigest: true
23          attestors:
24            - entries:
25                - keys:
26                    publicKeys: |-
27                      -----BEGIN PUBLIC KEY-----
28                      MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8nXRh950IZbRj8Ra/N9sbqOPZrfM
29                      5/KAQN0/KjHcorm/J5yctVd7iEcnessRQjU917hmKO6JWVGHpDguIyakZA==
30                      -----END PUBLIC KEY-----

Harbor is an open source trusted cloud native registry that provides a critical layer of defence before an image even reaches the orchestrator. Within its project configuration settings, administrators can enable specific deployment security policies that act as a hard gate:

• Content Trust Enforcement: Harbor can be configured to prevent any image from being pulled if it lacks a valid Cosign or Notation signature. This ensures that only verified, signed artefacts can leave the registry.
• Vulnerability Thresholds: Beyond signatures, Harbor integrates with scanners like Trivy to inspect images for known CVEs. You can set a policy to block the pull of any image that contains vulnerabilities exceeding a defined severity level, such as "High" or "Critical".

By using Harbor in conjunction with a Kubernetes Admission Controller, you create a redundant security model. Harbor prevents the distribution of insecure or unverified images across the network, while the Admission Controller ensures that even if an image were somehow injected into the environment, the cluster would refuse to execute it. This dual layered approach is essential for maintaining a hardened supply chain.

While digital signatures and registry policies form a robust defence, the way you reference images in your deployment manifests is equally critical. To achieve the highest level of security, organisations should transition from pulling containers by tags to pulling them by SHA512 digests.

The Flaw of Mutable Tags

Software tags, such as :latest or :v1.2.1, are mutable pointers. They can be reassigned to different images at any time. This mutability introduces a significant supply chain risk; if a registry or a developer account is compromised, an attacker can overwrite an existing tag with a malicious image.

Because the tag name remains the same, your Kubernetes cluster or CI/CD pipeline will pull the "updated" malicious version without triggering any immediate alerts. This lack of immutability makes it impossible to guarantee that the code running in production today is identical to the code that was audited yesterday.

The Security of SHA512 Digests

A SHA512 digest is an immutable, cryptographic checksum of the entire container image. Referencing an image by its digest (e.g., image@sha256:abcd...) ensures that you are pulling a specific, bit-for-bit version of the software.

Using digests provides several technical advantages for a hardened supply chain:

• Immutability: Once a digest is defined in your YAML manifest, it can never point to a different set of bits. Any change to the image, however minute, would result in an entirely different hash.
• Tamper Proofing: Even if a registry is compromised and an attacker tries to swap the underlying image data, the pull will fail because the downloaded content will not match the specified SHA512 hash.
• Scanning Consistency: When you scan an image for vulnerabilities, the results are only valid for that specific digest. By pulling by digest, you ensure that the image you scanned in staging is precisely the same one that enters production.

Managing the Root of Trust: Where to Store Cosign Keys

The integrity of your supply chain relies entirely on how you protect your signing authority. If a private key is compromised, an attacker can sign malicious code that your cluster will implicitly trust. To mitigate this, organisations generally adopt one of three strategies:

1. Keyless Signing (Sigstore)

The most modern approach is to eliminate long-lived keys altogether. By using Sigstore, Cosign generates an ephemeral key pair that exists only for the seconds it takes to sign the image. Your identity is proven via an OIDC token (e.g. from GitHub Actions or Google Cloud). A short-lived certificate is issued and the event is recorded in the Rekor transparency log. This removes the operational burden of key rotation and the catastrophic risk of a stolen static key.

2. Cloud Key Management Services (KMS)

For environments requiring a dedicated private key, Cloud KMS (such as AWS KMS, Azure Key Vault, or Google KMS) is the professional standard. In this model, the private key is generated within a Hardware Security Module (HSM) and is marked as non-exportable. Cosign sends the image digest to the KMS, the hardware signs it, and the signature is returned. The key never leaves the secure cloud hardware, providing a physical layer of protection.

3. Kubernetes Secrets and Vaults

While storing keys in Kubernetes Secrets is possible, it is typically reserved for internal testing. For production on-premises workloads, HashiCorp Vault or OpenBao provides a more robust alternative, offering fine-grained access control and detailed audit logs to track every time a signing key is accessed.

Use Keyless signing for automated pipelines to achieve maximum security with minimum overhead. If compliance mandates a physical root of trust, leverage a Cloud KMS to ensure your keys remain unextractable.

The Necessity of the SBOM

While a digital signature proves the origin of a container, it does not reveal the contents within. This is where the Software Bill of Materials (SBOM) becomes indispensable. Modern containers are often bloated with hundreds of third party dependencies, many of which contain hidden vulnerabilities.

An SBOM provides a comprehensive inventory of every library, package and licence included in the image. Providing this document is no longer just a best practice but a requirement for high security environments and government contracts. By coupling Cosign with SBOMs, organisations achieve two distinct layers of protection:

• Integrity: Cosign confirms the image has not been tampered with since it was signed.
• Visibility: The SBOM allows security teams to scan for newly discovered vulnerabilities (CVEs) within the software components long after the image has been built.

Tools such as Syft can generate these manifests in standard formats like SPDX or CycloneDX. Once generated, these SBOMs can themselves be signed by Cosign and attached to the image in the registry. This creates a secure, verifiable package that tells you exactly what is running and who authorised it, providing the transparency required to defend against sophisticated supply chain incursions.

Final Thoughts

Securing the modern supply chain is no longer an optional enhancement; it is a fundamental requirement for operational resilience. As we have seen, the transition from trusting arbitrary software tags to enforcing immutable, signed artifacts represents a critical evolution in cloud-native security.

By integrating Cosign and Kyverno, organisations can transform their Kubernetes clusters into self-defending environments that refuse to execute unverified code. Complementing this with Harbor for registry-level enforcement and providing comprehensive SBOMs ensures total visibility into the software stack.

The path forward requires a holistic approach where every component is cryptographically verified. Implementing these layers of defence today ensures that your infrastructure remains a fortress against the increasingly sophisticated threats of tomorrow. By removing implicit trust and replacing it with verifiable evidence, you secure not just your code, but the very foundation of your digital enterprise.

‍