Forgejo Pipelines · Workshop Lektion 12 / Sicherheit ★

Sicherheit: Fork-PRs & Token

Wo CI gefährlich wird – und wie Forgejo dich (und dein Repo) standardmässig schützt.

Warum das zählt
CI führt Code aus. Bei Pull Requests aus fremden Forks ist dieser Code nicht vertrauenswürdig. Wer hier nicht aufpasst, verschenkt Secrets oder Schreibrechte. Forgejo trifft bewusste Voreinstellungen – die musst du kennen, gerade als Workshop-Vermittler.

Fork-PRs laufen entschärft

Read-only Token, keine Secrets Ein Workflow, der durch einen pull_request aus einem Fork ausgelöst wird, bekommt einen nur-lesenden FORGEJO_TOKEN und keinen Zugriff auf Secrets. So kann eingeschleuster Code weder ins Repo schreiben noch Geheimnisse abgreifen. Das ist Forgejos Standardschutz – verlass dich darauf.

Die gefährliche Ausnahme: pull_request_target

on:
  pull_request_target:      # läuft im Kontext des ZIEL-Repos!
pull_request_target hat Secrets – und Risiko Dieses Event läuft im Kontext des Ziel-Branches und hat dadurch Secrets und mehr Rechte. Verlockend – aber wenn du darin ungeprüften Fork-Code auscheckst und ausführst, öffnest du genau das Loch, das pull_request schliesst. Regel: in pull_request_target niemals den PR-Branch bauen/ausführen, nur vertrauenswürdige, read-only Schritte (z. B. ein Label setzen).

Least Privilege beim Token

Der automatische Token sollte nur so viel dürfen wie nötig. Wo Forgejo es unterstützt, schränkst du Rechte explizit ein und gibst zusätzliche nur dort, wo sie gebraucht werden (z. B. ein eigenes PAT fürs Pushen von Images, Lektion 8 – nicht der Default-Token).

Faustregeln Secrets nie in Logs echoen. Deploy-Jobs nie aus Fork-PRs. Für Schreibzugriffe auf Pakete/Registry separate, eng gescopte Tokens. Actions per SHA pinnen (Lektion 6).

Parallelen: GitLab CI ↔ Forgejo Actions

GitLab CI

Fork-MRs: Secrets standardmässig geschützt

protected Variablen/Branches

Job-Token mit konfigurierbarem Scope

Forgejo Actions

Fork-PRs: read-only Token, keine Secrets ★

Riskante Ausnahme: pull_request_target

Eng gescopte PATs für Schreibzugriffe

Übungen für Teilnehmende

Übung 1 · Risiko erkennen

Frage: Ein Workflow nutzt pull_request_target und checkt den PR-Branch aus, um npm test zu fahren. Wo ist das Problem?

Lösung anzeigen

Fremder Fork-Code läuft mit Secrets/Schreibrechten des Ziel-Repos – ein klassisches Exfiltrations-Loch. Tests gehören in pull_request (entschärft), nicht in pull_request_target.

Übung 2 · Entscheiden

Frage: Du willst, dass externe Beitragende per PR die Tests auslösen, aber keine Secrets sehen. Welches Event nimmst du – und was passiert mit dem Deploy-Job?

Lösung anzeigen

pull_request. Der Deploy-Job läuft dort nicht sinnvoll (keine Secrets) – ihn gatest du auf push/main bzw. workflow_dispatch (Lektion 10).

Kurz prüfen (aus dem Kopf)

Was bekommt ein Workflow aus einem Fork-PR?

Worauf darfst du in pull_request_target verzichten?

Primärquelle zum Lesen Forgejo Docs – Reference (Fork-PR-Sicherheit, pull_request_target, Token-Verhalten).
Ich bin dein Teacher. Unsicher, ob ein Workflow Fork-sicher ist? Schick ihn mir – wir prüfen Trigger, Token und Secret-Zugriff gemeinsam.
← Lektion 11 · Reusable workflows Lektion 13 · Besonderheiten & Migration →