Attest a specific version of a project and version
During the attestation process, you can provide the name of the project the workflow belongs to and, optionally, a version. You can read more here
Contract-less pieces of evidence
A Workflow Contract specifies the necessary content that a workflow must include in its attestation. For instance, it might mandate the inclusion of the URI@digest of the generated container image, the container root filesystem used during the build, and the Software Bill of Materials for that container image. These pieces of evidence must be associated with a specific material type. Operators define what must be included in the contracts, and developers need to understand and comply with these requirements.
This has been the case up until now, with the introduction of contract-less pieces of evidences and auto-discovery, we ease the job of operators and developers when working with attestations.
Not all pieces of evidences need to to be registered as a material on the contract, you can add as many pieces of evidences as you like by adding its value and a new flag --kind, which determines that type of material you’re attesting, example:
$ chainloop attestation init --workflow wf-test --project core
INF Attestation initialized! now you can check its status or add materials to it
┌───────────────────┬──────────────────────────────────────┐
│ Initialized At │ 21 May 24 07:23 UTC │
├───────────────────┼──────────────────────────────────────┤
│ Attestation ID │ 6e9d2e76-fdc0-4493-a344-4cf44a2b7bf2 │
│ Name │ wf-test │
│ Team │ founding │
│ Project │ core │
│ Contract Revision │ 3 │
└───────────────────┴──────────────────────────────────────┘
┌────────────────────────┐
│ Materials │
├───────────┬────────────┤
│ Name │ one-file │
│ Type │ ARTIFACT │
│ Set │ No │
│ Required │ Yes │
│ Is output │ Yes │
├───────────┼────────────┤
│ Name │ other-file │
│ Type │ EVIDENCE │
│ Set │ No │
│ Required │ Yes │
│ Is output │ Yes │
└───────────┴────────────┘
There are two expected materials of kind ARTIFACT and EVIDENCE. With the changes we can perform the following:
$ chainloop attestation add --value controlplane.cyclonedx.json --kind SBOM_CYCLONEDX_JSON
INF material added to attestation
We are explicitly saying which is the kind (SBOM_CYCLONEDX_JSON) we want to apply to material that is not found on the contract. After fulfilling the required materials, the ones stated on the contract, we can perform the attestation as usual:
$ chainloop attestation push
INF push completed
┌───────────────────┬──────────────────────────────────────┐
│ Initialized At │ 21 May 24 06:37 UTC │
├───────────────────┼──────────────────────────────────────┤
│ Attestation ID │ 57b8dc22-d84d-40c3-a04c-8948231b3134 │
│ Name │ wf-test │
│ Team │ founding │
│ Project │ core │
│ Contract Revision │ 3 │
└───────────────────┴──────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ Materials │
├───────────┬─────────────────────────────────────────────────────────────────────────┤
│ Name │ one-file │
│ Type │ ARTIFACT │
│ Set │ Yes │
│ Required │ Yes │
│ Is output │ Yes │
│ Value │ go.mod │
│ Digest │ sha256:29773f085c46a33efcb6cdb185f6ec30ce1c4ca708b860708cd055b70488ef4d │
├───────────┼─────────────────────────────────────────────────────────────────────────┤
│ Name │ other-file │
│ Type │ EVIDENCE │
│ Set │ Yes │
│ Required │ Yes │
│ Is output │ Yes │
│ Value │ LICENSE.md │
│ Digest │ sha256:c71d239df91726fc519c6eb72d318ec65820627232b2f796219e87dcf35d0ab4 │
├───────────┼─────────────────────────────────────────────────────────────────────────┤
│ Name │ material-1716273574284654000 │
│ Type │ SBOM_CYCLONEDX_JSON │
│ Set │ Yes │
│ Required │ No │
│ Is output │ Yes │
│ Value │ controlplane.cyclonedx.json │
│ Digest │ sha256:a6bc29d7a2d8d9f6df12a86ee4c86c58189d77bb6ded9487330c39f46ee00d9a │
└───────────┴─────────────────────────────────────────────────────────────────────────┘
Attestation Digest: sha256:61832d846b870d01647a384c3df49e3c75fd87f45821c9295d97ab91d5bae198
Auto-discovery of pieces of evidence
On top of contract-less pieces of evidence, we have introduced auto-discovery.
Auto-discovery it’s a way of inspecting the incoming piece of evidence and try to match it with at least of of the available type of materials of Chainloop. Please note this is a best effort, and the prediction might fail and match it with the wrong type of material, defaulting in ARTIFACT.
To let the auto-discovery work, don’t set the --kind flag during chainloop att add and the CLI will work it out for you.
Remote State
By default, the attestation process state is stored locally. But this setup is not suitable when running a multi-step attestation process in a stateless environment, like our Dagger module, or when you want to leverage CI multi-job parallelism or similar.
For that, we implemented an attestation remote state. Simply put, instead of the attestation CLI being in charge of maintaining the state during the attestation, this can be delegated to the server and retrieved at any time by providing an “attestation-id.”
# You can enable the feature by providing the --remote-state flag
# and it will return an attestation-id
$ chainloop attestation init --name my-workflow --project my-project --remote-state
# Then you can add any piece of evidence by providing the attestation-id
$ chainloop attestation add --value cyberdyne.cyclonedx.sbom --attestation-id deadbeef
# And finally craft the attestation, sign-it and push it
$ chainloop attestation push --attestation-id deadbeef
With this optional feature, as long as you have the attestation-id, you can add any piece of evidence to the attestation from anywhere.