Add release provenance attestations

Author: Boyeep

.github/workflows/release.yml

@@ -6,8 +6,7 @@ on:
       - "v*.*.*"
 
 permissions:
-  contents: write
-  packages: write
+  contents: read
 
 jobs:
   verify:
@@ -55,6 +54,15 @@ jobs:
     name: Publish GHCR Images
     needs: verify
     runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      packages: write
+      id-token: write
+      attestations: write
+      artifact-metadata: write
+    outputs:
+      backend-attestation-url: ${{ steps.attest-backend.outputs.attestation-url }}
+      frontend-attestation-url: ${{ steps.attest-frontend.outputs.attestation-url }}
     steps:
       - name: Checkout
         uses: actions/checkout@v4
@@ -97,6 +105,7 @@ jobs:
             type=semver,pattern={{major}}
 
       - name: Build and push backend image
+        id: push-backend
         uses: docker/build-push-action@v6
         with:
           context: ./backend
@@ -108,7 +117,16 @@ jobs:
           cache-from: type=gha
           cache-to: type=gha,mode=max
 
+      - name: Generate backend provenance attestation
+        id: attest-backend
+        uses: actions/attest@v4
+        with:
+          subject-name: ghcr.io/${{ steps.vars.outputs.owner }}/nextjs-python-computer-vision-kit-backend
+          subject-digest: ${{ steps.push-backend.outputs.digest }}
+          push-to-registry: true
+
       - name: Build and push frontend image
+        id: push-frontend
         uses: docker/build-push-action@v6
         with:
           context: ./frontend
@@ -120,10 +138,20 @@ jobs:
           cache-from: type=gha
           cache-to: type=gha,mode=max
 
+      - name: Generate frontend provenance attestation
+        id: attest-frontend
+        uses: actions/attest@v4
+        with:
+          subject-name: ghcr.io/${{ steps.vars.outputs.owner }}/nextjs-python-computer-vision-kit-frontend
+          subject-digest: ${{ steps.push-frontend.outputs.digest }}
+          push-to-registry: true
+
   github-release:
     name: Publish GitHub Release
     needs: publish-images
     runs-on: ubuntu-latest
+    permissions:
+      contents: write
     steps:
       - name: Set lowercase owner
         id: vars
@@ -140,3 +168,8 @@ jobs:
 
             - `ghcr.io/${{ steps.vars.outputs.owner }}/nextjs-python-computer-vision-kit-backend:${{ github.ref_name }}`
             - `ghcr.io/${{ steps.vars.outputs.owner }}/nextjs-python-computer-vision-kit-frontend:${{ github.ref_name }}`
+
+            ## Provenance Attestations
+
+            - Backend image: ${{ needs.publish-images.outputs.backend-attestation-url }}
+            - Frontend image: ${{ needs.publish-images.outputs.frontend-attestation-url }}

CONTRIBUTING.md

@@ -133,6 +133,8 @@ If you modify request or response shapes:
 5. Wait for the release workflow to verify the repo, publish GHCR images, and create the GitHub Release.
 6. Confirm the release smoke workflow passes against the published images, or dispatch it manually for a tag if you need to re-check a release.
 
+The release notes will also include links to the image provenance attestations generated during the publish workflow.
+
 The component labels used by Release Drafter are synced from `.github/labels.json`, and most of the common ones are applied automatically from changed paths.
 
 To run the same image smoke check locally, set `BACKEND_IMAGE` and `FRONTEND_IMAGE`, then run `npm run check:release-smoke`.

README.md

@@ -138,6 +138,7 @@ An SBOM workflow also publishes SPDX artifacts for the repository source plus th
 - Release Drafter defaults to a patch bump unless a maintainer applies `minor` or `major` to the pull request.
 - Pushing a tag like `v0.1.0` triggers the release workflow.
 - That workflow verifies the tagged commit, publishes backend/frontend images to GHCR, and creates a GitHub Release with generated notes.
+- The release workflow also generates build-provenance attestations for the published GHCR images and links them from the release notes.
 - A follow-up smoke workflow pulls those published GHCR images and checks backend health, a real inference request, and the frontend shell before you treat the release as healthy.
 - Maintainers can re-run the same check manually with `BACKEND_IMAGE=... FRONTEND_IMAGE=... npm run check:release-smoke`.
 

SECURITY.md

@@ -34,6 +34,7 @@ The repository also uses automated scanning to help catch common security issues
 - GitHub dependency review on pull requests for newly introduced vulnerable dependency changes
 - GitHub license-report artifacts for npm and Python dependency inventories
 - GitHub SBOM artifacts for the repository source and runner images
+- GitHub build-provenance attestations for published release images
 
 Dependency review is also configured with an allowlist that matches the current dependency tree, so changes that introduce new license types are surfaced deliberately instead of silently drifting in.
 

future-reference-feature.md

@@ -24,6 +24,7 @@ The template-grade layer is the part worth reusing almost anywhere:
 - security scanning
 - license reporting
 - SBOM generation
+- provenance attestations
 - repo governance
 - image/build verification
 - smoke testing after release
@@ -175,6 +176,7 @@ What it covers here:
 - semver bump guidance through labels
 - tag-triggered release workflow
 - GHCR publishing
+- build-provenance attestations for published container images
 - release smoke test against published images
 - synced repository labels
 
@@ -189,6 +191,7 @@ Generic takeaway:
 
 - if the repo is public and meant to last, release automation is worth it
 - release smoke tests are especially valuable because they test the thing users actually consume
+- provenance attestations strengthen trust in published artifacts without requiring manual signing steps
 
 ### 7. Repo Governance and Maintainer UX
 

template-playbook.md

@@ -52,6 +52,7 @@ If a template only has code and no repo workflow, it is usually still a prototyp
 - semver labels
 - label sync
 - publish workflow
+- provenance attestations for published artifacts when possible
 - release smoke test
 
 ### Repo Governance
@@ -159,6 +160,7 @@ If you want the version that scales better for open source or long-term reuse, a
 - dependency changes should be reviewed on pull requests
 - dependency licenses should be reportable without manual digging
 - SBOMs should be generated for source trees or release artifacts when supply-chain visibility matters
+- published artifacts should have provenance attestations when the platform supports them
 - release steps should be automated
 - docs should explain maintainer flow, not just user setup