GitHub Actions sind praktisch und genau deshalb gefährlich. Ein Workflow läuft mit Token, hat Zugriff aufs Repository und zieht oft fremden Code aus dem Marketplace, ohne dass jemand genau hinschaut. Wer eine Action per Tag einbindet, vertraut darauf, dass hinter diesem Tag morgen noch derselbe Code steckt. Das muss nicht so sein. Hier sind drei Stellschrauben, die ich in jedem Repository als Erstes anfasse.

Actions auf den Commit-SHA pinnen

Ein Tag wie @v4 ist ein beweglicher Zeiger. Der Maintainer kann ihn jederzeit auf einen neuen Commit umhängen, und ein kompromittiertes Maintainer-Konto kann das ebenfalls. Damit läuft beim nächsten Build fremder Code in deiner Pipeline, ohne dass sich in deinem Workflow eine Zeile geändert hat. Genau dieses Muster stand hinter mehreren Supply-Chain-Vorfällen der letzten Jahre.

Die Lösung ist simpel: Pinne auf den vollen Commit-SHA und schreibe die Version als Kommentar dahinter.

# unsicher, beweglicher Tag
- uses: actions/checkout@v4
# besser, fixer Commit-SHA mit Versionskommentar
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

Der SHA ist unveränderlich. Wird die Action aktualisiert, bekommst du das über einen Pull Request von Dependabot oder Renovate, kannst die Änderung lesen und bewusst zustimmen. Das gilt nicht nur für fremde Actions, sondern auch für die offiziellen von GitHub selbst.

Berechtigungen auf das Nötigste reduzieren

Standardmäßig bekommt das GITHUB_TOKEN in vielen Setups weitreichende Schreibrechte. Ein Workflow, der nur Tests laufen lässt, braucht aber keinen Schreibzugriff auf dein Repository. Setze die Berechtigungen explizit, am besten global auf read und nur dort hoch, wo ein Job wirklich schreiben muss.

permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
      - run: npm ci && npm test
  release:
    needs: test
    runs-on: ubuntu-latest
    permissions:
      contents: write   # nur dieser Job darf Tags und Releases schreiben
    steps:
      - run: echo "release"

Der Effekt: Selbst wenn ein Step kompromittierten Code ausführt, ist der mögliche Schaden auf das beschränkt, was dieser eine Job darf. Least privilege ist kein abstraktes Prinzip, sondern hier eine konkrete Zeile YAML.

OIDC statt Langzeit-Secrets

Der Klassiker beim Deployment in die Cloud sind statische Zugangsschlüssel, die als Secret im Repository liegen. Die liegen dort dauerhaft, lassen sich versehentlich loggen und rotieren in der Praxis selten. Besser ist ein kurzlebiges Token über OpenID Connect. GitHub stellt dem Workflow ein signiertes Identitätstoken aus, die Cloud prüft es und gibt im Gegenzug temporäre Zugangsdaten heraus. Kein langlebiges Secret mehr im Repository.

permissions:
  id-token: write   # erlaubt GitHub, ein OIDC-Token auszustellen
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502 # v4.0.2
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-deploy
          aws-region: eu-central-1
      - run: aws sts get-caller-identity

Auf der Cloud-Seite vertraut die Rolle nur Tokens aus genau deinem Repository und idealerweise nur einem bestimmten Branch. Damit kann ein Fork oder ein fremder Workflow die Rolle nicht übernehmen. Das Prinzip funktioniert genauso mit Azure und Google Cloud.

Was sonst noch in die Checkliste gehört

Diese drei Punkte sind die Basis, nicht das Ende. Sei vorsichtig mit pull_request_target, weil dieser Trigger mit den Rechten des Ziel-Repositories läuft und bei unbedachtem Checkout von Fork-Code ausnutzbar wird. Schränke in den Repository-Einstellungen ein, welche Actions überhaupt erlaubt sind. Und behandle den Inhalt von Pull Requests als das, was er ist: nicht vertrauenswürdige Eingabe.

Im Kern ist Pipeline-Sicherheit dieselbe Disziplin wie der Rest sicherer Softwarelieferung. Es geht um nachvollziehbare Herkunft, minimale Rechte und kurzlebige Geheimnisse. Wie sich dieser Gedanke über die Pipeline hinaus auf die ganze Lieferkette ziehen lässt, schreibe ich regelmäßig auf digital-business.blog. Wenn du nur drei Dinge aus diesem Beitrag mitnimmst: SHA pinnen, Rechte runter, Secrets raus.