From "Trust Me" to "Verify Me" - Tom van den Berg - NDC Copenhagen 2026
Summary
The talk details the critical shift in software security from trusting producers to verifying artifacts through cryptographic evidence. Using the SLSA framework as a guide, the speaker demonstrates how build provenance and attestation provide verifiable proof of what was built, how it was built, and that it has not been tampered with. Key tools demonstrated include `cosign` for artifact signing and leveraging OCI registries to store signed artifacts and their associated metadata.
Key takeaways
-
Supply Chain Attacks are the New Frontier
2:25
Modern attacks no longer start in application code but in the build pipeline. Examples include the SolarWinds attack (2020) and recent compromises targeting CI secrets via supply chain vulnerabilities.
-
Digest-Based Signing is Mandatory
6:10
Relying on tags for artifact signing is dangerous because tags are mutable (can be rewritten). Security must rely on the content digest (SHA-256 hash) to ensure reproducibility and integrity.
-
SLSA Framework Guides Verification
14:30
The Open Source Security Foundation's SLSA framework provides a vocabulary of guidelines for securing the entire software development lifecycle, defining requirements for producers and consumers.
-
Verification Requires Provenance and Attestation
20:05
Build provenance is verifiable information detailing where, when, and how an artifact was produced. An attestation is a signed statement that verifies claims about the artifact (e.g., confirming successful security scans or build level).
-
Security Must Be Automated and Enforced
39:10
To make security actionable, verification must be integrated into CI/CD workflows as a mandatory deployment gate. This includes checking the SLSA build level and verifying all attached attestations.
Technical details
-
Artifact Signing
420s
Artifact signing involves creating a digital signature using a private key (e.g., via `cosign`) and pushing the artifact, the signature, and the associated metadata to an OCI registry.
-
OCI Artifacts
1650s
The Open Container Initiative (OCI) standard allows artifacts of any type (e.g., Terraform modules, ML models, markdown files) to be treated as first-class citizens in a registry, enabling them to receive signatures and provenance.
-
Build Provenance Structure
1305s
Provenance records contain verifiable information about the build process, including internal parameters (trusted by the platform) and external parameters (e.g., environment variables used). The subject of the provenance points to the artifact's digest.
-
SLSA Levels
950s
The SLSA framework defines security levels: Level 1 (basic), Level 2 (self-hosted runners), and Level 3 (isolated/unforgeable provenance). Achieving higher levels requires more rigorous controls.
-
Policy Enforcement
2500s
Advanced gatekeeping can use tools like Open Policy Agent (OPA) to enforce deployment policies, requiring artifacts to have specific attestations attached (e.g., a Bill of Materials or CVE report) before deployment.
Mentioned resources
- SLSA framework
- cosign
- OCI registry
Channel & topics
Watch on YouTube · Back to latest
This independent, AI-assisted summary is provided for commentary and informational purposes. It may contain errors or omit important context. Please watch the original video for the creator's complete presentation. Video, thumbnail, and related copyrights belong to their respective owners.