Security in Continuous Delivery Pipelines Through Artifact Signature Validation with Cosign

The Silent Problem in the Software Supply Chain

In modern software development, we rely on hundreds of third-party libraries, ready-to-use container images, and automated tools that build our systems every day. This machinery, known as the continuous delivery pipeline (the automated process taking code from a programmer's computer to the production server), functions like an industrial assembly line. However, if an intruder manages to alter a single piece in the middle of this assembly line, the entire final system can be compromised without the team immediately realizing it.

In practice, this means that blindly trusting public code repositories or image registries without verifying the exact origin opens critical gaps for malicious code injection attacks. To resolve this invisible vulnerability, modern reliability engineering has turned to asymmetric cryptography, creating a mechanism where every built artifact carries an inviolable digital seal, proving exactly who created it and ensuring it was not modified along the way.

Understanding Cosign's Role in the Sigstore Ecosystem

Cosign is a modern open-source tool developed under the Sigstore project umbrella, specifically created to simplify the signing, verification, and storage of container artifacts. Traditionally, digitally signing a file required creating complex certificates, private keys guarded under lock and key, and bureaucratic processes that hindered developer velocity. Cosign removes this headache by allowing signatures without traditional key files, utilizing managed identities and public transparency.

In practice, the tool works by generating a cryptographic signature tied to a verifiable identity, such as a corporate email account authenticated via OpenID Connect (a standard protocol allowing web application user authentication without exposing passwords). When a container image is generated by the continuous integration server, Cosign applies a mathematical key to seal the package. This seal is then recorded in an immutable, public ledger, ensuring no one can delete or alter the history of that signature.

Implementing Automated Signing in the Pipeline

To put this protection into practice, we need to insert specific commands inside our automation pipeline configuration file, such as GitHub Actions or GitLab CI. The process occurs right after the container image build step and before it is pushed to the final repository. Below, we illustrate how to execute the signing using local keys and an automated workflow.

cosign generate-key-pair

The command above creates a key pair: a public one, which will be distributed to servers needing to validate the software, and a private one, which must be kept strictly confidential by the automation system. Next, after pushing the image to the registry, the pipeline runs the actual signing command, pointing to the exact address of the artifact generated in the cloud.

cosign sign --key cosign.private.key my-registry.azurecr.io/app/service:v1.2.0

This command reads the private key, calculates the unique digital fingerprint of the container image, and writes the signature directly to the image registry alongside the original package. Any subsequent change to the image content will instantly invalidate this mathematical signature.

Validating Artifacts Before Production Execution

Signing files is only half the battle; true security happens the moment the production environment decides whether to accept or reject the execution of that package. Before a server or computer cluster downloads and runs the container image, the system must perform a rigorous check using the corresponding public key.

In practice, we configure the environment to refuse any image that lacks a valid, recent signature issued by an authorized organizational key. If an attacker manages to replace the legitimate image with a tampered copy inside the public registry, the verification process will fail immediately, halting deployment and triggering alerts for the security team.

cosign verify --key cosign.pub my-registry.azurecr.io/app/service:v1.2.0

If verification succeeds, Cosign returns the signature details and the command exits without errors, freeing the operating system to start the container with complete peace of mind. Otherwise, the command returns an explicit failure, blocking untrusted software access to the productive environment.

Automating Security with Kubernetes Admission Policies

Doing manual checks via the command line works well for testing, but in large-scale production environments utilizing container orchestrators like Kubernetes (a system managing thousands of applications distributed across multiple servers), the process must be fully automated. For this, we use admission controllers, which intercept every attempt to create new pods and validate their signatures in the background.

Tools like Kyverno or Sigstore's Policy Controller work alongside Cosign to enforce strict business rules. For instance, we can define a policy stating: "No container can run in this cluster unless its image has been signed by our engineering team's official key and logged in the public ledger." If someone tries to bypass this rule by submitting a raw manifest directly to the cluster, Kubernetes itself will reject the request before even allocating hardware resources.

Final Considerations and Next Steps

Security in continuous delivery pipelines is no longer an optional luxury and has become a fundamental requirement for the operational survival of any technology company. Introducing artifact signatures through modern tools like Cosign mitigates supply chain attack risks without imposing excessive friction on developers' daily workflows.

By combining cryptographic keys, transparency logs, and automated execution policies, organizations build insurmountable barriers against silent tampering. The next step for mature teams is to extend this validation beyond containers, applying the same conceptual rigor to configuration files, deployment charts, and artificial intelligence models.