Digital Signatures at the Edge: Why Image Signing is the Next Step After CVE

To maximize the security of your container supply chain, automated CVE scanning at the cluster boundary is essential. The combination of registry scans and admission control ensures that code with known vulnerabilities never gets executed. This clears an important hurdle. However, a fundamental problem remains: a vulnerability scan only checks the content of a container at a specific point in time - it does not verify its origin and integrity.

In today’s often complex CI/CD environments, knowing whether an image is error-free is not enough. You need to be able to mathematically prove that the image about to be launched in the Kubernetes cluster is exactly the same as the one your developers or automated pipeline released an hour ago. Without cryptographic assurance through Image Signing, the pipeline remains vulnerable to sophisticated supply chain attacks where malicious code is silently inserted between the code repository and live infrastructure.

The Security Gap Despite Scanning: The Trust Problem

A conventional CVE scan is blind to manipulations in the transport chain. Without digital signatures on container artifacts, three specific attack vectors arise in enterprise environments:

1. The Man-in-the-Middle Attack on the Registry

An attacker gains unauthorized access to the container registry or intercepts network traffic. They replace a legitimate, previously clean-scanned image (e.g., backend:latest) with a manipulated version containing a crypto miner or a backdoor. Since the attacker crafts the malicious code not to trigger any known CVEs, the admission controller lets the image through. The cluster executes malicious code from a seemingly trusted source.

2. Tag Hijacking

Container tags (such as :latest, :v1.2, or :prod) are mutable in the OCI standard. A developer or a compromised script can upload a new, untested image under an existing production tag. Kubernetes does not notice the underlying code change during automatic scaling or node restarts and pulls the wrong image.

3. The Corrupted Pipeline (Shadow Deployments)

If attackers gain access to the CI/CD pipeline, they can manipulate the build process so that their own containers are built unnoticed alongside official artifacts and pushed directly into the cluster. A pure vulnerability scan might validate this code as “clean,” even though it was never approved by an authorized engineer.

The Solution: The Mathematical Seal via Cosign and Harbor

To radically solve this trust problem, the software supply chain is extended with a cryptographic signature layer. The modern industry standard for this is Cosign (from the open-source project Sigstore), which natively harmonizes with enterprise registries like Harbor.

The principle works like the digital seal on a certificate:

[ CI/CD Pipeline / Build Server ]
               |
               v (Image is built & verified)
[ Cryptographic Signing via Cosign ] <--- Private Key / KMS
               |
               v (Push of Image + Signature Metadata)
   [ Managed Harbor Registry ]
               |
               v (Deployment Request)
[ Kubernetes API Server / Policy Engine ] <--- Validation with Public Key
               |
     +---------+---------+
     |                   |
     v                   v
[ Signature Valid? ]  [ Signature Missing / Manipulated? ]
     |                   |
     v                   v
[ Deployment Allowed ] [ Deployment Hard Blocked ]

1. Signing Directly in the Trusted Build Environment

After the CI/CD pipeline successfully builds the container image and passes the CVE scan, Cosign is used. The pipeline uses a protected private key (securely stored in a key management system or protected pipeline variable) to digitally sign a cryptographic hash of the container.

2. Synchronous Push in the OCI Standard

Cosign pushes the resulting signature as a separate, linked artifact directly into the same Harbor registry. Since Harbor is fully OCI-compliant, the registry manages the signature metadata inseparably linked to the corresponding container image. The dashboard immediately visually declares the image as “Signed.”

3. Uncompromising Verification at Admission Control

When the image is requested in the Kubernetes cluster, a policy engine (such as Kyverno or OPA Gatekeeper) checks the image before it starts. The controller only possesses the company’s public key. It mathematically verifies whether the signature at the registry corresponds with this key and whether the image content (SHA256-Digest) has changed by even a single bit since the signing process. If the signature does not match or is completely missing, the deployment is rigorously rejected.

Strategic Added Value: Protection Against Insider Threats and CRA Compliance

Implementing image signing elevates the security level of your IT infrastructure to a new level and provides technical answers to complex regulatory requirements:

• Uncompromising Compliance with the Cyber Resilience Act (CRA): The CRA requires proof of the integrity and authenticity of software components throughout their lifecycle. Cryptographic signatures are the irrefutable mathematical proof that the delivered software exactly matches the verified version.
• Protection Against Insider Threats: Even administrators with extensive rights in the Kubernetes cluster cannot simply bypass the signature requirement. If an insider attempts to push a manipulated image directly from their local machine into the cluster, the start fails miserably because their private machine does not have the authorized signature key of the official CI/CD pipeline.
• Resilience Against Compromised Registries: Should the container registry itself become the target of a successful hacker attack and have malicious code injected, the manipulation will be detected at the cluster boundary at the latest. Attackers can swap images, but without the private pipeline key, they cannot forge a valid mathematical signature.

Conclusion: Trust is Good, Mathematics is Safer

CVE scanning and image signing are not competing concepts but the two heart chambers of a secure software supply chain. While scanning ensures the quality of the code, signing guarantees its authenticity. Those operating containerized workloads in highly regulated environments—be it under DORA, NIS-2, or the CRA—cannot rely solely on the mere absence of known errors. Only the digital seal at the edge makes the pipeline tamper-proof and establishes the unshakeable foundation for a true zero-trust model in Cloud-Native engineering.

FAQ: Image Signing & Cosign in Practice

Where Should the Private Keys for Image Signing be Stored?

The security of the entire signature setup hinges on the secrecy of the private key. In a professional enterprise environment, these keys should never be stored as raw text files in CI/CD variables. Best practice is to integrate key management systems (KMS) or cloud hardware security modules (HSM/BYOHSM). The pipeline triggers the signing process via a secure API, without the key ever leaving the protected hardware environment.

What Happens if a Signed Image Later Receives a New Critical CVE?

Image signing only confirms that the image is authentic and originates from your pipeline. It does not protect against software aging. If a new vulnerability is discovered in the image after three months, the signature remains mathematically valid, but the parallel active CVE scanner in Harbor will raise an alarm. The subsequent admission controller in the Kubernetes cluster checks both criteria: it requires a valid signature and adherence to maximum CVE thresholds.

Does the Setup Support Keyless Signing?

Yes. Cosign and the Sigstore ecosystem support a cutting-edge process called Keyless Signing. This eliminates the need to manage long-lived cryptographic keys. Instead, the CI/CD pipeline authenticates via short-lived OpenID Connect tokens (OIDC) with an internal certification authority. This authority issues an ultra-short-lived digital certificate valid only for the moment of the push. This eliminates the risk of private keys ever being stolen or leaked.