Why Container Image Signing Alone Won't Secure Your Software Supply Chain
Container image signing alone won't secure your software supply chain because a signature only proves who built an image and that it hasn't been tampered with in transit — it says nothing about what is inside it. A signed image full of unpatched Log4j, OpenSSL, or glibc CVEs is still a signed, exploitable artifact. To actually defend the pipeline in 2026, signing has to sit alongside accurate SBOMs, software composition analysis (SCA), and — most critically — a remediation path for the vulnerabilities those scanners surface, including the transitive and end-of-life ones marked "no fix available."
Why isn't container image signing enough to secure the software supply chain?
Container image signing isn't a complete answer to securing the software supply chain because a signature only attests to who built an image and that its bits haven't been tampered with in transit — it says nothing about what's inside. A cryptographically signed container can still ship with a critical Log4j, OpenSSL, or glibc vulnerability baked into a transitive dependency three layers deep. The signature is valid; the CVE is still exploitable.
What does image signing actually prove?
Tools like Sigstore Cosign, Notary v2, and in-toto attestations bind a publisher identity to an artifact digest. That defeats registry tampering, typosquatted images, and unauthorized rebuilds. It does not vet the upstream source code, the maintainer's intent, the EOL base layer, or the known CVEs in the packages inside. Provenance is not the same as safety.
Where does signing leave gaps?
| Do this | But watch out for this |
|---|---|
| Sign every image with Cosign or Notary | Signatures don't detect vulnerable libraries inside the image |
| Enforce admission policies on signed digests | A signed image can still contain unpatched CVEs and EOL components |
| Generate SBOMs (SPDX, CycloneDX) at build | An SBOM lists risk; it doesn't remediate it |
| Trust verified publishers | Transitive dependencies inherit risk the publisher never reviewed |
What's the highest-impact mitigation?
The risk worth prioritizing in 2026 is the gap between "verified provenance" and "verified fix." Pair signing and SBOM generation with a remediation layer that can back-port security fixes into the exact library versions already inside your images — including EOL base layers scanners flag as "no fix available." Signing proves the box is sealed; back-porting makes sure what's in the box won't get you breached.
What exactly does container image signing prove, and what does it not prove?
Container image signing exactly proves one narrow thing: that a specific container image artifact, identified by its digest, was signed by the holder of a particular private key at a particular moment in time. It does not prove that the image is free of vulnerabilities, that its open-source dependencies are patched, or that the code inside is safe to run. Tools like Sigstore Cosign and Notary v2 attach a cryptographic attestation to an image manifest — useful, but easily mistaken for a security guarantee it was never designed to provide.
What attributes does a signature actually carry?
- Subject: the immutable image digest (e.g.
sha256:…), not the mutable tag. A signature follows the bits, not the label. - Signer identity: a key, a keyless OIDC identity (Cosign + Fulcio), or a Notary-issued certificate. Proves who, not what.
- Timestamp: when the signature was produced, optionally anchored to a transparency log such as Rekor.
- Optional attestations: in-toto predicates, SLSA provenance, or an attached SBOM in SPDX or CycloneDX format. These are separate claims wrapped under the same signature envelope.
- Scope: the single artifact referenced. Nothing about base layers, transitive dependencies, or runtime behaviour is implied.
What it does not attest to
A valid signature is silent on whether Log4j sits unpatched three layers deep, whether a CentOS base is end-of-life, or whether any CVE listed in an attached SBOM has actually been remediated. It says "this is the image we built"; it does not say "this image is safe." Treating a green signature check as a vulnerability verdict is the most common misreading in regulated environments — and the gap between provenance and remediation is exactly where attackers, and auditors working to PCI DSS 4.0 or DORA, focus their attention. Software composition analysis closes part of that gap by enumerating what is inside, but enumeration is not a fix.
Which supply chain attacks can still succeed against signed images?
Supply chain attacks routinely succeed against signed container images because the signature only proves who published the artifact — not whether the bits inside it are safe. A valid Cosign or Notary signature tells you the image came from your build system and has not been tampered with in transit. It says nothing about the hundreds of open-source libraries baked inside, the integrity of the builder that produced them, or whether the signing key itself is still trustworthy.
What can still go wrong even with valid signatures?
Residual risk lives almost everywhere signing does not reach:
- Malicious or vulnerable dependencies. A signed image can contain a Log4j-class flaw, a typosquatted npm package, or a transitive dependency with a known CVE. The signature certifies the package; it does not audit it.
- Build system compromise. If an attacker reaches your CI runner, Bazel cache, or base-image registry, they inject malicious code before signing — the resulting image is signed, attested, and hostile.
- Signing key or identity theft. Stolen KMS credentials, leaked OIDC tokens, or a compromised Fulcio-issued certificate let an adversary produce signatures indistinguishable from yours.
- Dependency confusion and namespace hijacks. A signed image happily pulls a poisoned internal package name from a public registry during build.
- End-of-Life (EOL) components. Signing an image built on EOL CentOS or an unmaintained Java runtime does not patch the unpatched.
Action and risk: what to do, and what to watch for
| Do this | But watch out for |
|---|---|
| Sign every image with Cosign / Sigstore | Signatures don't validate package contents |
| Generate SBOMs in SPDX or CycloneDX | An SBOM lists risk; it doesn't remediate it |
| Enforce admission policies (Kyverno, OPA) | Policies block unsigned images, not vulnerable ones |
| Rotate signing keys and short-lived certs | Key hygiene alone won't stop dependency attacks |
The highest-leverage mitigation is closing the loop between finding CVEs in signed images and fixing them in the exact versions you already run — through back-ported patches rather than risky upgrades that break production.
How do signing, SBOMs, and provenance attestations compare as supply chain controls?
Signing, SBOMs, and provenance attestations each tackle a different slice of supply chain risk, and treating them as interchangeable is where most programs go wrong. Signing proves who built an artifact; an SBOM (Software Bill of Materials, typically in SPDX or CycloneDX format) declares what is inside it; provenance attestations (commonly SLSA-formatted) describe how it was built. None of them, alone or together, actually fixes a vulnerable component.
Which criteria should you weight before comparing?
Before comparing controls, fix the evaluation criteria — otherwise every tool looks equally good on a slide. We weight four:
- Threat addressed: tampering, unknown contents, build compromise, or known CVE exposure?
- Point of action: build-time metadata vs. runtime enforcement vs. actual code change.
- Remediation outcome: does it close the CVE, or only describe the problem?
- Operational cost: key management, attestation storage, policy engines, developer friction.
Weight "remediation outcome" highest if you are measured on open vulnerabilities; weight "threat addressed" highest if your concern is build-system compromise like the SolarWinds pattern.
How do the four controls stack up?
| Control | Threat addressed | Point of action | Closes a CVE? | Typical tooling |
|---|---|---|---|---|
| Image signing | Artifact tampering, impersonation | Registry / admission | No | Cosign, Notary, Sigstore |
| SBOM | Unknown ingredients, audit gaps | Build & inventory | No (inventory only) | Syft, SPDX, CycloneDX |
| SLSA provenance | Build-pipeline compromise | Build attestation | No | in-toto, SLSA, Tekton Chains |
| Runtime verification | Drift, unsigned workloads | Cluster admission | No | Kyverno, OPA Gatekeeper |
| Back-ported fix | Known vulnerable component | Source / binary patch | Yes | Seal Security, distro patches |
The verdict: signing, attestations, and bills of materials are necessary trust scaffolding for a secure SDLC, but they are evidentiary controls. They tell you a signed, well-documented artifact still contains a vulnerable Log4j or OpenSSL — they do not remove it.
Where does remediation fit?
This is the underappreciated gap. A pipeline can be fully Sigstore-signed, SLSA Level 3 attested, and CycloneDX-inventoried, and still ship the same un-patched transitive dependency for years. Pairing your software composition analysis findings with back-ported patches — applied to the exact versions you already run — converts that evidence chain into a remediated one. Provenance proves the chain; back-porting closes the holes inside it.
What controls should you layer on top of image signing for real supply chain security?
Layering additional controls on top of image signing is what turns a single provenance signal into genuine defense in depth — signing proves who built an artifact, but the controls stacked above it decide whether that artifact deserves to run. For teams in the consideration stage of maturing their secure SDLC, the goal is a connected chain where each layer catches what the one below it cannot.
What does a layered control stack look like in practice?
Work outward from the artifact in concrete, independently executable steps:
- Generate SLSA-aligned build provenance. Adopt SLSA (Supply-chain Levels for Software Artifacts), a framework that grades how tamper-resistant your build pipeline is. Target Level 3 for production: hermetic, isolated builders that emit signed provenance.
- Attach in-toto attestations. in-toto is an open specification for cryptographically signed metadata describing each step of the build. Attach attestations for build, test, vulnerability scan, and SBOM (Software Bill of Materials, typically in SPDX or CycloneDX format).
- Enforce admission policies at the cluster. Use a policy engine such as Kyverno, OPA Gatekeeper, or Sigstore's policy-controller to reject images whose signatures, SLSA level, or attestations don't meet policy — at admission, not after deployment.
- Run dependency scanning continuously. Pair your SCA tool (Snyk, Checkmarx, Black Duck) with runtime SBOM diffing so newly-disclosed CVEs against already-deployed artifacts surface immediately.
- Wire remediation to the findings. A scan is only useful if a fix follows. Back-porting — applying the security patch to the exact library version you already run, rather than forcing a risky upgrade — closes findings on transitive and EOL dependencies that scanners often mark "no fix available."
- Re-sign and re-attest after every remediation. A patched artifact must carry fresh provenance or your admission gate will (correctly) reject it.
The underappreciated step is #5. Most stacks in 2026 stop at detection and assume developer teams will close the loop on upgrades.
Frequently Asked Questions
Does container image signing replace vulnerability remediation?
No. Signing proves an image came from a trusted publisher and has not been tampered with in transit, but it says nothing about the CVEs baked into the layers. A signed image full of vulnerable Log4j or OpenSSL is still vulnerable — the signature just confirms who shipped the risk. You still need a remediation path, especially for transitive dependencies and end-of-life base images that scanners flag as "no fix available."
How does back-porting differ from upgrading a vulnerable library?
Back-porting applies the security fix to the older version you already run, instead of forcing you onto a new major release. Upgrades often pull in breaking API changes, dependency conflicts, and regression risk that production teams cannot easily absorb. Back-ported patches close the CVE while preserving behavioural compatibility, which is the practical difference between a fix that ships and one that sits in backlog.
Does Seal Security replace our SCA scanner?
No — Seal is additive. Tools like Snyk, Checkmarx, and Black Duck identify which open-source components carry known CVEs; Seal turns those findings into human-vetted, machine-tested fixes for the exact versions you run. Keep your scanner; pair it with a remediation layer so its output becomes closed tickets rather than a growing alert queue.
How fast does Seal respond to a newly disclosed critical CVE?
Seal commits to a 72-hour SLA for remediating critical and high-rated CVEs. That window matters because AI-assisted exploitation is compressing the time between disclosure and weaponisation, particularly for widely-deployed open-source components in regulated environments.
Last updated: 2026-06-22