We sign every image built in our pipeline with Cosign, but I'm trying to separate what that signature proves from what we might be assuming it proves. It confirms that the image hasn't changed since signing and that it came from our build process, but it doesn't prove that the base image was trustworthy or that a compromised dependency wasn't pulled in earlier.
We can verify signatures on upstream base images before the build starts, but signing is much less common for language-level dependencies. For those, we currently rely on lockfiles, pinned versions, and checksums, which provide some integrity protection but are weaker against compromised registries or dependency-confusion attacks.
For teams that have hardened this process end to end, what do you verify before building, and what controls do you use for dependencies that lack ecosystem-wide signing? Do you fail builds and deployments when checks fail, or mostly collect this information for audits?
4 Answers
Treat the controls as separate layers. Verify the base image’s signature and digest before the build, use a minimal or distroless base where practical, generate an SBOM, scan the result, and attach provenance and vulnerability attestations with the image signature. In the cluster, admission policies such as Kyverno or OPA can reject images that are unsigned or missing the required attestations. This still doesn’t make every dependency trustworthy, but it narrows the amount of upstream software you inherit and makes the remaining risk visible.
For language dependencies, lockfiles, exact versions, and verified checksums are usually the practical baseline until stronger signing support exists. I’d also build through an approved internal mirror or proxy, retain the artifacts you used, and restrict direct access to public registries from CI. That gives you a controlled source and reproducibility instead of allowing every build to resolve packages from the open internet.
A local mirror adds operational work, but it’s a tradeoff I prefer over unrestricted package downloads. It lets you curate and retain dependencies, although you still need a process for updating and reviewing them.
Signing proves provenance and integrity from the signing point onward; it does not certify that the contents are safe or that the inputs were clean. Make that distinction explicit in your threat model. A trustworthy build system, reproducible inputs, pinned dependencies, base-image verification, SBOMs, and vulnerability checks each cover different parts of the chain, so no single Cosign signature should be treated as a complete security verdict.
The biggest difference is whether verification is merely recorded or enforced. Start policy checks in audit mode so you can discover legitimate sidecars, init containers, and other exceptions. After the inventory is understood, move to enforcement for production and define narrow, reviewed exceptions. Otherwise a policy that rejects every unsigned artifact can break the cluster on day one and encourage people to bypass it.
Minimal images help a lot, especially when the final image contains only the compiled artifact and its runtime requirements. They reduce both the attack surface and the amount of base-image noise that scanners report.