Webinar Description
Key Takeaways
- Focuses on verifying hermetic build environments as required by SLSA security frameworks
- Demonstrates cryptographic proof techniques for build isolation and runtime verification
- Covers SBOM completeness validation and software provenance tracing
- Features Cocoon, an open source build packager running within Edera Protect isolated zones
- Integrates technologies including in-toto, SLSA, Sigstore and SPIFFE SVIDs
- Intended for software engineers, DevSecOps practitioners and supply chain security professionals
Verifying Build Isolation in Modern Software Supply Chains
Software supply chain security has become a critical concern as organisations face increasing pressure to demonstrate that their builds are genuinely isolated and free from tampering. This technical session, scheduled for 19 August 2026, addresses one of the more challenging aspects of secure software development: proving that build environments meet the hermetic isolation requirements specified by frameworks such as SLSA. The presentation is designed for software engineers, security practitioners and DevOps professionals working to strengthen their software supply chain integrity.
About This Event
Presenters Marina and Puerco will demonstrate practical verification techniques for build isolation and runtime characteristics. The session moves beyond theoretical compliance to address a fundamental question that many organisations struggle to answer: how can teams verify, after the fact, that a container image or binary was compiled in a truly hermetic environment without tampering processes or hidden tooling?
The demonstration centres on Cocoon, an open source build packager that operates within Edera Protect isolated zones. This tooling enables teams to verify attested machine identity through SPIFFE SVIDs, validate environment features, and confirm SBOM completeness using reusable policy code.
The Challenge of Proving Hermetic Builds
Security frameworks like SLSA require software builds to run in isolated environments to guarantee they remain free of unintended external influence. Meeting this requirement demands full control over the runtime environment and every dependency entering a build, ensuring no malware can slip into released software. However, achieving isolation is only part of the challenge. Organisations must also be able to demonstrate that isolation was maintained throughout the build process.
The session addresses several verification scenarios that security teams commonly encounter. These include providing cryptographic proof that builds occurred in hermetic environments, establishing confidence that software components match declared dependencies, and tracing provenance to the specific virtual machine that executed a given build.
Technology Integration and Policy Enforcement
The verification approach demonstrated in this session brings together several established supply chain security technologies. In-toto provides a framework for securing the integrity of software supply chains by defining policies that specify which steps must occur and which parties are authorised to perform them. SLSA offers a maturity model for build integrity, while Sigstore enables keyless signing and verification of software artefacts. SPIFFE SVIDs provide cryptographically verifiable identity documents for workloads, enabling attested machine identity verification.
By combining these technologies with reusable policy code, teams can establish automated verification workflows that provide auditable evidence of build integrity without requiring manual inspection of each release.
Who Should Attend
This session is particularly relevant for software engineers responsible for build pipelines, DevSecOps practitioners implementing supply chain security controls, and security architects evaluating compliance with frameworks such as SLSA. Teams working toward SBOM completeness requirements or seeking to establish cryptographic provenance for their software releases will find the practical demonstration directly applicable to their work.