Artifact attestations help boost your build's supply chain security by showing where and how your software was created.

In Github Actions we can acheive this using actions/attest-build-provenance

1. First add permission to your workflows / re-usable workflows with attestations: write

permissions:
  id-token: write
  contents: read
  attestations: write

(optional) with Maven Builds

need to specify the jar that would be generated during the maven build with exact path. in my case it is target/*.jar We can also add the name to attestation.

    - name: Build with Maven
      shell: bash
      run: mvn --batch-mode --update-snapshots -DskipTests package    

    - name: Attest Artifacts
      uses: actions/attest-build-provenance@v1.3.2
      with:
        subject-path: 'target/*.jar'
        subject-name: ${{ inputs.container-name }}-attestation

2. with Docker builds

Similarly, you can ensure that your Docker artifacts are properly attested, thereby enhancing the security and integrity of your build process. This approach helps in maintaining a robust supply chain security by providing verifiable evidence of how and where your Docker images were created.

    - name: Docker build-push
      id: docker-build
      uses: docker/build-push-action@v6
      with:
        context: .
        push: true
        tags: |
          ${{ inputs.acr-url }}/${{ inputs.container-name }}:latest
        # cache-from: type=registry,ref=${{ inputs.acr-url }}/${{ env.containerName }}:buildcache
        # cache-to: type=registry,ref=${{ inputs.acr-url }}/${{ env.containerName }}:buildcache,mode=max
        cache-from: type=gha
        cache-to: type=gha,mode=max   

    - name: Attest Docker build
      uses: actions/attest-build-provenance@v1.3.2
      id: attest
      with:
        subject-name: ${{ inputs.acr-url }}/${{ inputs.container-name }}
        subject-digest: ${{ steps.docker-build.outputs.digest }}
        push-to-registry: true

And by just Generating these attestations doesn’t boost security.

3. You need to verify them for it to actually make a difference. Here is an example how this can be verified

    - name: Verify OCI image
      shell: bash
      env:
        GH_TOKEN: ${{ inputs.github-token }}
      run: |
        gh attestation verify oci://${{ inputs.acr-url }}/${{ inputs.container-name }}:latest --owner "$GITHUB_REPOSITORY_OWNER"

You will see a detailed summary after the workflow execution is complete. it will show the status of the Docker build and push actions, indicating whether the image was successfully built and pushed to the specified container registry.

Additionally, it will include information about the attestation process, confirming whether the build provenance was properly attested and pushed to the registry.

Finally, the summary will display the results of the verification step, showing whether the OCI image was successfully verified using the provided GitHub token. This comprehensive summary helps ensure that each step of the workflow was executed correctly and provides valuable insights into the overall process.

By clicking on the Attestation URL, you will see detailed information.