Add SBOM generation workflow

Author: Boyeep

.github/workflows/sbom.yml

@@ -0,0 +1,69 @@
+name: SBOM
+
+on:
+  push:
+    branches:
+      - main
+  schedule:
+    - cron: "24 3 * * 3"
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+jobs:
+  source-sbom:
+    name: Source SBOM
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Generate repository source SBOM
+        uses: anchore/sbom-action@v0.20.9
+        with:
+          path: .
+          format: spdx-json
+          artifact-name: repo-source.spdx.json
+          syft-version: v1.41.2
+          upload-release-assets: false
+
+  image-sbom:
+    name: Image SBOM (${{ matrix.name }})
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          - name: backend
+            context: ./backend
+            dockerfile: ./backend/Dockerfile
+            target: runner
+            image: cv-kit-backend:sbom
+            artifact: backend-runner.spdx.json
+          - name: frontend
+            context: ./frontend
+            dockerfile: ./frontend/Dockerfile
+            target: runner
+            image: cv-kit-frontend:sbom
+            artifact: frontend-runner.spdx.json
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Build runner image
+        run: >
+          docker build
+          --file ${{ matrix.dockerfile }}
+          --target ${{ matrix.target }}
+          --tag ${{ matrix.image }}
+          ${{ matrix.context }}
+
+      - name: Generate image SBOM
+        uses: anchore/sbom-action@v0.20.9
+        with:
+          image: ${{ matrix.image }}
+          format: spdx-json
+          artifact-name: ${{ matrix.artifact }}
+          syft-version: v1.41.2
+          upload-release-assets: false

README.md

@@ -129,6 +129,8 @@ A separate GitHub workflow generates license-report artifacts for the root works
 
 The dependency-review config also keeps a conservative allowlist of licenses already present in the current dependency tree, so tightening policy does not start by breaking routine updates.
 
+An SBOM workflow also publishes SPDX artifacts for the repository source plus the frontend and backend runner images.
+
 ## Releases
 
 - Release Drafter keeps a draft release updated from merged pull requests on `main` and can auto-label incoming pull requests by path.

SECURITY.md

@@ -33,6 +33,7 @@ The repository also uses automated scanning to help catch common security issues
 - CodeQL code scanning on GitHub for JavaScript/TypeScript, Python, and workflow files
 - 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
 
 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

@@ -23,6 +23,7 @@ The template-grade layer is the part worth reusing almost anywhere:
 - release automation
 - security scanning
 - license reporting
+- SBOM generation
 - repo governance
 - image/build verification
 - smoke testing after release
@@ -219,13 +220,15 @@ Files:
 - `.github/workflows/template-ci.yml`
 - `.github/workflows/codeql.yml`
 - `.github/workflows/license-report.yml`
+- `.github/workflows/sbom.yml`
 - `SECURITY.md`
 
 What it covers here:
 
 - tracked git content scanned with `gitleaks`
 - CodeQL scanning for JavaScript/TypeScript, Python, and workflow files
 - generated license inventories for npm and Python dependencies
+- SBOM artifacts for source and runner images
 - private disclosure guidance
 
 Why it matters:
@@ -239,6 +242,7 @@ Generic takeaway:
 - secret scanning is a near-default for public repos
 - CodeQL or equivalent static analysis is a strong baseline for maintained starters
 - non-blocking license reporting is a good bridge before stricter allowlist enforcement
+- SBOM generation is a strong supply-chain visibility layer for deployable templates
 
 ### 9. Workflow Linting
 

template-playbook.md

@@ -41,6 +41,7 @@ If a template only has code and no repo workflow, it is usually still a prototyp
 - workflow lint
 - secret scan
 - dependency review on pull requests
+- SBOM generation for source or publishable artifacts when relevant
 - app verification
 - cross-platform check if relevant
 - packaging or Docker build check if relevant
@@ -82,6 +83,7 @@ soon.md
 .github/workflows/release-drafter.yml
 .github/workflows/release.yml
 .github/workflows/release-smoke.yml
+.github/workflows/sbom.yml
 .github/workflows/sync-labels.yml
 .github/workflows/codeql.yml
 scripts/dev.mjs
@@ -156,6 +158,7 @@ If you want the version that scales better for open source or long-term reuse, a
 - secrets should be scanned
 - 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
 - release steps should be automated
 - docs should explain maintainer flow, not just user setup