Insights · Managed Services
Pinned, Signed, Scanned: A Sovereign Software Supply Chain
Owning your hardware is only half of sovereignty. The other half is knowing exactly what software runs on it. How we make every container image pinned, scanned, and signed — and why the registry is something you should run yourself.
Sovereignty is usually discussed as a hardware story — whose datacenter, whose network, whose disks. That matters, but it stops short. The more consequential question for most operators is quieter: do you know exactly what software is running on the hardware you own? A self-hosted cluster pulling unverified images from the public internet on every deploy has not actually escaped its dependencies. It has just moved them somewhere harder to see.
We treat the software supply chain as a first-class part of the boundary we own. The shape of it comes down to three disciplines — pinned, scanned, signed — and one architectural choice: the registry is ours.
Run your own registry
The first decision is to host the container registry inside our own infrastructure rather than depend on a public one. This is not about distrust of any particular provider. It is about removing a hard external dependency from the most security-sensitive moment in the lifecycle of a service: the instant it starts running. A registry we operate means deploys do not require reaching off our network, image availability is not someone else’s incident, and the full inventory of what we run lives in one place we control and can audit.
It also gives us somewhere to enforce the next two disciplines, because they all hang off the registry.
Pin to the artifact, not the label
A tag like latest — or even a version like 2.4 — is a moving label. The image
it points to today is not guaranteed to be the image it points to next week. For
anything we deploy, that ambiguity is unacceptable: the whole point of a build is
that it is reproducible. So we pin deployments to immutable identifiers, not
to friendly labels. A deploy references a specific, content-addressed artifact —
the exact bytes that were built and tested — and that reference cannot silently
drift underneath us.
The practical payoff is that “what is running in production” is always answerable precisely, and a rollback is just re-pointing at a previous known-good artifact. No guessing about which build a tag resolved to at deploy time.
Scan before it ships, and keep scanning
Pinning makes a build reproducible; it does not make it safe. Known vulnerabilities are discovered continuously, including in images that were clean the day they were built. So scanning is not a one-time gate at build — it is a standing cadence. Images are scanned for known vulnerabilities before they are eligible to run, and re-scanned on a routine schedule afterward, with an out-of-band rebuild triggered immediately when a high-severity issue lands in something we already ship.
The important design point is that “we scanned it once and it passed” is a dangerously incomplete claim. The threat landscape moves after the build is done. The cadence is what makes the guarantee durable.
Sign it, and refuse anything unsigned
The last discipline closes the loop between “we built and approved this” and “this is what is actually running.” Trusted images are cryptographically signed, and the cluster is configured to refuse to run anything that is not properly signed. An unsigned image — however it arrived — does not start.
This is the admission-control equivalent of the edge’s approval gate: a deliberate, enforced checkpoint that an artifact has to pass before it is allowed to take effect. It turns “please only deploy approved images” from a convention people are expected to follow into a rule the platform enforces on its own.
Why the discipline compounds
Each piece is modest on its own. Together they answer a question a lot of infrastructure cannot answer honestly: what, exactly, is running right now, where did it come from, and how do we know it has not been tampered with? Pinning makes the answer precise. Scanning keeps it honest over time. Signing makes it enforceable. And hosting the registry ourselves means none of it depends on a service we do not control.
Owning your hardware gets attention because it is visible. Owning your supply chain is the part that actually determines whether “sovereign” means something once the machines are humming.
supply-chaincontainersregistrysecuritysovereignty