kas-build-attestation - working with SLSA / in-toto attestations

       Daniel Wagner, Jan Kiszka, Claudius Heine

       kas  supports  the  generation  of  SLSA  /  in-toto  build attestation data.  Currently, support for the
       following attestation formats is implemented:

       • provenancev1Provenance
       The provenance data provides information about the build. This includes data about the build environment,
       as  well  as  all   primary   (first-level)   dependencies.   The   attestation   will   be   stored   in
       attestation/kas-build.provenance.json

       The  following  modes  are  supported:  mode=min,  mode=max,  whereby  the  mode  controls  the amount of
       information that is included in the attestation. The CLI options hereby loosely follow the dockerbuildx
       provenance options, which are described in detail in Provenanceattestations.  For compatibility with the
       dockerbuildx  CLI  options,  we  also  support  --provenancetrue, which is equivalent to --provenancemode=min.

       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.

       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

   Workingwithsigstorecosign
       The  cosigntool  from  the  sigstoreproject  (documentation)  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).  By  that,  the  predicate  first needs to be extracted (provenance in this
       example):

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

   AttestationSigningWARNING:
          The following command operates on the public append-only transparency log. Make sure to understand the
          implications before executing.

       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.

   AttestationVerification
       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

   AttestationRestoration
       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

       Siemens AG, 2017-2024

4.7                                               Feb 03, 2025                          KAS-BUILD-ATTESTATION(1)

       Part of the kas(1) suite.

       kas-build-attestation - working with SLSA / in-toto attestations