Published

March 13, 2026

Signing, sealing, delivering: how to secure your Kubernetes software supply chain from build to edge

The software supply chain is under siege. In 2025 alone, coordinated attacks on npm packages compromised thousands of developer systems; GitHub Actions exploits leaked secrets across hundreds of repositories; and a hijack of 18 widely used open source libraries put billions of weekly downloads at risk. What’s striking is the pattern these incidents share: attackers didn’t break through firewalls or crack passwords. They exploited the implicit trust that developers place in the tools and artifacts they use every day.

For organizations running Kubernetes in production — and especially those operating at the edge, in air-gapped environments, or under government and defense compliance regimes — that kind of trust isn’t a luxury you can afford. When a container image leaves your CI/CD pipeline and lands on an edge device outside the four walls of a data center, you need cryptographic proof that it hasn’t been tampered with. You need to know who built it, when, and from what source. Promises aren’t enough. You need evidence.

In this post, we’ll explain how digital signatures work in the context of modern software artifacts, how Sigstore and Cosign make signing practical at scale, and how Spectro Cloud embeds these capabilities directly into Kubernetes orchestration so you can enforce a verifiable chain of trust from code commit to edge cluster.

Why software supply chain security demands action now

Modern software is assembled, not written. A typical Kubernetes application pulls in base container images, open source libraries, Helm charts, CI/CD tooling, and infrastructure-as-code modules from dozens of different sources. Each one is a link in the supply chain. Each one is a potential point of compromise.

The numbers are sobering. Supply chain attacks are projected to have cost businesses $60 billion globally in 2025, triple the impact from 2021. SolarWinds, Log4Shell, the xz backdoor, the tj-actions/changed-files compromise of March 2025: each demonstrated a different vector, from poisoned dependencies and compromised CI pipelines to backdoored build tools and tampered GitHub Actions. And those are just the ones that made headlines.

For defense and public sector organizations, the stakes run even higher. Executive Order 14028 and CISA guidance now require agencies and their contractors to demonstrate software provenance, produce SBOMs, and implement secure software development practices. The CNCF Public Sector User Group (which Spectro Cloud co-chairs) published a landmark white paper in November 2025, laying out a reference architecture for secure software supply chains (S3C) aligned with NIST and CISA standards. The framework breaks the challenge into three functional stages: establish trust, generate verifiable evidence, and share and verify artifacts across trusted networks.

But this isn’t just a government problem. Any organization shipping software to environments it doesn’t fully control (edge retail locations, hospital imaging devices, factory floors, restaurant kiosks) faces the same fundamental question: can you prove that what’s running on that device is exactly what you intended?

The risks hiding in your software artifacts

Modern software artifacts — container images, Helm charts, OCI binaries, Zarf packages — are frequently updated, often by different parties at different times. This dynamic environment exposes end users to threats that traditional perimeter security simply can’t address.

When we talk about securing software artifacts, two concerns are foundational:

• Integrity: has the artifact been altered between the moment it was signed and the moment it reaches the target system?

• Authenticity: did the artifact actually originate from the claimed source?

These sound straightforward, but in practice they’re remarkably hard to guarantee. A container image tag can be overwritten with entirely different content. A CI pipeline can be injected with malicious logic while leaving the source code untouched. An old, signed artifact can be replayed to reintroduce known vulnerabilities. In every one of these cases, the system behaves exactly as designed... it just deploys something you didn’t intend.

At the edge, these risks are amplified. Edge devices often operate without continuous monitoring, lack instant rollback capability, may be physically accessible to adversaries, and suffer delayed detection when something goes wrong. Failures propagate slowly but widely. As our colleagues at Airbus Defence and Space put it in our forthcoming KubeCon EU 2026 session: integrity must be proven, not assumed.

How digital software signatures work

A digital signature scheme provides a mathematical guarantee of both integrity and authenticity. The core components are straightforward:

1. Key generation: a signer produces a public/private key pair using a cryptographic algorithm such as ECDSA or RSA.

2. Signing: the private key creates a signature over the artifact (or its hash), binding the signer’s identity to the artifact’s exact content.

3. Verification: anyone with the corresponding public key can verify the signature, confirming both who signed the artifact and that its contents haven’t changed.

This is well-understood cryptography. The hard part isn’t the math: it’s key management. Distributing public keys securely, protecting private keys from compromise, revoking and replacing keys when something goes wrong... these operational challenges have historically made artifact signing impractical for most organizations. That’s where Sigstore changes the game.

Sigstore and Cosign: making artifact signing practical

Sigstore is an open source ecosystem under the OpenSSF (Open Source Security Foundation) — of which Spectro Cloud is a member — aimed at making software signing ubiquitous, transparent, and simple. Its core insight is elegant: identity, not static keys, should be the root of trust.

Cosign is the signing tool within Sigstore. Its recommended approach, keyless signing, works like this:

• The signer authenticates via an OIDC provider (Google, GitHub, Microsoft) and receives an ID token.

• Cosign generates a short-lived private key in memory and sends the corresponding public key, along with the ID token, to Fulcio (Sigstore’s certificate authority).

• Fulcio issues a short-lived certificate (valid for ten minutes) that binds the signer’s identity to the public key.

• Cosign signs the artifact and records both the signature and the certificate in Rekor, Sigstore’s transparency log: a publicly queryable, tamper-evident ledger.

• The private key is then discarded. Because the signature is anchored to an identity and a timestamp in the transparency log, verification doesn’t require access to any long-lived key.

This eliminates the key distribution, storage, and revocation problems that have historically plagued artifact signing. Verification becomes a straightforward question: was this artifact signed by a known identity, at a known time, through a known build process?

Sigstore supports a wide range of artifact types, including OCI-compliant container images, Git tags, blobs, Tekton bundles, and WASM binaries. Major platforms (including Kubernetes itself, GitHub, and Arch Linux) already integrate Sigstore natively. Cosign has reached general availability with a stable API, making it production-ready for enterprise adoption.

Beyond signatures: SLSA and provenance

Signing an artifact proves who signed it and that it hasn’t been modified. But it doesn’t prove how it was built, or from what source code. That’s where SLSA (Supply-chain Levels for Software Artifacts) comes in.

SLSA is a framework (also under the OpenSSF umbrella) that defines increasing levels of assurance around build integrity, provenance, and verifiable traceability. At higher SLSA levels, a signed artifact comes with attestations that record the build platform, the source repository, the dependencies consumed, and the workflow that produced it.

This matters because several of the most damaging attack vectors don’t target the code at all. They target the build process. A compromised CI pipeline can inject malicious logic into a clean codebase. A poisoned dependency can pass every test without raising an alert. An image tag can be overwritten to point to entirely different content. In every case, a signature alone isn’t sufficient: you need provenance that explains how the artifact came into existence.

Combining Sigstore signatures with SLSA provenance attestations gives you a robust evidence chain — who built it, from what source, on what platform, with what dependencies, and when. That’s the foundation for admission policies that reject anything unexplained.

How Spectro Cloud secures the supply chain from cloud to edge

Understanding how signing and provenance work is one thing. Operationalizing them at scale, across hundreds or thousands of Kubernetes clusters (including edge devices in disconnected environments), is quite another.

Spectro Cloud’s Palette and Palette VerteX platforms use full-stack declarative orchestration to manage Kubernetes clusters from the operating system layer through to user applications. Configurations are organized as cluster profiles: composable, version-controlled definitions that cover the OS, container networking, container storage, Kubernetes distribution, and CNCF add-ons. These profiles can be applied to an entire fleet of clusters, ensuring consistent conformance across thousands of nodes.

Signed content bundles for edge

For edge deployments, cluster profiles are used to generate offline content bundles via Spectro Cloud’s edge-cli tool. This tool authenticates to the Palette endpoint, consolidates the cluster definition (Helm charts, manifests, Zarf packages, and container images) into a single binary, and signs all artifacts using Cosign. The signed bundle can then be shipped to edge devices to deliver either an initial software payload or an update.

On the edge host, embedded verification keys ensure that only content from trusted sources gets deployed. If a signature doesn’t match, the content is rejected. This prevents tampering with edge devices in environments where physical security can’t be guaranteed: a retail store, a hospital, a forward-deployed military installation, or a manufacturing floor.

Artifact Studio: a single source of truth

Spectro Cloud’s recently launched Artifact Studio extends this model to the platform itself. Every download (bundles, packs, ISOs, and installers for self-hosted Palette, Palette VerteX, or PaletteAI) includes a sig.bin file verifiable against Spectro Cloud’s published public key, giving teams an authoritative record of what was released, when, and for whom. For the full story on how Artifact Studio fits into the broader challenge of secure software sharing, see our companion post on secure software artifact sharing.

Declarative enforcement at admission

The final piece is enforcement. Palette integrates with policy engines like OPA and Kyverno to enforce admission policies at the cluster level. These policies can require that every container image be signed by a known identity, carry valid SLSA provenance, include an SBOM, or meet freshness requirements — rejecting anything that fails the check before it ever reaches a running pod. This isn’t configuration-as-security. It’s evidence-based verification, baked into the orchestration layer.

Proving trust: from theory to practice with Airbus

At KubeCon EU 2026 in London, Spectro Cloud’s Sheldon Lo A Njoe and Nicolas Ferrao of Airbus Defence and Space will present “Proving Trust: Signed Supply Chains and Verifiable Deployments at the Edge.” The session walks through real attack vectors (compromised dependencies, CI pipeline injection, image tag substitution, unauthorized GitOps updates, replay and downgrade attacks) and demonstrates how each can be mitigated through signature verification, provenance policies, and digest-pinned deployments.

The core message is one that resonates well beyond aerospace and defense: none of these attacks required breaking Kubernetes. They all exploited implicit trust. The system assumed the build was correct, the artifact was authentic, and the update was authorized. What stopped them wasn’t a firewall... it was verifiable evidence.

That lesson applies everywhere, but it carries particular weight in defense and aerospace, where edge devices may operate without continuous monitoring, without instant rollback capability, and in environments where physical access by adversaries is a realistic scenario.

Playing our part in the wider community

Securing the software supply chain isn’t a problem any one vendor can solve alone. It demands open standards, shared infrastructure, and cross-industry collaboration.

Spectro Cloud contributes to this effort through several channels. We’re members of the OpenSSF, which shepherds critical projects including Sigstore, SLSA, GUAC, and the OSPS Baseline. And at events like KubeCon, we work alongside organizations like Airbus Defence and Space to share real-world implementations of these standards.

We’re also, of course, a software publisher ourselves. Every artifact we ship has to meet the same standards we advocate for our customers. Artifact Studio, signed edge content bundles, and declarative policy enforcement are how we hold ourselves accountable.

What you can do today

If you’re not yet signing your software artifacts, the time to start is now. Here’s a pragmatic path forward:

• Start signing container images with Cosign. Keyless signing via Sigstore eliminates the key management burden and can be integrated into any CI/CD pipeline with minimal effort.

• Generate SLSA provenance for your builds. Tools like SLSA GitHub generators produce provenance attestations automatically, giving you a verifiable record of how each artifact was produced.

• Enforce admission policies in your clusters. Use OPA, Kyverno, or a similar policy engine to require valid signatures and provenance before any image is admitted to a running workload.

• Produce and publish SBOMs. Know what’s in your software, and make that information available to your consumers. In many public sector contexts, this is already a regulatory requirement.

• Pin images by digest, not tag. Tags are mutable; they can be overwritten. Digests are content-addressed and immutable. At the edge especially, tags are a liability.

For organizations that need to go further (managing signed content bundles for air-gapped edge deployments, enforcing compliance across a fleet of thousands of clusters, meeting FedRAMP and FIPS requirements) that’s where Spectro Cloud can help. Put us to the test.