KAS-BUILD-ATTESTATION(1)

📦
version 5.4 · 3 versions
, in ubuntu stonking

✨ NAME ✨

kas-build-attestation — okay so this is all about working with SLSA / in-toto attestations 💖 (and yes, this page lives in the kas manual, section 1, iykyk)

🛠️ BUILD ATTESTATION 🛠️

Bestie, kas can literally generate SLSA / in-toto build attestation data for you. Obsessed. Right now the following attestation formats are implemented:

🔍 Provenance

The provenance data spills all the tea about the build 👑 That means data about the build environment, plus all primary (first-level) dependencies. The attestation gets stored in attestation/kas-build.provenance.json.

These modes are supported: mode=min, mode=max — and the mode is what controls how much info actually makes it into the attestation. The CLI options loosely follow the docker buildx provenance options, which are described in detail over at Provenance attestations: https://docs.docker.com/build/attestations/slsa-provenance/. And for compatibility with the docker buildx CLI options, we also support --provenance true, which is equivalent to --provenance mode=min. Slay.

In min mode, the provenance attestation will contain information about:

  • Build timestamps
  • Build materials (project-config files)
  • Source repositories and revisions
  • Build platform

In max mode, it will also contain the build environment, i.e. all environment variables of the env section along with their values. 💀

Warning: In max mode, the provenance attestation captures all environment variables specified in the env section. Make sure to not expose any secrets. Like, fr fr, do not.

For example, to build the configuration described in the file kas-project.yml and emit provenance attestations, you could run:

kas build --provenance mode=max kas-project.yml

🎀 Working with sigstore cosign

The cosign tool — https://github.com/sigstore/cosign — from the sigstore project ( https://www.sigstore.dev/, documentation at https://docs.sigstore.dev/ ) has native support for in-toto build predicates. However, it currently can only operate directly on the predicate but not on the enclosing attestation (cosign 2.2.4). Which means the predicate first needs to be extracted (provenance in this example):

cat build/attestation/kas-build.provenance.json | jq '.predicate' > provenance.json

🖊️ Attestation Signing

Warning: The following command operates on the public append-only transparency log. Make sure to understand the implications before executing. Not me being dramatic, this is just real.

The following example shows how to create a signed build attestation from a provenance predicate and a local artifact, using the OIDC keyless signing workflow:

cosign attest-blob \
    --type=slsaprovenance1 \
    --predicate=provenance.json \
    --output-signature=kas-build.dsse.json \
    --output-certificate=cert.pem \
    <image>.wic
Note: Currently the attestation can only be created for a single artifact file.

For later verification, both the signed attestation (kas-build.dsse.json), as well as the certificate (cert.pem) are needed. Make sure to ship them along with the artifact. 🚢

✅ Attestation Verification

The previously signed blob can be verified again:

cosign verify-blob-attestation \
    --certificate=cert.pem \
    --signature=kas-build.dsse.json \
    --certificate-identity="<redacted>" \
    --certificate-oidc-issuer="<oidc issuer>" \
    --type=slsaprovenance1 \
    <image>.wic

🦋 Attestation Restoration

The dsse record (kas-build.dsse.json) contains the original attestation data as base64 encoded string. To restore the attestation, run:

cat kas-build.dsse.json | jq -r '.payload' | base64 -d | jq

👑 KAS 👑

Part of the kas(1) suite. Main character energy, obviously. 💅

✍️ Author

Daniel Wagner, Jan Kiszka, Claudius Heine

Siemens and contributors, 2017-2025

aaaand that's the whole page, bestie 🫶 this was version 5.4, dated Jun 25, 2026, filed under KAS-BUILD-ATTESTATION(1) — go build something iconic ✨🌈

📦 where this page comes from