Signed Isn't the Same as Verified: Secure Builds Inside an Isolated Zone

A signature tells you someone approved an artifact. It doesn't tell you where that artifact was built, what kernel ran the build, whether the network was open, or whether the machine could be trusted in the first place. For a decade, that gap is where supply chain attacks have lived.

In our latest webinar, Edera's Marina Moore (Head of Research, Edera) and Adolfo García Veytia (Founder, Carabiner Systems) walk through what it takes to close the gap. The short version: you don't get verifiable build provenance by bolting attestations onto a shared-kernel build box. You get it by running the build inside an isolated environment that can prove its own state.

Watch the full replay below.

Why the Build Environment Is the Weak Link

Most supply chain tooling focuses on the artifact: sign the image, generate the SBOM, attach some metadata. That's necessary, but it assumes the machine doing the building is trustworthy. On a shared kernel, that assumption doesn't hold. Every build job shares kernel state with everything else on the node, and nothing in the signature can attest to the environment the build actually ran in.

Edera flips the starting point. Each build runs inside a zone — a single-tenant environment with its own kernel, isolated from the host and from every other workload on the machine. The zone isn't a sandbox layered on top of the build. It's the foundation the build runs on, and it becomes something you can make non-falsifiable and verifiable claims about.

Rooting Trust in the Zone, Not the Host

Isolation and identity are stronger together. Marina and Adolfo demonstrate a SPIRE-compatible setup where node attestation is rooted in the isolation boundary itself, so a workload can prove not just what it is, but that it's genuinely running inside a verified, isolated zone — down to the kernel and network configuration.

That's the difference between "trust me, this was signed" and "here's cryptographic evidence of exactly where and how this ran." If you want the deeper architectural argument behind this approach, Marina laid it out in Open Standards and Zero Trust on Commodity Hardware.

From Isolated Build to Verifiable Provenance

On top of the isolation layer, the demo shows how build evidence gets captured and gated:

• A hermetic build that runs with no network access, so dependencies can't be swapped mid-build.
• An in-toto attester that records the zone's real state — kernel, CPU, memory, network configuration — and signs it with the zone's own SPIFFE identity.
• Policy backed by Ampel that refuses to publish artifacts unless the required in-toto attestations are present and valid.
• SLSA-compatible Provenance you can verify immediately, or years later, without depending on the original build server still being around.

The result is build output you can trust before you run it or ship it — because the proof covers the environment, not just the file.

Note: parts of the demo tooling shown (including the "Cocoon" builder) are experimental and not yet publicly available.

Watch the Replay

The session runs through the full architecture and a live build demo — including the parts you can try yourself today with SPIRE, in-toto, and SigStore. If you care about SLSA, hermetic builds, or proving what actually ran in your pipeline, it's worth the watch.

Resource Links

Demo Link: https://github.com/carabiner-labs/edera-attester

SLSA: https://slsa.dev/spec/v1.2/

ampel: https://github.com/carabiner-dev/ampel

SPIFFE/SPIRE: https://spiffe.io/

in-toto: https://in-toto.io/

EderaON: https://on.edera.dev/

FAQ

What makes a build "verifiable" instead of just signed?

A signature proves someone approved an artifact. A verifiable build attaches cryptographic evidence about the environment it ran in — the kernel, the isolation boundary, the network configuration — so you can confirm how and where it was built, not just that it was blessed.

How do Edera zones improve supply chain security?

Each build runs in its own zone with a dedicated kernel, isolated from the host and other workloads. That isolation boundary becomes the root of trust for attestation, so build provenance reflects a verified environment instead of a shared-kernel machine you have to take on faith.

What is a hermetic build?

A hermetic build runs with no network access and all dependencies supplied up front, so nothing can be pulled or swapped mid-build. Combined with signed attestations, it lets you prove the build used exactly the inputs you expect.

Do I need special hardware for this?

No. The approach in the webinar uses open standards — SPIFFE/SPIRE, in-toto, and SigStore — rooted in Edera's isolation model, rather than specialized confidential computing CPUs.