# From "Trust Me" to "Verify Me" - Tom van den Berg - NDC Copenhagen 2026

## Executive 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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.

## Practical implications

- Implement artifact signing using digest references instead of mutable tags.
- Adopt the SLSA framework to define and enforce minimum security levels for all deployed software.
- Integrate provenance generation into build pipelines to capture detailed, verifiable metadata about every build run.
- Use OCI registries as a central source of truth for storing signed artifacts and their associated attestations (e.g., SBOMs, CVE reports).
- Enforce deployment policies using tools like Open Policy Agent that mandate the presence and validity of specific attestations.

## Topics

Software Supply Chain Security, Build Provenance, Artifact Attestation, SLSA Framework, DevSecOps, cosign, OCI registry

Source: https://www.youtube.com/watch?v=BSDvzzij6_Y