CI-Sicherheit: docker-host-Runner darf keinen Code aus Fork-PRs ausführen #43

New issue

Open

opened 2026-11-03 09:52:39 +00:00 by cschlaefke · 0 comments

cschlaefke commented

2026-11-03 09:52:39 +00:00

Owner

Problem

Die Jobs supabase-tests und e2e laufen auf dem Runner-Label docker-host mit Zugriff auf den dind-Daemon des Runners (Root-Äquivalent). Das Repo ist öffentlich. Bei on: pull_request stammt die Workflow-Datei aus dem PR-Head: ein Fork-PR kann Bedingungen wie if: head.repo.full_name == github.repository entfernen und beliebigen Code auf dem Runner ausführen. supabase-tests hat gar keinen Schutz.

Aufgefallen im Review von PR #42 (Refs #38, #1).

Zu tun

Forgejo-Einstellungen prüfen: Actions für Fork-PRs nur nach Freigabe durch Maintainer (Approval) bzw. deaktiviert
Runner-Label docker-host nur für vertrauenswürdige Events/Repos; Fork-PRs auf ein Label ohne Docker-Zugriff verweisen oder gar nicht ausführen
Alternativ Repo privat oder Fork-PRs generell sperren
Entscheidung in docs/ (ADR oder docs/auth-konfiguration.md) festhalten
Kommentare in ci.yml anpassen, sobald die echte Absicherung steht

Priorität

Sicherheit, vor dem ersten externen Beitrag bzw. spätestens vor Release.

## Problem Die Jobs `supabase-tests` und `e2e` laufen auf dem Runner-Label `docker-host` mit Zugriff auf den dind-Daemon des Runners (Root-Äquivalent). Das Repo ist öffentlich. Bei `on: pull_request` stammt die Workflow-Datei aus dem PR-Head: ein Fork-PR kann Bedingungen wie `if: head.repo.full_name == github.repository` entfernen und beliebigen Code auf dem Runner ausführen. `supabase-tests` hat gar keinen Schutz. Aufgefallen im Review von PR #42 (Refs #38, #1). ## Zu tun - [ ] Forgejo-Einstellungen prüfen: Actions für Fork-PRs nur nach Freigabe durch Maintainer (Approval) bzw. deaktiviert - [ ] Runner-Label `docker-host` nur für vertrauenswürdige Events/Repos; Fork-PRs auf ein Label ohne Docker-Zugriff verweisen oder gar nicht ausführen - [ ] Alternativ Repo privat oder Fork-PRs generell sperren - [ ] Entscheidung in `docs/` (ADR oder `docs/auth-konfiguration.md`) festhalten - [ ] Kommentare in `ci.yml` anpassen, sobald die echte Absicherung steht ## Priorität Sicherheit, vor dem ersten externen Beitrag bzw. spätestens vor Release.