Supply chain security — Cosign, SLSA framework and in-toto attestations

The SolarWinds attack in 2020, the Codecov breach in 2021, and the XZ Utils backdoor in 2024 established software supply chain compromise as the dominant threat model for production infrastructure — not the runtime exploit of a running service but the injection of malicious code into the build and distribution pipeline that produces the software before it reaches production. Container images are a particularly attractive target because a single compromised base image or build tool can propagate the malicious payload to hundreds of downstream consumers through the registry pull mechanism, without any of those consumers making any change to their own code. Supply chain security for containers therefore requires answering three questions that vulnerability scanning alone cannot answer: who built this image, from which source code, using which build environment, and has any of that changed between what was tested and what was deployed? Cosign, the SLSA framework, and in-toto attestations are the three tools that provide cryptographic, auditable answers to these questions.

The key insight that distinguishes supply chain security from vulnerability scanning is the direction of trust. Vulnerability scanning asks 'does this artifact contain known bad components?' — a question that depends on the accuracy of the vulnerability database and the completeness of the SBOM. Supply chain security asks 'can I verify that this artifact was produced by the process I trust, from the source I control, without modification?' — a question that depends on cryptographic proof rather than database coverage. These two questions are complementary: a clean Trivy scan on a compromised image provides false assurance if the scanner itself was not running against the actual deployed bytes, while a verified Cosign signature on a malware-infected image proves provenance but does not indicate safety. A complete supply chain security posture requires both.

Analogy🏏Cricket

🏏 Think of it like cricket: The Pod-ReplicaSet-Deployment hierarchy maps precisely onto the three levels of IPL franchise team management. A Pod is a single player on the field at a given moment — the smallest unit of participation, carrying its own identity and fulfilling a specific role in the current game. A ReplicaSet is the franchise's match-day playing XI contract — it specifies that exactly eleven players matching a specific profile must always be on the field; if one is injured and leaves, the team management immediately sends a substitute of the same profile to restore the count. A Deployment is the franchise's season-long team strategy — it manages how the playing XI evolves between matches: when a new batting approach is adopted, the Deployment replaces the old XI with the new one in a controlled rolling substitution rather than swapping all eleven players simultaneously and disrupting team cohesion. Just as the franchise director does not manage individual players directly — the playing XI contract (ReplicaSet) handles the count and the season strategy (Deployment) handles the transitions — you never manage Pods directly in production; the Deployment manages the transition and the ReplicaSet maintains the count. This reveals why the three-level hierarchy exists rather than one omnibus 'workload' object: each level solves one specific problem, and composing three focused abstractions produces better separation of concerns than one object that conflates scheduling, scaling, and update management.