In March 2021, the Linux Foundation launched Sigstore to solve a problem that had quietly plagued software supply chains for years: nobody could reliably prove that a container image was built by whom it claimed to be, or that it hadn't been tampered with between the registry and the runtime. Four years later, container image signing has moved from "nice to have" to a checkbox in federal procurement (Executive Order 14028), SOC 2 audits, and CNAPP vendor comparisons — including with Aqua Security, one of the more established names in cloud-native security. Teams evaluating Aqua's platform for image assurance often assume signing is a solved problem once a scanner is in place. It isn't. Scanning tells you what's inside an image; signing tells you whether you can trust where it came from. This post breaks down how image signing actually works, where teams get it wrong, how Aqua approaches it, and what a complete solution looks like in 2026.
What Is Container Image Signing, and Why Does It Matter Now?
Container image signing is the process of cryptographically attaching a verifiable identity and integrity guarantee to a container image so that anyone pulling it — a CI runner, a Kubernetes admission controller, a developer's laptop — can confirm it hasn't been altered since it was built and that it came from an authorized source. Mechanically, a signing tool computes a digest of the image manifest, signs that digest with a private key (or an ephemeral "keyless" identity backed by an OIDC token), and stores the signature alongside the image in the registry, typically as a separate OCI artifact or in the registry's supported attestation format.
The urgency is not theoretical. Docker Hub disclosed in April 2019 that attackers accessed a database exposing roughly 190,000 accounts, and in 2021 researchers found thousands of malicious images sitting in Docker Hub's public repositories, some downloaded millions of times before removal. Sonatype's 2022 State of the Software Supply Chain report measured a 742% average annual increase in software supply chain attacks over the prior three years. Signing doesn't stop every attack vector, but it closes the specific gap that lets a tampered or impersonated image slip into a pipeline undetected — which is exactly the gap exploited in incidents like the 2021 Codecov Bash Uploader compromise and the 2023 3CX build-chain attack.
How Do Attackers Exploit Unsigned Container Images?
Attackers exploit unsigned images primarily through three vectors: registry tampering, typosquatting, and compromised build pipelines. Without a signature, a Kubernetes cluster or CI system has no cryptographic way to distinguish myorg/api:v2.4.1 pushed by your release pipeline from an identically tagged image pushed by an attacker who gained temporary write access to the registry — tags are mutable pointers, not proof of origin.
Typosquatting is well documented on public registries: security researchers have repeatedly found malicious images published under names deliberately similar to popular ones (nginx1, pytorch-nightly variants, and similar patterns), counting on developers pulling by name without verification. A 2020 study by researchers at NYU and cloud security firms found hundreds of Docker Hub images embedding cryptominers or backdoors, several with tens of thousands of pulls. On the build side, the SolarWinds compromise (disclosed December 2020) and the later 3CX incident (March 2023) both demonstrated that an attacker who gets inside the build environment doesn't need to touch the registry at all — they poison the artifact before it's ever signed, or in the absence of signing, before it's ever distinguishable from a legitimate build. This is precisely why frameworks like SLSA (Supply-chain Levels for Software Artifacts, introduced by Google in 2021) tie signing to build provenance rather than treating it as a standalone control.
What Is the Difference Between Docker Content Trust and Sigstore/Cosign?
The practical difference is key management, and it's why most of the industry has moved on from the first generation of the technology. Docker Content Trust (DCT), built on Notary and TUF (The Update Framework), was Docker's original 2015-era answer to image signing. It works, but it requires teams to generate, rotate, back up, and protect long-lived private keys — operational overhead that caused adoption to stay low for years; DCT was largely opt-in and rarely enforced by default in production clusters.
Sigstore's cosign, released alongside the project's 2021 launch under the Linux Foundation with backing from Google, Red Hat, and Chainguard, introduced "keyless signing": instead of managing a long-lived key, a signer authenticates via OIDC (GitHub Actions OIDC, Google, GitLab, etc.), receives a short-lived certificate from Sigstore's Fulcio CA, signs the image, and the signature plus certificate are recorded in Rekor, a public, tamper-evident transparency log. No key ever needs to be stored or rotated by the engineering team. Cosign has become the de facto standard — it's the signing mechanism behind Kubernetes' own release artifacts since 1.24, and it's what most CNAPP and admission-control tooling now verifies against, including OPA Gatekeeper and Kyverno policies used to block unsigned images at the cluster boundary.
How Does Aqua Security Handle Container Image Signing?
Aqua Security handles image trust primarily through vulnerability scanning and policy enforcement in its CNAPP platform, with signature verification available as part of its image assurance policies rather than as a first-class signing workflow. Aqua's open-source scanner, Trivy, is widely deployed (routinely cited with over 20 million downloads a month across package managers) and does an effective job identifying CVEs, misconfigurations, and secrets in an image. Aqua also acquired Argon Security in December 2021 specifically to add software supply chain security capabilities — pipeline integrity, CI/CD risk detection, and artifact provenance — on top of its existing runtime and posture products.
Where teams evaluating Aqua often run into friction is that signing and verification live somewhat separately from the day-to-day scanning workflow: you can configure Aqua's admission controller to require signed images and check for Trivy scan pass/fail as an assurance gate, but generating and managing the signatures themselves typically means wiring cosign or Notation into your CI pipeline independently, then pointing Aqua's policy engine at the result. That's a reasonable architecture — it follows the "best tool for each layer" philosophy — but it means signing enforcement, key/identity management, and vulnerability policy live in different systems that your team has to keep in sync, which is where drift and gaps in enforcement typically creep in during audits.
What Should You Look for in a Container Image Signing Solution?
A complete solution needs four things working together, not as separate tools you have to reconcile: keyless signing tied to your CI identity, signature verification enforced at admission time, transparency-log backed non-repudiation, and provenance/SBOM attestation bound to the same signature. If any one of these is bolted on separately — say, signing in one tool and SBOM generation in another with no cryptographic link between them — an auditor (or an attacker) can find the seam.
Concretely, that means: OIDC-based keyless signing (no static keys sitting in a CI secrets store waiting to leak, as happened in the 2022 CircleCI breach that forced customers to rotate stored secrets and tokens); a Rekor-compatible transparency log so signatures are independently auditable outside your own infrastructure; Kubernetes admission control (via Kyverno, Gatekeeper, or a native controller) that rejects unsigned or improperly-attested images before they schedule, not just flags them in a dashboard after the fact; and SLSA-aligned provenance attestations bound to the same signing identity used for the image itself, satisfying both NIST SSDF and the EO 14028 requirements that many enterprise and public-sector buyers now require in vendor questionnaires.
How Safeguard Helps
Safeguard was built around the premise that signing shouldn't be a bolt-on step you configure once and hope holds — it should be an enforced, verifiable property of every artifact that moves through your pipeline. Safeguard integrates keyless signing via Sigstore/cosign directly into your CI/CD flow, so every image gets a short-lived, OIDC-backed signature and a Rekor transparency-log entry the moment it's built, with no private keys for your team to generate, store, or rotate.
From there, Safeguard binds SBOM generation and SLSA provenance attestation to that same signing identity, so a single verification step confirms three things at once: the image hasn't been tampered with, it came from the build you expect, and its declared contents match what's actually inside it. At deploy time, Safeguard's admission policies enforce signature and attestation checks at the cluster boundary — unsigned or unattested images are blocked before scheduling, not flagged after the fact — and every policy decision is logged for SOC 2 and EO 14028 audit evidence without extra tooling.
For teams currently running Aqua or a similar CNAPP for scanning and posture management, Safeguard is designed to slot in as the signing and provenance layer rather than force a rip-and-replace: you keep your existing vulnerability scanning and runtime protection, and Safeguard closes the specific gap — cryptographic proof of origin and integrity — that scanning alone was never built to solve. The result is one enforced chain of trust from commit to cluster, instead of several tools you have to manually keep in sync.