Astral entwickelt Tools, auf die sich Millionen von Entwicklerinnen und Entwicklern weltweit verlassen (Ruff, uv, ty), und hat vor dem Hintergrund der jüngsten Supply-Chain-Hacks bei Trivy und LiteLLM seine eigenen Sicherheitspraktiken offengelegt. Die Zielgruppe umfasst drei Gruppen: Nutzer, andere Open-Source-Maintainer und Entwickler von CI/CD-Systemen.
1. CI/CD-Sicherheit
Die Sicherheits-Defaults von GitHub Actions sind anfällig, und Vorfälle bei Ultralytics, tj-actions und Nx gingen allesamt auf riskante Trigger wie pull_request_target zurück. Astrals Gegenmaßnahmen sind die folgenden:
Vollständiges Verbot riskanter Trigger
Trigger wie pull_request_target und workflow_run, die sich praktisch nicht sicher einsetzen lassen, werden organisationsweit verboten. Die meisten Projekte glauben, diese Trigger zu brauchen, tatsächlich reichen in den meisten Fällen aber der weniger privilegierte Trigger pull_request oder einfache Workflow-Logs aus.
Hash-Pinning für Action-Commit-Hashes
Statt auf Tags oder Branches (veränderbar) zu verweisen, wird auf eine konkrete Commit-SHA gepinnt. Zusätzlich wird gegengeprüft, ob dieser Commit tatsächlich dem Release-Stand entspricht, um „Impostor Commits“ zu verhindern. Dabei kommen zizmor und GitHubs eigene Policies gemeinsam zum Einsatz, und selbst indirekt aufgerufene verschachtelte Actions werden vollständig per Hash gepinnt.
Prinzip der geringsten Rechte
Auf Organisationsebene werden die Standardrechte auf schreibgeschützt gesetzt, und jeder Workflow beginnt mit permissions: {}; nur auf Job-Ebene werden die tatsächlich benötigten Rechte ergänzt. Secrets werden außerdem nicht auf Organisations- oder Repository-Ebene verwaltet, sondern pro Deployment-Umgebung isoliert, damit Test-Jobs keinen Zugriff auf Release-Secrets erhalten.
2. Repository- und Organisationssicherheit
Die Zahl der Admins und Konten mit weitreichenden Rechten wird minimiert; die meisten Organisationsmitglieder erhalten nur Lese- und Schreibrechte für die Repositorys, die sie tatsächlich benötigen. Für 2FA verlangt Astral mindestens TOTP und damit mehr als GitHubs Standardanforderung (egal welche Methode); künftig soll dies weiter verschärft werden, sodass nur noch WebAuthn und Passkeys zugelassen werden.
Für den main-Branch gelten Schutzregeln wie kein Force-Push und verpflichtende Pull Requests; Release-Tags dürfen erst nach erfolgreichem Deployment erstellt werden. Besonders wichtig: Diese Regeln werden auf Organisationsebene erzwungen, sodass selbst Repository-Admins sie nicht umgehen können.
3. Automatisierung (mit GitHub Apps)
Aufgaben, die sich in GitHub Actions nicht sicher umsetzen lassen, etwa Kommentare in Third-Party-PRs zu hinterlassen, werden in die GitHub App astral-sh-bot ausgelagert. Gleichzeitig betont Astral, dass auch GitHub Apps nicht frei von Schwachstellen sind und bei Ausführung von nicht vertrauenswürdigem Code zwingend der Trigger pull_request verwendet werden muss.
4. Release-Sicherheit
Für Deployments auf PyPI, crates.io und NPM nutzt Astral Trusted Publishing, sodass keine langfristigen Zugangsdaten nötig sind. Binärdateien und Docker-Images werden zudem mit Sigstore-basierten Attestierungen versehen, um eine kryptografische Verbindung zwischen Release-Artefakten und den zugehörigen Workflows herzustellen.
Mit GitHubs Funktion für unveränderliche Releases (immutable releases) wird verhindert, dass veröffentlichte Builds nachträglich manipuliert werden. Außerdem ist die Nutzung von Caches während des Release-Builds verboten, um Cache-Poisoning-Angriffe auszuschließen.
Auch der Release-Prozess selbst ist doppelt abgesichert: Zur Aktivierung der Release-Umgebung ist die manuelle Freigabe durch mindestens ein weiteres berechtigtes Organisationsmitglied erforderlich. Für einen bösartigen Release müssten also gleichzeitig zwei Konten mit starker 2FA kompromittiert werden.
5. Abhängigkeitssicherheit
Dependabot und Renovate werden genutzt, um Dependency-Updates und Hinweise auf bekannte Schwachstellen zu verwalten. Ergänzend gibt es jedoch eine „Cooldown“-Policy, nach der nicht sofort direkt nach einem neuen Release aktualisiert wird. So soll die Auswirkung vorübergehend kompromittierter Abhängigkeiten minimiert werden. In uv ist diese Funktion bereits integriert.
Astral pflegt außerdem soziale Verbindungen zu benachbarten Projekten und Arbeitsgruppen wie der Python Packaging Authority (PyPA) und dem Python Security Response Team, um Informationen zu teilen — etwa wenn ein an pip gemeldetes Problem auch uv betreffen könnte. Neue Abhängigkeiten werden zurückhaltend aufgenommen, Dependencies mit Binary Blobs werden vermieden, und nicht benötigte Features werden deaktiviert.
Zur Nachhaltigkeit abhängiger Projekte leistet Astral zudem finanzielle Beiträge über den OSS Fund.
Zusammenfassung der wichtigsten Empfehlungen
Astral hebt vier Kernprinzipien hervor: die Grenzen von CI/CD realistisch anerkennen und Aufgaben, die sich nicht sicher umsetzen lassen, konsequent aufgeben oder in GitHub Apps auslagern; langfristige Zugangsdaten nach Möglichkeit abschaffen und auf den kleinstmöglichen Bereich isolieren; den Release-Prozess über Deployment-Umgebungen, Freigaben und unveränderliche Tags absichern; sowie den Gesundheitszustand des gesamten Dependency-Baums kontinuierlich im Blick behalten.
Einordnung
Aus Sicht von jemandem, der sich intensiv mit PyPI und Supply-Chain-Sicherheit beschäftigt, ist dieser Beitrag mehr als nur ein Sicherheitsleitfaden: Er ist ein Praxisbeispiel dafür, wie sich die Vertrauensarchitektur des gesamten Open-Source-Ökosystems gestalten lässt. Besonders Trusted Publishing, die Cooldown-Policy und der Release-Prozess mit doppelter Freigabe sind für größere Open-Source-Projekte durchaus als Referenz interessant.
Original: Astral Blog, 2026.04.08
Noch keine Kommentare.