Draft: SLSA Workflow POC

What does this MR do and why?

This POC is an attempt to show how the publish and verify workflows described in https://gitlab.com/gitlab-org/gitlab/-/issues/553213+ could work. External service calls have been mocked to simplify the example.

How this POC works

1. A project has a build job with the variable MAKE_SLSA=true and produces an artifact. For example (from the demo project:

   build:
     stage: build
     variables:
       MAKE_SLSA: true
     id_tokens:
       SIGSTORE_ID_TOKEN:
         aud: sigstore    
     script:
       - bundle install
       - gem build -o mygem.gem mygem.gemspec
     artifacts:
       name: "mygem.gem"
       paths:
         - mygem.gem

2. After the build succeeds, Ci::Build#generate_attestation! is called which will:

   1. Generate the provenance statement
   2. Pass the provenance statment, artifact digest, and id_token to generate_and_sign_attestation which will make a request to glgo and return signed attestations for the given inputs in the format of a Sigstore Bundle. In the case of this POC, the request to glgo has been mocked to limit the complexity of this example.
   3. The signed attestations is then persisted to the ci_slsa_attestations table in the database along with relevant metadata.

3. With the attestation persisted in the database, it can then be made available via an API, which will effectively "publish" it to a known location. The attestation is indexed by the sha256 digest of the build artifact so that anyone in posession of the build artifact is able to find and verify the attestation. For example: http://gdk.test:3443/api/v4/projects/20/attestations/92a1d880d1f45d93020d5796e44ee413f1705f23081770e6e7b2cb0794873879

4. With all of this in place, a consumer is then able to verify a build artifact with the following commands:

   curl -X GET "http://gdk.test:3443/api/v4/projects/20/attestations/$(shasum -a 256 $GEM_NAME | cut -d' ' -f1)" > bundle.json
   wget http://localhost:8082/trusted-root.json
   cosign verify-blob-attestation --new-bundle-format --trusted-root trusted-root.json --bundle bundle.json --rekor-url "http://localhost:3000" --certificate-oidc-issuer $CI_SERVER_URL --certificate-identity https://gdk.test:3443/${CI_PROJECT_PATH}//.gitlab-ci.yml@refs/heads/${CI_COMMIT_BRANCH} $GEM_NAME

References

Screenshots or screen recordings

Before	After

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.