Quick question: how many container images are running in your clusters right now? Follow-up question: how many packages are inside them, and how many of those packages does anything actually use?
If you don't know, you're in good company. Most platform teams don't, because the answer is usually "thousands" and "frighteningly few." Every unused package, shell, and debug tool sitting inside a container image is attack surface you're carrying around for no benefit, like airport souvenirs you'll never look at again.
That's why, starting with Palette 4.9.b, we're rolling out hardened container images across the platform.
Over the next few releases, the system components, binaries, and packs that Palette deploys will move to minimal, continuously patched, signed images with a dramatically smaller attack surface. By release 4.10.0, hardened images will be the standard for connected deployments of Palette, Palette VerteX, and PaletteAI.
This post covers what's changing, why we're doing it, and the one small thing most customers will need to do about it. (Spoiler: it's configuring a pull secret, once. We'll walk you through it.)
Why now: the supply chain problem keeps getting worse
Modern software is assembled rather than written. A typical Kubernetes platform pulls together base images, open source libraries, Helm charts, CNIs, CSIs, observability stacks, and a small army of CLI tools, all from different sources. Every one of those is a link in your software supply chain, and every link is a potential point of compromise.
The numbers are heading the wrong way. Cybersecurity Ventures estimates that software supply chain attacks cost businesses $60 billion globally in 2025, up from $46 billion in 2023, on their way to a projected $138 billion by 2031. The 2025 wave of attacks on package registries and build pipelines showed that attackers have figured out the economics: why breach one company when you can poison a dependency used by ten thousand?
If you're in government, defense, or a regulated industry, this isn't just a risk conversation. Executive Order 14028 and subsequent CISA guidance require agencies and their contractors to demonstrate software provenance, produce SBOMs, and follow secure development practices. "Trust us, it's fine" stopped being an acceptable answer some time ago. Now you need to prove it, with paperwork.
What "hardened" actually means here
‘Hardened images’ gets thrown around as a marketing term, so let's be specific about what you're getting. The images we're adopting, built and continuously maintained with a specialist commercial partner, are:
- Minimal. Unnecessary packages, shells, and debug tools are stripped out, with distroless variants where appropriate. Less software means fewer CVEs and less attack surface.
- Secure by default. Workloads run as non-root, with hardened configurations aligned to CIS Benchmarks.
- Continuously patched. Security fixes land on a predictable cadence, with SLA-backed updates for long-term support versions.
- Verifiable. Every image ships with a signed SBOM, provenance attestations (in-toto/SLSA), and scan results. You don't have to take our word for what's inside; you can check.
- Compliance-ready. FIPS variants serve Palette VerteX and PaletteAI VerteX deployments, with alignment to STIG and CIS requirements that government and defense customers care about.
In practice that means the third-party components Palette deploys on your behalf (think cert-manager, Traefik, CNIs like Calico and Cilium, CSIs, monitoring packs) plus the binaries we use under the hood (kubectl, helm, syft, grype) will come from hardened, attested sources. Your security team ultimately gets a smaller CVE backlog to triage and cryptographic proof of where everything came from. Everybody wins, except the people writing exploit kits.
This isn't a new direction for us…
ICYMI, we've been banging the software supply chain drum for a long time. Palette has had SBOM and vulnerability scanning built into cluster operations for years, alongside CIS-hardened OS images, immutable edge deployments, and signed content bundles. We're members of the OpenSSF, the Linux Foundation body that shepherds projects like Sigstore and SLSA. And at KubeCon we've worked alongside Airbus Defence and Space to present real-world frameworks for verifiable supply chains at the edge.
If you want the deeper technical story on signing, provenance, and why identity beats static keys, our recent post on securing the Kubernetes software supply chain covers it properly. Hardened images are us applying those same standards to every component we ship, instead of just advocating them at conferences.
How it works: one secret, set once
Hardened images live in private registries and require authentication to pull. That's a deliberate part of the security model (anonymous public pulls and verified provenance don't mix well), but it does mean one change on your side: an image pull secret.
Don’t worry: you won’t have to edit secrets into hundreds of cluster namespaces. The pull secret is configured once per Palette or VerteX instance, and the platform propagates it automatically to every managed workload cluster and namespace that needs it. New clusters get it on day one. New images we add later are covered by the same secret. If your security policy requires rotation, you can rotate it natively through the system console without touching individual clusters.
Set it once, and Palette handles the rest. That's the way a management platform should work, isn’t it?
What happens now?
If you run Palette, VerteX, or PaletteAI in connected mode, this change applies to you. A few exceptions:
- SaaS customers: we handle it on the backend. Nothing to do apart from check that the key is there. Enjoy your coffee.
- Fully airgapped deployments with mirror registries configured, where no images are pulled from our public registries: exempt. Your isolation already does the job.
- Pull-through cache users (Harbor, Artifactory and friends): you're included, and you'll configure the registry credentials at the cache.
We've deliberately phased the rollout over the next few releases to give you time to adapt. If you have a customer success manager or TAM, they'll be reaching out proactively to walk you through it. If you'd rather not wait, contact them directly or raise a support ticket and we'll get you set up.
And if you're not yet a Spectro Cloud customer: this is what full-stack security looks like when it's a product principle instead of a compliance checkbox. From hardened OS images to attested container images to FIPS-validated cryptography in Palette VerteX, we sweat the layers underneath your workloads so your team doesn't have to. If that sounds like the kind of platform partner you'd rather have, book a demo and we'll show you around.