feat(ci): harden the supply chain and build the server once

.github/workflows/ci-security-scan.yml

@@ -1,10 +1,5 @@
 name: Security
 
-# CodeQL SAST scanning is handled by GitHub's Default Setup (enabled in repo settings).
-# This provides automatic scanning on push/PR with incremental analysis and zero maintenance.
-# This workflow handles dependency scanning (Trivy), secret detection (TruffleHog), and
-# a freshness check on the RFC 9116 security.txt Expires field.
-
 on:
   workflow_call:
     inputs:
@@ -15,6 +10,24 @@ on:
         default: "false"
 
 jobs:
+  dependency-review:
+    name: "New dependency risk"
+    runs-on: ubuntu-latest
+    if: inputs.should_skip != 'true' && github.event_name == 'pull_request'
+    timeout-minutes: 5
+    permissions:
+      contents: read
+    steps:
+      - name: Review dependency changes
+        uses: actions/dependency-review-action@a1d282b36b6f3519aa1f3fc636f609c47dddb294 # v5.0.0
+        with:
+          fail-on-severity: high
+          # CI tooling is part of the release trust boundary.
+          fail-on-scopes: runtime, development, unknown
+          license-check: true
+          show-patched-versions: true
+          vulnerability-check: true
+
   security-scan:
     name: "Dependencies, secrets, and policy"
     runs-on: ubuntu-latest

.github/workflows/rescan-main-images.yml

@@ -1,20 +1,7 @@
-# Rescans the images built from main's HEAD against the release vulnerability policy.
-#
-# The gate in reusable-docker-build.yml runs where an image is built, so it catches a change that
-# introduces a finding and cannot catch a finding that appears with no change at all. That is the
-# common case: v0.75.0 was blocked by CVEs published after the code merged clean, and nothing
-# noticed until the release failed. rescan-release-images.yml already covers published releases on
-# this cadence; this covers what main would release today.
-#
-# Non-blocking by design. Findings go to a tracking issue, updated in place, because a red status on
-# a schedule nobody triggered — for a regression no commit caused and no revert fixes — is how a team
-# learns to ignore the gate.
 name: Rescan main images
 
 on:
   schedule:
-    # Weekly, twenty minutes after the supported-release rescan, so the two never contend for the
-    # Trivy database. Monday also puts findings in front of the same review Renovate's PRs land for.
     - cron: "37 4 * * 1"
   workflow_dispatch:
 
@@ -57,15 +44,11 @@ jobs:
           username: ${{ github.actor }}
           password: ${{ secrets.GITHUB_TOKEN }}
 
-      # A day old at most: an older mirror would report last week's drift as this week's.
       - uses: ./.github/actions/download-trivy-db
         with:
           max-age-hours: "24"
           metadata-path: reports/trivy-db.json
 
-      # Resolves each image's `:main` tag to its linux/amd64 digest, scans it, and evaluates the one
-      # security/vulnerability-policy.json through the one scripts/check-release-vulnerabilities.ts.
-      # A finding does not fail this step; an unreachable registry or a broken scanner does.
       - name: Scan the images built from main
         env:
           TRIVY_USERNAME: ${{ github.actor }}

.github/workflows/reusable-docker-build.yml

@@ -443,14 +443,7 @@ jobs:
             > /dev/null
           gh attestation verify "oci://$IMAGE_REF" --owner "${{ github.repository_owner }}"
 
-  # The release vulnerability gate, run where the image is built. Until this job existed the
-  # policy's first execution was at `tag-images`, so a release was the first thing it could
-  # fail — a tripwire, not a safety net (issue #1703). It calls the same script and the same
-  # security/vulnerability-policy.json the release and the scheduled rescan call; a second
-  # copy of the policy is precisely the failure this prevents.
-  #
-  # linux/amd64 only: Alpine and Debian ship the same package versions across architectures,
-  # and the release still scans both, where the evidence bundle has to be complete.
+  # Scan one platform before merge; release evidence scans every published platform.
   scan:
     name: Scan linux/amd64 Image
     needs: [build, merge]
@@ -489,13 +482,10 @@ jobs:
       - name: Resolve the linux/amd64 subject
         id: subject
         env:
-          # The run tag both build paths already publish; it names this run's image whether
-          # `build` pushed it directly or `merge` assembled an index from the per-arch pushes.
           IMAGE_REF: ${{ inputs.registry }}/${{ inputs.image-name }}:run-${{ github.run_id }}-${{ github.run_attempt }}
           INPUT_IMAGE_NAME: ${{ inputs.image-name }}
         run: |
           set -euo pipefail
-          # First, so the artifact below is still named after the image if the lookup fails.
           echo "image=${INPUT_IMAGE_NAME##*/}" >> "$GITHUB_OUTPUT"
           raw=$(docker buildx imagetools inspect "$IMAGE_REF" --raw)
           if jq -e 'has("manifests")' <<< "$raw" > /dev/null; then

.github/workflows/scorecard.yml

@@ -0,0 +1,51 @@
+name: OpenSSF Scorecard
+
+on:
+  branch_protection_rule:
+  schedule:
+    - cron: "23 4 * * 1"
+  push:
+    branches: ["main"]
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+permissions: read-all
+
+jobs:
+  analysis:
+    name: Supply-chain posture
+    runs-on: ubuntu-latest
+    # OpenSSF publishing is limited to the default branch.
+    if: github.event.repository.default_branch == github.ref_name
+    timeout-minutes: 10
+    permissions:
+      contents: read
+      id-token: write
+      security-events: write
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+        with:
+          persist-credentials: false
+
+      - name: Run OpenSSF Scorecard
+        uses: ossf/scorecard-action@2d1146689b8cda280b9bc96326124645441f03bc # v2.4.4
+        with:
+          results_file: results.sarif
+          results_format: sarif
+          publish_results: true
+
+      - name: Upload findings to code scanning
+        uses: github/codeql-action/upload-sarif@cdf488f595d80d6e07e03d4674febd5ab45fa938 # v4.37.9
+        with:
+          sarif_file: results.sarif
+
+      - name: Preserve the assessment
+        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
+        with:
+          name: openssf-scorecard-${{ github.sha }}
+          path: results.sarif
+          if-no-files-found: error
+          retention-days: 14

docs/contributor/ci-cd.mdx

@@ -71,75 +71,36 @@ workflows run again for the merge group, which includes the current base and que
 the pull request. Each required context is bound to the GitHub Actions integration rather than
 accepting a same-named external status.
 
-Review is a *native* requirement, not a status check: the `main` ruleset sets
-`required_approving_review_count: 1` with `dismiss_stale_reviews_on_push`, so a pull request without
-a current approval sits in GitHub's own **Review required** state. That state blocks the merge
-button, blocks entry to the merge queue, and holds an armed auto-merge — and the checks list on a
-healthy pull request stays fully green, because waiting for a reviewer is no longer expressed as a
-yellow check.
-
-The review requirement is not waived for anyone. It is *satisfied* automatically for the authors
-listed in the comma-separated repository variable `REVIEW_POLICY_MAINTAINERS`:
-[`review-policy.yml`](https://github.com/ls1intum/Hephaestus/blob/main/.github/workflows/review-policy.yml)
-submits an approving review with `GITHUB_TOKEN`, attributed to `github-actions[bot]`, which counts
-toward the required count. Every other author waits for a human with write access. Repository
-administrators own the allow-list.
-
-Be honest about what that is: auto-approval encodes exactly the policy the old custom
-`review-policy` check encoded — *a listed maintainer may merge their own work* — and it exists only
-because the repository has a single write-access collaborator, so there is nobody else to ask. It is
-not a review. **The moment a second write-access reviewer exists, delete the workflow and the
-`REVIEW_POLICY_MAINTAINERS` variable and let the native requirement stand on its own.** Nothing else
-has to change; the ruleset already asks for the approval.
-
-Two settings this depends on, both already in place: the organisation's *Allow GitHub Actions to
-create and approve pull requests*, which governs whether `GITHUB_TOKEN` may approve at all, and
-`dismiss_stale_reviews_on_push`, which is why the workflow runs on `synchronize` as well as
-`opened`, `reopened` and `ready_for_review` — every push has to earn a fresh approval. The approval
-is pinned to the head commit it was decided against, and a run that finds its own approval already
-standing on that commit submits nothing, so re-runs do not stack duplicate reviews.
-
-The workflow deliberately carries no `branches:` filter, and runs on `edited` too, because of
-stacked pull requests (`CONTRIBUTING.md` § Stacked Pull Requests). Merging a lower layer
-retargets the upper one onto `main`, and that retarget fires no event a base-filtered workflow would
-see — the layer would reach the merge queue unapproved and be refused entry. So every layer earns
-its approval while it still points at the layer below. An approval on a pull request targeting
-anything but `main` satisfies no rule and is inert.
-
-[`scripts/review-policy.ts`](https://github.com/ls1intum/Hephaestus/blob/main/scripts/review-policy.ts)
-holds the decision, and it reads the author login and nothing else — never the diff, the title or
-the body. That is what makes it safe under `pull_request_target` with `pull-requests: write`: the
-job checks out only `scripts` from the default branch, with `persist-credentials: false`, and runs
-no pull-request code. An empty or unset `REVIEW_POLICY_MAINTAINERS` approves nobody and warns, which
-leaves every pull request needing a human — the safe direction.
+Review is a native ruleset requirement with stale approvals dismissed on every push. Authors listed
+in `REVIEW_POLICY_MAINTAINERS` receive an automated approval; every other author needs a human with
+write access. Repository administrators own that allow-list. Remove the automation when independent
+maintainer review is available.
+
+The approval workflow evaluates only the author login using code checked out from the default branch.
+It runs no pull-request code and approves nobody when the allow-list is empty. Its event set also covers
+stacked pull requests before they are retargeted to `main`.
 
 The changesets Version PR is the temporary exception: updates made with `GITHUB_TOKEN` do not trigger
 the required workflows, so release automation uses the ruleset bypass. The resulting version bump
 runs source validation on `main` before release; other pushes build final-SHA images without repeating
 source validation.
 
-## 🔒 Security
-
-- **CodeQL** – SAST scanning via GitHub's Default Setup (automatic, zero maintenance)
-- **Trivy** – Scans dependencies for CVEs
-- **TruffleHog** – Secret detection in code and history
-- **Renovate** – Monitors dependencies for vulnerabilities
-- **Environment protection** – Production requires approval
-
-What a Trivy image finding has to be before it blocks, and what an exception has to contain, is in
-[Vulnerability remediation](./vulnerability-remediation.mdx).
-
-### CodeQL Default Setup
-
-CodeQL runs automatically via GitHub's Default Setup (enabled in repository settings), providing:
-
-- Scans on every push to main and protected branches
-- Scans on pull request creation and updates
-- Weekly scheduled scans for the full codebase
-- Incremental analysis (20% faster on PRs)
-- Zero maintenance – GitHub manages query updates
-
-This is more efficient than a custom workflow and doesn't consume CI minutes.
+## 🔒 Security and supply-chain controls
+
+| Control | Timing | Enforcement | Destination |
+| --- | --- | --- | --- |
+| GitHub dependency review | pull requests | blocks new high or critical findings in runtime, development, and unknown scopes | required Security workflow |
+| CodeQL default setup | managed by GitHub | repository SAST policy | code scanning |
+| TruffleHog and GitHub push protection | pull requests and pushes | block verified secrets | Security workflow and repository protection |
+| Trivy filesystem scan | CI | scanner failure blocks; findings publish | code scanning and Security workflow |
+| Image vulnerability policy | image build and release | blocks fixable high or critical findings | build summary and release evidence |
+| Scheduled image rescans | weekly | findings update the tracking issue; scanner failure fails the run | vulnerability response issue |
+| OpenSSF Scorecard | `main`, branch-protection changes, and weekly | posture findings do not extend the pull-request critical path | code scanning and run artifact |
+| Renovate | configured schedule and vulnerability alerts | pull requests require normal review and CI | dependency dashboard |
+
+[Vulnerability remediation](./vulnerability-remediation.mdx) owns the blocking and exception policy.
+[Release management](./release-management.mdx#supply-chain-evidence) owns artifact signing, provenance,
+SBOM, and release-verification guarantees.
 
 ## 📦 Environments
 

docs/contributor/release-management.mdx

@@ -114,41 +114,8 @@ Compose topology. They receive the same per-platform SBOM, license, vulnerabilit
 evidence as first-party images. Hephaestus requires its own signatures and build provenance only for
 images it builds; it does not misrepresent observed upstream images as Hephaestus-built artifacts.
 
-The version-controlled policy rejects every HIGH or CRITICAL finding **for which upstream has published
-a fix**. An unfixable finding is still counted and still appears in the signed evidence, but it does not
-block: the pinned upstream images cannot be patched at all, so failing on one removes no risk and leaves
-nobody an action. A residual fixable finding requires an exception scoped to its image, platform,
-vulnerability, package, and installed version, with an owner, justification, evidence URL, and expiry no
-more than 90 days away. Each exception and policy report records the scanned digest, but an exception is
-not matched on it — the release digest does not exist until the images are tagged, so a digest-keyed
-exception could only ever be written after the gate had already failed a release.
-
-The same policy runs on every image build, against the `linux/amd64` image the run just pushed, so a
-pull request fails before a release can. The release scans both architectures, where the evidence bundle
-has to be complete. Both call `scripts/check-release-vulnerabilities.ts` with
-`security/vulnerability-policy.json`; there is no second copy of either. A failing gate names the
-rejected CVEs in the run summary and uploads its `.policy.json`.
-
-The latest release is rescanned weekly. A policy violation or scan failure is reported on
-[the vulnerability response issue](https://github.com/ls1intum/Hephaestus/issues/1369); scanner failure
-is never treated as no findings.
-
-`main`'s images are rescanned on the same weekly cadence, by `rescan-main-images.yml`. Container
-vulnerabilities are time-dependent, not commit-dependent: the build gate can only catch a finding some
-change introduced, and the finding that blocked v0.75.0 was published after the code had merged clean.
-The scheduled run resolves each image's `:main` tag to its `linux/amd64` digest and evaluates the same
-policy through the same script, so nothing about the verdict differs from a release.
-
-That run is **not** blocking, and no scheduled run should be. Nobody triggered it, no commit caused the
-finding and no revert removes it — the remedy is to rebuild `main` against a patched base image, which
-the next merge does anyway. So `scripts/report-vulnerability-drift.ts` keeps a single tracking issue in
-step with the findings instead: opened when they appear, edited in place and commented when the set
-changes, silent when it has not, and closed when it clears. It recognises its own issue by an HTML
-marker on the first line of the body, not by the title, so the issue can be retitled and triaged freely;
-delete that line and the next run opens a new one.
-
-[Vulnerability remediation](./vulnerability-remediation.mdx) states the policy in full — what an
-exception must contain, and why VEX is not adopted.
+[Vulnerability remediation](./vulnerability-remediation.mdx) is the normative policy for blocking
+findings, scheduled rescans, and exceptions.
 
 ## Browser source maps
 
@@ -208,7 +175,7 @@ The whole app is versioned as one product: changesets target the root `hephaestu
 
 | Environment | Trigger | Approval | URL |
 | --- | --- | --- | --- |
-| Staging | Green commit on `main` | None (auto) | https://staging.hephaestus.aet.cit.tum.de |
+| Staging | Verified signed release | None (auto) | https://staging.hephaestus.aet.cit.tum.de |
 | Production | Release cut | Required reviewer | https://hephaestus.aet.cit.tum.de |
 | PR previews | `preview` label on a same-repo PR | None (push access) | PR deployment link |
 

docs/contributor/vulnerability-remediation.mdx

@@ -21,18 +21,8 @@ written down.
 A finding blocks when it is **HIGH or CRITICAL and upstream has published a fix** — Trivy reports a
 non-empty `FixedVersion`. MEDIUM and below never block, at any scan.
 
-The fixable/unfixable split is the part most easily read wrong, so plainly: **an unfixable HIGH is not
-an exception and does not need one.** Four of the images in `security/release-images.json` are upstream
-— alpine, nats, nginx, and traefik — and cannot be patched here at all, so failing on a finding that
-has no fix removes no risk and leaves nobody an action. The share is not marginal: when the gate was
-first measured against real images, `agent-pi` reported 59 HIGH/CRITICAL findings of which 1 was
-fixable, and `postgres` 99 of which 23 were.
-
-Gating on fix availability is the ordinary shape of this control. Google Binary Authorization exposes
-`maximumFixableSeverity` and `maximumUnfixableSeverity` as separate settings; Docker Scout's default
-policy is "no **fixable** critical or high vulnerabilities"; Snyk separates `--fail-on=upgradable` from
-`--severity-threshold`; Chainguard's remediation SLA starts when a patch exists rather than when the
-CVE is published.
+An unfixable HIGH is not an exception and does not need one. It remains recorded, but without a
+patched version there is no upgrade for the gate to require.
 
 Unfixable findings are still counted. The filter lives in the evaluator, not in a `--ignore-unfixed`
 flag on Trivy, so every HIGH and CRITICAL stays in the scan report and in the `highCritical` list of
@@ -92,12 +82,4 @@ A value outside those five is a malformed policy and throws. An `affected` excep
 category — it defers a risk we concede applies, and claiming non-exploitability at the same time is a
 contradiction.
 
-## VEX is not adopted
-
-The vocabulary above is all we take. [OpenVEX](https://github.com/openvex/spec) has been frozen at
-v0.2.0 since 2023-08-22, and Trivy's `--vex` still carries an EXPERIMENTAL banner and matches on
-digest-based PURLs that a locally built image does not have. `aquasecurity/vexhub`, Trivy's default VEX
-repository, stopped updating on 2026-03-23 and has no OS-distro coverage at all — no Alpine, no Debian,
-no nginx — and Alpine publishes no VEX itself, which is where most findings here originate. Adopting it
-would mean hand-authoring documents that duplicate `security/vulnerability-policy.json`, minus the
-expiry field OpenVEX does not define. Revisit if the distros start publishing.
+The policy uses CISA's justification vocabulary without requiring a separate VEX document.

package.json

@@ -139,7 +139,8 @@
 		"pg": "8.20.0",
 		"surge": "0.43.1",
 		"typescript": "7.0.2",
-		"vite-plus": "0.3.0"
+		"vite-plus": "0.3.0",
+		"yaml": "2.9.0"
 	},
 	"devEngines": {
 		"packageManager": {