This repository contains a number of different workflows demonstrating how to build applications using in-toto and in-toto related tools. Please see the in-toto Attestation Framework specification for more information.
The following workflows are designed to use Github Actions.
The Attestation Framework can be used to define signed attestations of what occurred in the execution of a software supply chain. These attestations can be inspected and analyzed to assist with ensuring the integrity of a software supply chain. It's assumed that the workflow owners that generate in-toto attestations are trusted. Additional controls, such as code reviews should be implemented to further ensure integrity. In addition, it's possible for workflows to be owned by different "functionaries" ensuring a true form of separation of duties. Note that attestations can be manipulated and then signed by the creating workflow, so additional controls and design are required to ensure integrity.
Github supports the creation of in-toto Attestations using Fulcio for signing and Rekor for storage. Both tools are part of the Sigstore project. A Fulcio certificate is a short lived certificate which will include the Github OIDC within the chain. Additional information within the certificate can be inspected, including the workflow information.
To inspect the certificate, download an example attestation, write the certificate to a new file (ensuring to include -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- formatting), and run the following:
openssl x509 -in cert.pem -textAgain, the assumption is that the workflow is semi trusted. For example, a build workflow could checkout a different git sha, however the attestation would show the sha for the executed commit and not the cloned commit within the resolved dependencies.
Through the use of OIDC, short lived certificates, and reusable workflows it's possible to have strong guarantees of the integrity of a software artifact.
gh-complete is a workflow designed as the primary orchestrating workflow. This workflow leverages other workflows such as; build, scan, release, etc.
This workflow could be owned by an engineering team seeking to build and release their software.
gh-build is an example of a Github Reusable Workflow for building a containerized application with Docker.
This workflow is designed to build and push a container image to ghcr, and generate an in-toto Provenance Attestation which is then attached to the callers repository.
This workflow could be owned by a build engineering team.
gh-scan is for running container or other security scans. Trivy is used for this usecase.
This workflow could be owned by a security team.