Dein Blog zum Thema digitales Business

Der Moment, in dem eine Action Vertrauen bekommt

Du suchst im GitHub Marketplace nach einer Action, findest einen Treffer, der genau das tut, was du brauchst, und fügst die Zeile uses: irgendwer/irgendwas@v3 in deinen Workflow ein. Ab diesem Moment läuft fremder Code mit den Rechten deines Repositorys, oft inklusive Zugriff auf Secrets, GITHUB_TOKEN und alles, was der Workflow sonst berühren kann. Die Entscheidung, dieser Action zu vertrauen, ist in diesem Augenblick schon gefallen, meistens ohne dass sie bewusst getroffen wurde.

Genau hier setzt Vetting an: die Prüfung, bevor die Action zum ersten Mal läuft. Das ist ein anderer Schritt als das Pinnen auf einen bestimmten Commit, dazu gleich mehr. Vetting entscheidet, ob eine Action überhaupt in deine Pipeline gehört. Pinning entscheidet danach, wie du eine bereits akzeptierte Action stabil hältst.

Was passiert, wenn niemand vorher hinschaut

Wie real dieses Risiko ist, zeigt ein Fall, der öffentlich dokumentiert ist: Im März 2025 wurde die verbreitete Action tj-actions/changed-files kompromittiert. Die CISA-Sicherheitsbehörde bestätigte den Vorfall als Supply-Chain-Kompromittierung unter CVE-2025-30066 (Quelle: CISA-Advisory vom 18.03.2025, https://www.cisa.gov/news-events/alerts/2025/03/18/supply-chain-compromise-third-party-tj-actionschanged-files-cve-2025-30066-and-reviewdogaction). Nach eigenständigen Schätzungen der Sicherheitsfirmen Wiz und Orca waren mehr als 23.000 Repositories betroffen, die die Action zu diesem Zeitpunkt eingebunden hatten (Quellen: wiz.io/blog sowie orca.security/resources/blog, jeweils zu CVE-2025-30066).

Der Punkt für dieses Thema ist nicht die technische Angriffsmechanik, sondern die Reihenfolge: Zehntausende Teams hatten diese Action längst in Betrieb, bevor irgendjemand ihre Historie, ihre Maintainer-Struktur oder ihren Berechtigungsumfang geprüft hatte. Die Action war etabliert, weit verbreitet und genau deshalb ein attraktives Ziel. Vertrauen war über Verbreitung entstanden, nicht über Prüfung.

Maintainer-Historie: wer steht hinter dem Code

Bevor du eine Action zum ersten Mal einsetzt, lohnt sich ein Blick auf das Repository dahinter, nicht nur auf den Marketplace-Eintrag. Fragen, die sich in wenigen Minuten beantworten lassen: Steht die Action unter einer Organisation mit mehreren Maintainern oder unter einem einzelnen persönlichen Account? Wie lange existiert das Repository schon, und gab es in der jüngeren Vergangenheit einen Wechsel der Maintainer oder der Ownership? Wie regelmäßig kommen Commits, und stammen sie von mehreren unterschiedlichen Personen oder von einer einzigen?

Ein Ownership-Wechsel ist dabei kein Alarmsignal für sich allein, aber ein Punkt, an dem sich frühere Vertrauensbewertungen nicht mehr automatisch übertragen lassen. Wer eine Action vor zwei Jahren geprüft hat und sie seither unverändert weiterlaufen lässt, hat unter Umständen eine andere Action vor sich, als er ursprünglich geprüft hat.

Berechtigungsumfang: was die Action von deinem Repository verlangt

Der zweite Blick gilt dem, was die Action tatsächlich braucht, um zu funktionieren, im Vergleich zu dem, was sie tatsächlich anfordert. Eine Action, die Dateinamen zwischen zwei Commits vergleicht, braucht Lesezugriff auf den Verlauf. Verlangt sie zusätzlich Schreibrechte auf Repository-Inhalte oder Zugriff auf Secrets, die mit ihrer eigentlichen Aufgabe nichts zu tun haben, ist das eine Diskrepanz, die eine Rückfrage wert ist, unabhängig davon, wie bekannt die Action ist.

Die README und die action.yml im Repository zeigen üblicherweise, welche Inputs und welche Permissions vorgesehen sind. Der Vergleich mit dem, was dein Workflow ihr tatsächlich an Rechten mitgibt, ist der eigentliche Prüfschritt. Least Privilege gilt für Third-Party Actions genauso wie für jeden Service-Account: nur die Rechte gewähren, die die konkrete Aufgabe erfordert, nicht mehr.

Der Code selbst: composite, Docker oder JavaScript

GitHub Actions gibt es in drei Bauformen. Composite Actions reihen bestehende Schritte aneinander und sind meist am leichtesten nachzuvollziehen. Docker Actions laufen in einem eigenen Container, dessen Inhalt du dir separat ansehen musst. JavaScript Actions führen kompilierten oder gebündelten Code aus, der im Repository oft nicht mehr im Klartext, sondern minifiziert vorliegt.

Für die Prüfung heißt das: Es reicht nicht, sich auf die Beschreibung zu verlassen. Ein Blick in den tatsächlichen Quellcode, oder zumindest in die Liste der Schritte und Abhängigkeiten, die eine Action mitbringt, zeigt, ob nachvollziehbar bleibt, was ausgeführt wird. Bei minifiziertem Code sinkt diese Nachvollziehbarkeit erheblich, was ein Grund mehr ist, den Berechtigungsumfang eng zu halten, wenn du dich für den Einsatz entscheidest.

Was das mit Pinning zu tun hat, und was nicht

Diese Prüfung liegt vor der Pinning-Frage, nicht anstelle von ihr. Ob eine Action überhaupt vertrauenswürdig genug ist, um sie einzusetzen, ist eine andere Frage als die, wie du eine bereits akzeptierte Action danach stabil und nachvollziehbar hältst. Letzteres, warum ein Commit-SHA einem Versionstag vorzuziehen ist und was eine Allowlist dabei leistet, haben wir im Artikel „Third-Party Actions pinnen“ (digital-business.blog/2026/07/10/third-party-actions-pinnen-warum-sha-statt-tag-und-was-eine-allowlist-bringt) behandelt. Beide Schritte gehören zusammen, aber sie beantworten unterschiedliche Fragen: Vetting entscheidet über das Ob, Pinning über das Wie danach.

Eine Action, die du ungeprüft einsetzt, bleibt riskant, ganz gleich, wie sauber sie anschließend gepinnt ist. Ein sauber gepinnter Commit-Hash macht eine kompromittierte Action nicht vertrauenswürdig, er macht nur nachvollziehbar, welche Version genau lief.

Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Alles Weitere richtet sich nach der Lage und läuft über drei Felder: Implementation, also Delivery und Nachweis modulweise in die Pipeline einziehen, AI Governance, also Nachvollziehbarkeit bei KI-gestützten Build- und Deployment-Schritten, und Maintenance, also die Frage, wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem mehr gehört. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Kontakt: mm@mhm-dl.de