From Mild To Wild

How Hot Can Your SLSA Be?

Andrew McNamara (Conforma) • Adolfo "puerco" García Veytia (AMPEL)

artifact → predicate + signature → attestation

{
  "subject": {
    "name": "registry.k8s.io/kube-proxy:v1.36.0-beta.0",
    "digest": { "sha256": "5f013cc6fb21eb60820bfc4a925fddb710a70acecd56166874da8ef2c13d3933" }
  },

  "predicateType": "https://in-toto.io/attestation/promotion-record/v1",
  "predicate": {
    "srcRef": "us-central1-docker.pkg.dev/k8s-staging-images/kube-proxy:v1.36.0-beta.0",
    "dstRef": "registry.k8s.io/kube-proxy:v1.36.0-beta.0",
    "digest": "5f013cc6fb21eb60820bfc4a925fddb710a70acecd56166874da8ef2c13d3933",
    "promotedAt": "2026-03-21T19:56:27Z",
    "builderId": "htts://sigs.k8s.io/promo-tools/v4.0.9"
  }
}

Attestations = signed statements about an artifact (who built it, from what, how).
Often in-toto: predicate (e.g. SLSA provenance) + signature.

Verify provenance properties</span> ??? Puerco introduces this level. As mentioned before, an attestation is a signed statement about your software — produced by your build system, your CI pipeline, or a verification tool. At mild, we verify fundamental provenance properties: is provenance present, is the build type recognized, does it come from a trusted builder, were materials properly tracked? This is where everyone should start. --- layout: false ## 🌶 Mild: Verify Provenance Properties ??? Puerco introduces the mild checks. These are the foundational properties every consumer should verify. They're entirely build-system-agnostic — they work with provenance from GitHub Actions, Tekton, or any other system that produces SLSA-formatted attestations. --- ## 🌶 Mild: AMPEL PolicySet ```hjson { id: set-base-verification frameworks: [ { id: SLSA, name: "Supply-Chain Levels for Software Artifacts" } ] policies: [ { id: slsa-builder-id source: { location: { uri: "git+https://github.com/carabiner-dev/policies#slsa/slsa-builder-id.json" } } meta: { controls: [ { framework: SLSA, class: BUILD, id: LEVEL_3 } ] } } { id: slsa-build-type source: { location: { uri: "git+https://github.com/carabiner-dev/policies#slsa/slsa-build-type.json" } } meta: { controls: [ { framework: SLSA, class: BUILD, id: LEVEL_3 } ] } } { id: slsa-build-point source: { location: { uri: "git+https://github.com/carabiner-dev/policies#slsa/slsa-build-point.json" } } meta: { controls: [ { framework: SLSA, class: BUILD, id: LEVEL_3 } ] } } ] } ``` **Result**: pass / fail per rule. Works with any build system that produces SLSA provenance. ??? Puerco walks through the AMPEL policy for mild. Two tenets: the first checks that SLSA provenance exists, the second verifies the VSA declares at least Build Level 1. No hardcoded builder identity or build type. CEL expressions keep the policy compact and readable. --- ## 🌶 Mild: AMPEL Policy ```hjson { id: slsa-build-point context: { buildPoint: { required: true, type: string } buildPointAllowRepo: { required: false, type: bool, default: true } buildPointCommit: { required: false, type: string, default: "" } } tenets: [ { predicates: { types: ["https://slsa.dev/provenance/v1"] } outputs: { uri: { code: "has(predicate.data.buildDefinition) && has(predicate.data.buildDefinition.resolvedDependencies) && predicate.data.buildDefinition.resolvedDependencies.exists(dep, has(dep.uri) && (dep.uri.contains('@') ? dep.uri.split('@')[0] : dep.uri) == (context.buildPoint.contains('@') ? context.buildPoint.split('@')[0] : context.buildPoint)) ? predicate.data.buildDefinition.resolvedDependencies.filter(dep, has(dep.uri) && (dep.uri.contains('@') ? dep.uri.split('@')[0] : dep.uri) == (context.buildPoint.contains('@') ? context.buildPoint.split('@')[0] : context.buildPoint))[0].uri : ''" } commitMatch: { code: "context.buildPointCommit != '' && has(predicate.data.buildDefinition) && has(predicate.data.buildDefinition.resolvedDependencies) && predicate.data.buildDefinition.resolvedDependencies.exists(dep, has(dep.uri) && (dep.uri.contains('@') ? dep.uri.split('@')[0] : dep.uri) == (context.buildPoint.contains('@') ? context.buildPoint.split('@')[0] : context.buildPoint) && has(dep.digest) && dep.digest.exists(k, dep.digest[k] == (context.buildPointCommit.contains(':') ? context.buildPointCommit.split(':')[1] : context.buildPointCommit)))" } } code: "outputs.uri != '' && (context.buildPointAllowRepo || outputs.uri == context.buildPoint) && (context.buildPointCommit == '' || outputs.commitMatch)" assessment: { message: "Expected build point found: " } error: { message: "Build point mismatch" guidance: "The attested build point does not match the expected reference" } } ] } ``` **Result**: pass / fail per rule. Works with any build system that produces SLSA provenance. ??? Puerco walks through the AMPEL policy for mild. Two tenets: the first checks that SLSA provenance exists, the second verifies the VSA declares at least Build Level 1. No hardcoded builder identity or build type. CEL expressions keep the policy compact and readable. --- ## 🌶 Mild: Run the AMPEL Policy ```shell ampel verify sha256:734d6c22b80cdf9bd21c6b13d3475cf02c888d4a0b00d2e092a735 \ # Path to policy --policy "1-mild/ampel/policy.hjson" \ # SLSA Attestation --attestation "slsa.json" ``` --- ## 🌶 Mild: Run the AMPEL Policy ```shell ampel verify "$(crane registry.access.redhat.com/ubi10/ubi-minimal:latest)" \ # Policy code --policy '1-mild/ampel/policy.hjson' \ # Read attestations attached to the image --collector 'coci:registry.access.redhat.com/ubi10/ubi-minimal:latest' \ # Pass the build point to check --context 'buildPoint:git+https://gitlab.com/redhat/rhel/containers/ubi10-minimal.git' \ # Output an attested copy of the resutls --attest-results=true \ # Output the results as a VSA --attest-format 'vsa' ``` --- ## 🌶 Mild: "Conforma Does That Too" Same checks, different engine: ```rego # Conforma policy — verify foundational provenance properties deny contains result if { count(lib.slsa_provenance_attestations) == 0 result := lib.result_helper(rego.metadata.chain(), []) } deny contains result if { some att in lib.slsa_provenance_attestations build_type := _build_type(att) # handles both SLSA v0.2 and v1.0 allowed := lib.rule_data("allowed_build_types") not build_type in allowed result := lib.result_helper(rego.metadata.chain(), [build_type]) } # Plus upstream rules for: builder identity, source materials, external params ``` **Same checks. Different engine.** Attestation formats follow open standards (in-toto / SLSA), so engines are substitutable. ??? Andrew's "me too." The Conforma policy does the same checks in Rego. Two custom rules: provenance must exist, build type must be in the allowed list. The allowed list is configurable — not hardcoded to any build system. Upstream rules handle builder identity, source materials, and external parameters. About 30 seconds. --- ## 🌶 Mild: Run Conforma ```shell ./1-mild/conforma/verify.sh ``` ```shell === Mild: Verifying base image === Image: registry.access.redhat.com/ubi10/ubi-minimal:latest --- Step 1: Verify release signature Key: 1-mild/conforma/cosign-release.pub Success: true Result: SUCCESS Violations: 0, Warnings: 0, Successes: 15 [...] --- Step 2: Verify provenance Policy: 1-mild/conforma/policy.yaml Key: 1-mild/conforma/cosign-provenance.pub Success: true Result: SUCCESS Violations: 0, Warnings: 0, Successes: 50 [...] === Output files === output/mild/conforma/signature-report.json — image signature verification result output/mild/conforma/provenance-report.json — SLSA provenance policy evaluation ``` ??? Walk through the transcript: two `ec validate` passes (release key, then policy + provenance key), multi-arch index components, JSON reports under `output/mild/conforma/`. This is literal sample output from `mild-to-wild-samples` on a recent run. --- ## "But What About Multiple Attestations — and a Portable Summary?" ??? Puerco raises the bar. Medium does two things: combine multiple attestations (e.g. built image + base image) and verify them together, and produce a VSA so downstream consumers don't have to re-fetch and re-verify every attestation — they check the one summary. This is the transition to medium — Puerco leads with AMPEL. --- class: center, middle, medium

🌶🌶 Medium