Wie du einen Reusable Workflow technisch richtig baust, mit GITHUB_TOKEN-Durchreichung und der Regel, dass ein permissions:-Block Rechte nur einschränken, nie erweitern kann, steht bereits ausführlich mit Codebeispiel in Reusable Workflows in GitHub Actions sauber bauen vom 17.07.2026 auf muellermh.blog. Dieser Beitrag wiederholt das nicht. Er setzt eine Ebene höher an: wer in einer Organisation secrets: inherit überhaupt autorisieren kann, was du als Repo-Maintainer preisgibst, wenn du damit einen fremden zentralen Workflow aufrufst, und wie weit der Schaden reicht, wenn genau dieser zentrale Workflow kompromittiert wird.
Die Grenze, die secrets: inherit überhaupt zieht
secrets: inherit reicht alle Secrets des aufrufenden Workflows unverändert an den aufgerufenen Reusable Workflow weiter, ohne sie einzeln aufzulisten. Das funktioniert laut GitHub-Dokumentation ausschließlich für Aufrufe innerhalb derselben Organisation oder desselben Enterprise (docs.github.com, Abschnitt „Passing inputs and secrets to a reusable workflow“). Ein Reusable Workflow aus einer fremden Organisation oder von einem Drittanbieter kann inherit also gar nicht empfangen, GitHub blockt das organisationsübergreifend. Relevant wird die Frage „wer darf das setzen“ deshalb zuerst innerhalb der eigenen Organisation: Jeder, der Schreibzugriff auf ein Repository hat, kann in dessen Workflow-Datei secrets: inherit eintragen und damit sämtliche Organisations- und Repository-Secrets an einen zentralen Workflow weiterreichen, den ein anderes Team pflegt. Das ist keine Einstellung, die eine Organisation zentral vergibt. Es ist eine Zeile Code, die jeder mit Schreibrecht auf das rufende Repository selbst setzt.
Was der Aufruf eines fremden zentralen Workflows preisgibt
Ruft dein Repository einen zentralen Reusable Workflow eines anderen Teams auf, bekommt dieser Workflow genau die Rechte, die du ihm im permissions:-Block mitgibst, nie mehr als das eigene Token des rufenden Workflows selbst trägt: GitHub hält dazu fest, dass Berechtigungen entlang der Kette nur erhalten oder reduziert, nie erweitert werden können (docs.github.com, Abschnitt „Nesting reusable workflows“). Diese Grenze ist eine Ober-, keine Untergrenze: Sie verhindert, dass der fremde Workflow sich selbst mehr Rechte verschafft, sie verhindert nicht, dass er mit secrets: inherit Zugriff auf jedes Secret bekommt, das deinem Workflow zur Verfügung steht, auch solche, die der fremde Workflow gar nicht braucht. Zur Abgrenzung: Composite Actions richtig schneiden vom 17.08.2026 erwähnt secrets: inherit nur knapp im Vergleich zu Composite Actions, ohne diese Tiefe. Die Governance-Frage, wer das für einen fremden zentralen Workflow setzen darf, ist dort nicht das Thema.
Secrets wandern nicht automatisch mit
Wird in einer Kette A ruft B ruft C ein weiterer Reusable Workflow verschachtelt, gehen Secrets ausschließlich an den direkt aufgerufenen Workflow: „Secrets are only passed to directly called workflow“ (docs.github.com, Abschnitt „Passing secrets to nested workflows“). Workflow C bekommt Secrets von A also nur, wenn B sie explizit an C weiterreicht, nicht automatisch, weil A sie an B inherited hat. Wer die Reichweite eines secrets: inherit einschätzen will, muss deshalb die ganze Aufrufkette lesen, nicht nur den eigenen Workflow.
Die repo-seitige Freigabe für private Repositories
Ob ein privates Repository fremden Workflows überhaupt erlaubt, seine Reusable Workflows oder Actions zu nutzen, regelt eine eigene Einstellung in den Repository-Einstellungen: „Not accessible“, oder Freigabe für Repositories desselben Besitzers beziehungsweise derselben Organisation (docs.github.com, Abschnitt „Allowing access to components in a private repository“). Diese Regelung gilt ausdrücklich nur für private Repositories, der Zugriff ist dort „nur von privaten Repositories“ aus möglich, und lässt sich nicht auf öffentliche Repositories übertragen, für die andere Regeln gelten. Wer einen zentralen Workflow in einem privaten Repository pflegt, entscheidet über diese Einstellung mit, wer ihn aus anderen Repositories heraus überhaupt aufrufen darf, unabhängig von secrets: inherit.
Die org-weite Allow/Block-Policy für Actions und Reusable Workflows
Oberhalb der einzelnen Repository-Einstellung kann eine Organisation selbst festlegen, welche Actions und Reusable Workflows überhaupt laufen dürfen: über die Policy „Allow OWNER, and select non-OWNER, actions and reusable workflows“ mit einer Allowlist in der Syntax OWNER/REPOSITORY/PATH/FILENAME@TAG-OR-SHA. Wildcards sind mit * möglich, etwa für alle Workflows einer bestimmten Organisation, mehrere Muster werden mit Komma getrennt, und ein führendes ! blockt ein Muster gezielt, selbst innerhalb einer sonst erlaubten Gruppe (docs.github.com, Abschnitt zur Policy für Actions und Reusable Workflows in Organisationen). Diese Policy ist der eigentliche Hebel für die Frage „wer darf überhaupt einen fremden zentralen Workflow aufrufen“: Steht ein Workflow nicht auf der Allowlist, kommt die Frage nach secrets: inherit gar nicht erst auf.
Blast-Radius bei einem kompromittierten zentralen Workflow
Wird ein zentraler Reusable Workflow kompromittiert, auf den mehrere Repositories mit secrets: inherit zugreifen, reicht der Schaden so weit wie die Summe der Secrets, die diese Repositories jeweils an ihn weitergereicht haben, nicht nur die Secrets, die der Workflow für seine eigentliche Aufgabe braucht. Das ist ein anderer Blast-Radius-Gedanke als in Self-hosted Runner als geteilte Angriffsfläche auf diesem Blog: Dort geht es um den Hardware-Pool, den sich mehrere Jobs teilen, hier um die Secrets- und Workflow-Lieferkette. Zur Versionierung eines solchen zentralen Workflows, Major-Tags, Breaking Changes und das Risiko von @main als Referenz, siehe Reusable Workflows versionieren: Major-Tags, Breaking Changes, Test-Repo und Reusable Workflows: Breaking Changes vermeiden und ankündigen, beide ohne Permissions- oder Secrets-Bezug. Wer zusätzlich steuern will, über welche Freigabestufe ein Deployment überhaupt laufen darf, findet den Approval-Gate-Mechanismus in Deployment Environments als eigene Berechtigungsgrenze, und wer die Zugriffsrechte auf den Branch selbst absichern will, der den Aufruf enthält, in Repository Rulesets: der Nachfolger von Branch Protection Rules. Alle drei regeln einen anderen Mechanismus als die Frage, wer secrets: inherit setzen darf.
Was das für deine Org-Policy heißt
Drei Fragen lohnen sich vor jedem Aufruf eines fremden zentralen Reusable Workflows. Erstens: Steht dieser Workflow überhaupt auf der org-weiten Allowlist, oder würde ihn ein Block-Muster mit ! ausschließen? Zweitens: Erlaubt die Repo-Einstellung des Ziel-Repositories, falls privat, den Zugriff aus deinem Repository überhaupt? Drittens: Trägt dein Workflow secrets: inherit, und wenn ja, welche Secrets stehen deinem Workflow insgesamt zur Verfügung, nicht nur welche der fremde Workflow tatsächlich braucht? Wer nur die dritte Frage stellt, sieht nur die Zeile im eigenen Workflow, nicht die Organisationsgrenze und die Allowlist, die vorher schon entschieden haben, ob diese Zeile überhaupt wirken kann.
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.
Kommentar verfassen