Astrals Open-Source-Sicherheitsstrategie

 (astral.sh)
1 Punkte von GN⁺ 19 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Astral, das Tools wie Ruff, uv und ty entwickelt, die von Entwicklerinnen und Entwicklern auf der ganzen Welt genutzt werden, hält Sicherheit und Zuverlässigkeit für den zentralen Wert aller Produkte
  • Als Reaktion auf die jüngste Zunahme von Supply-Chain-Angriffen hat das Unternehmen interne Methoden zur Härtung der Sicherheit über den gesamten Build-, Distributions- und Release-Prozess hinweg offengelegt
  • In einer auf GitHub Actions basierenden CI/CD werden mehrschichtige Schutzmechanismen wie Hash-Pinning, minimale Berechtigungen und die Trennung von Geheimnissen eingesetzt
  • In der Release-Phase wird die Integrität der Auslieferung mit Trusted Publishing, Sigstore Attestations und Immutable Releases sichergestellt
  • Mit diesem Ansatz will Astral das Sicherheitsniveau des gesamten Open-Source-Ökosystems verbessern und nachhaltige Abwehrmechanismen aufbauen

Astrals Open-Source-Sicherheitsansatz

  • Astral entwickelt Tools wie Ruff, uv und ty, die von Millionen Entwicklerinnen und Entwicklern weltweit genutzt werden, und behandelt Sicherheit und Zuverlässigkeit dieser Tools als Kernwert
  • Da Supply-Chain-Angriffe zuletzt zugenommen haben, etwa bei den Hacks rund um Trivy und LiteLLM, hat Astral interne Sicherheitsmethoden veröffentlicht, mit denen die Sicherheit der eigenen Tools sowie der Build- und Distributionsprozesse gewährleistet werden soll
  • Dabei werden Best Practices für Sicherheit geteilt, an denen sich Nutzer, Open-Source-Maintainer und Entwickler von CI/CD-Systemen orientieren können

CI/CD-Sicherheit

  • Astral automatisiert Entwicklung und Auslieferung über umfangreiche CI/CD-Workflows auf Basis von GitHub Actions und nutzt diese als zentrale Sicherheitskomponente
    • Builds und Tests laufen damit nicht lokal, sondern in einer kontrollierten und beobachtbaren Umgebung
  • Da die Standard-Sicherheitseinstellungen von GitHub Actions als schwach erkannt wurden, setzt Astral unter anderem folgende Härtungsmaßnahmen um
    • vollständiges Verbot riskanter Trigger wie pull_request_target und workflow_run
    • Festlegung aller Actions auf einen bestimmten Commit-Hash (SHA) und zusätzliche Querprüfung auf impostor commits
    • kombinierter Einsatz der Audit-Tools unpinned-uses und impostor-commit von zizmor zusammen mit GitHub-Richtlinien
    • Hash-Pinning des gesamten Abhängigkeitsgraphen, einschließlich indirekt abhängiger Actions, bei denen Pinning nicht direkt möglich ist
  • Da Hash-Pinning allein nicht ausreicht, werden Unveränderlichkeitsmängel manuell geprüft und bei Bedarf gemeinsam mit Upstream-Projekten behoben
    • Beispiel: Download-URLs und Hashes für Binärdateien werden fest zugeordnet und unveränderlich eingebettet
  • Workflow-Berechtigungen sind standardmäßig auf nur Lesen beschränkt; pro Job werden nur die jeweils minimal nötigen Rechte vergeben
  • GitHub Secrets werden als nach Umgebung getrennte Deployment-Variablen verwaltet, damit Test- und Lint-Jobs keinen Zugriff auf Release-Geheimnisse erhalten
  • Als zusätzliche Werkzeuge kommen zizmor (statische Analyse) und pinact (automatisches Hash-Pinning) zum Einsatz

Repository- und Organisationssicherheit

  • Innerhalb der Astral-Organisation wird die Zahl der Konten mit Administratorrechten minimiert; die meisten Mitglieder erhalten nur Lese-/Schreibrechte für die jeweils benötigten Repositories
  • Für alle Mitglieder ist starke Zwei-Faktor-Authentifizierung (2FA) verpflichtend, mindestens auf dem Niveau von TOTP
    • Falls GitHub künftig nur noch phishing-resistente Verfahren wie WebAuthn oder Passkeys zulässt, will Astral sofort umsteigen
  • Branch-Schutzregeln werden organisationsweit angewendet
    • Auf den Branch main sind Force-Pushes nicht erlaubt; alle Änderungen müssen per PR eingebracht werden
    • Bestimmte Branch-Muster wie advisory-* oder internal-* dürfen nicht erstellt werden
  • Über Tag-Schutzregeln können Tags erst nach erfolgreicher Release-Auslieferung erstellt werden
    • Änderungen oder Löschungen von Tags sind verboten; Releases sind nur vom Branch main aus möglich
  • Selbst Repository-Administratoren können die Schutzregeln nicht umgehen; alle Schutzmechanismen werden auf Organisationsebene erzwungen
  • Astral hat diese Regelsammlung als gist veröffentlicht, damit andere Projekte sie als Referenz nutzen können

Automatisierung

  • Mit GitHub Actions lassen sich bestimmte Aufgaben wie Kommentare zu PRs von Dritten nicht sicher ausführen
  • Astral verwendet dafür die GitHub App astral-sh-bot, die Events sicher außerhalb von Actions verarbeitet
    • Die GitHub App erhält dieselben Event-Daten, läuft aber in einer Umgebung, in der Code und Daten voneinander getrennt sind
  • Allerdings entfernt auch die App keine sensiblen Zugangsdaten
    • Da Schwachstellen wie SQLi oder Prompt Injection bestehen können, muss sie mit demselben Sicherheitsniveau wie gewöhnliche Software entwickelt werden
    • Der Einsatz einer GitHub App bedeutet also nicht automatisch, dass die Ausführung nicht vertrauenswürdigen Codes sicher ist
  • Der GitHub-App-Ansatz ist sicherheitstechnisch vorteilhaft, erhöht aber die Komplexität
    • Entwicklung und Hosting der App sind nötig und können für Einzelentwickler oder kleine Projekte belastend sein
    • Das Python-Framework Gidgethub vereinfacht die Entwicklung
  • Astral plant, astral-sh-bot als Open Source zu veröffentlichen, und empfiehlt Mariattas Tutorial als Referenz

Release-Sicherheit

  • Astral-Tools werden nicht nur über GitHub, sondern auch über PyPI, Homebrew und Docker-Images verteilt
  • Um Supply-Chain-Angriffe zu verhindern, werden unter anderem folgende Maßnahmen umgesetzt
    • Einsatz von Trusted Publishing, um Registry-Zugangsdaten zu entfernen
    • Erstellung von Sigstore-basierten Attestations, die die kryptografische Verknüpfung zwischen Build-Artefakten und Workflows sicherstellen
      • Mit der GitHub-Funktion Immutable Releases werden nachträgliche Änderungen nach der Veröffentlichung verhindert
      • Durch Verzicht auf Build-Caches werden Cache-Poisoning-Angriffe blockiert
      • Der Release-Prozess ist in einer dedizierten Deployment-Umgebung isoliert
      • Für die Aktivierung der Release-Umgebung ist die Zustimmung eines weiteren Teammitglieds erforderlich, um bösartige Releases nach einer Kontenübernahme zu verhindern
      • Mit der Umgebung release-gate und einer GitHub-App-basierten Genehmigungsweiterleitung bleibt ein mehrstufiges Freigabeverfahren erhalten
      • Tags können erst nach einem erfolgreichen Release erstellt werden
      • Der Standalone-Installer prüft die Integrität von Binärdateien anhand eingebetteter Prüfsummen
      • Nach dem Release werden Dokumentation, Versionsmanifeste und pre-commit-Hooks über dedizierte Bot-Konten und fein granulierte PATs aktualisiert
      • Künftig ist zusätzlich Code Signing für macOS und Windows geplant

Sicherheit von Abhängigkeiten

  • Astral verwendet Dependabot und Renovate, um Dependency-Updates und Hinweise auf Schwachstellen zu verwalten
  • Durch eine Cooldown-Phase werden Updates direkt nach neuen Releases verzögert, um das Risiko vorübergehender Supply-Chain-Angriffe zu mindern
    • Renovate unterstützt Cooldown-Einstellungen pro Gruppe; für eigene Abhängigkeiten gelten gelockerte Regeln
  • Mit wichtigen Upstream-Projekten findet kontinuierliche Zusammenarbeit und Sicherheitsarbeit statt
  • Sicherheitsinformationen werden in Zusammenarbeit mit der Python Packaging Authority und dem Python Security Response Team geteilt
  • Neue Abhängigkeiten werden sorgfältig geprüft, und unnötige Abhängigkeiten sollen entfernt werden
    • Insbesondere werden Abhängigkeiten mit eingebetteten Binärblobs vermieden und unnötige Funktionen deaktiviert
  • Über den OSS Fund unterstützt Astral wichtige Open-Source-Projekte finanziell

Fazit und wichtigste Lehren

  • Open-Source-Sicherheit ist eine Kombination aus technischen und sozialen Problemen und erfordert kontinuierliche Gegenmaßnahmen
  • Von Astral hervorgehobene Grundprinzipien
    • Die Grenzen von CI/CD anerkennen und, wo unvermeidlich, externe Isolationsansätze wie GitHub Apps einsetzen
    • Langfristige Zugangsdaten eliminieren oder minimieren und dabei Trusted Publishing sowie OIDC-Authentifizierung nutzen
    • Den Release-Prozess härten, etwa durch Freigabe-, Tag- und Branch-Regeln sowie Immutable Releases
    • Abhängigkeiten im Blick behalten und mit Werkzeugen und Zusammenarbeit auch die Sicherheit von Upstream-Projekten stärken
  • Astral will diese Methoden fortlaufend bewerten und verbessern und die Abwehrmechanismen an verändertes Angreiferverhalten anpassen

Zusammenfassung der Fußnoten

  • PEP 740 von PyPI erlaubt das Hochladen von Attestations, ist derzeit aber noch nicht mit Astrals Trusted-Publishing-Implementierung kompatibel, weshalb die Nutzung vorerst aussteht
  • Prüfsummen im Installationsskript sind bei direkter Ausführung per curl ... | bash nur begrenzt wirksam, aber nützlich beim Vendoring innerhalb von CI/CD

Verwandte Beiträge

1 Kommentare

 
GN⁺ 19 일 전
Hacker-News-Kommentare

  • Um GitHubs CI sicher zu nutzen, scheint man zu viele Schritte durchlaufen zu müssen.
    Bei so einer Struktur halte ich einen sicheren Betrieb aus Sicht der Security für unmöglich.
    Es wirkt unrealistisch, Supply-Chain-Sicherheit auf ein System aufzubauen, das nicht einmal grundlegende Prinzipien wie Rechte-Trennung oder Isolation einhält.

    • Ich sehe das ähnlich. Ich habe kürzlich untersucht, wie man in GitHub Actions von Agenten geschriebenen Code sicher ausführen kann, und mit sandbox-action teilweise Erfolg gehabt.
      Aber die Konfiguration ist so fein abgestimmt, dass es nicht wie ein skalierbarer Ansatz wirkt. Wenn die Defaults sicherer wären, wäre schon viel gewonnen.
    • Mich würde interessieren, ob jemand statt dieses komplexen GitHub-CI ein brauchbares alternatives Build-System gesehen hat.
      Nachdem ich den ganzen Text gelesen habe, denke ich, dass diese Komplexität vielleicht ein inhärentes Problem dieses Bereichs ist.
    • Tatsächlich unterscheidet sich das nicht vom allgemeinen Problem bei Paketregistern.
      Die meisten unterstützen unveränderliche Releases nicht, und selbst wenn doch, ziehen sie oft automatisch neue Versionen nach, was sie anfällig für Angriffe macht.
      Wirklich sicher wäre es nur, verifizierte Abhängigkeiten mit fest gepinnten Versionen in einer eigenen Registry zu verwalten, aber das können praktisch nur Unternehmen wie Google.

  • Das uv-Binary unseres Teams bei stagex ist weltweit das einzige, das mit vollständigem Source-Bootstrapping und deterministischen, mehrfach signierten Artefakten gebaut wurde.
    Es verwendet ein Smartcard-basiertes Signatursystem, das mit einem 25 Jahre alten Web of Trust und mehr als 5000 Schlüsseln verbunden ist.
    Frustrierend ist, dass Freiwillige bei solcher Supply-Chain-Sicherheit engagierter sind als viele andere.

    • Der Markt hat die Antwort längst gegeben. Die Leute wollen Bequemlichkeit statt Sicherheit.
      Selbst wenn Tools wie OpenClaw Schlüssel und Geheimnisse leaken lassen, nutzen die Anwender sie weiter.
      Du versuchst, die Angriffsfläche zu verkleinern, während der Markt sie eher noch vergrößert.
    • Eigentlich ist das kein Grund, sich aufzuregen. Du baust eine reproduzierbare Linux-Distribution, und Partner verkaufen darauf aufbauend Support-Services.
      Ohne Freiwillige würden Projekte wie Debian gar nicht existieren. Man sollte nicht klagen, sondern mit besseren Ergebnissen konkurrieren.
    • (Ich bin der Autor des Artikels.) Die Anzahl oder das Alter von Schlüsseln ist kein Maß für Vertrauen.
      Wenn am Ende ein Dritter gebaute Artefakte bereitstellt, ist das Bedrohungsmodell nicht klar.
      Alle Builds von uv stammen aus gesperrten Auflösungen und liefern signierte Artefakte. Welchen zusätzlichen Wert Commits haben, die nur mit einem anderen Identitätssatz signiert sind, ist unklar.
    • Die Open-Source-Lizenz selbst ist so gestaltet, dass Unternehmen sie kostenlos nutzen können.
      Es gibt für OpenAI keinen zwingenden Grund, Geld auszugeben, um die Supply-Chain-Sicherheit zu verbessern.
    • Die Übernahme liegt erst ein paar Wochen zurück; es wäre eher seltsam gewesen, wenn OpenAI den Build-Prozess bereits geändert hätte.
      Die technische Kritik verstehe ich, aber OpenAI allein wegen des Zeitpunkts verantwortlich zu machen, halte ich für überzogen.

  • Zur Einordnung: Trusted Publishing bei PyPI wurde gemeinsam von William Woodruff und dem Team von Trail of Bits implementiert.

  • Ich würde das Astral-Team gern fragen, wie es diese starke Abhängigkeit von GitHub selbst trotz all dieser Mühe handhabt.
    Was macht ihr, wenn GitHub gehackt wird oder ein Bug die Konfiguration verändert?

    • Wir stehen auch direkt mit GitHub in Kontakt. Weil sie kritische Infrastruktur sind, überwachen wir Änderungen an der Plattform sehr genau.
    • GitHub hat wirklich viele Bugs. Es kommt oft genug vor, dass ein Workflow schon daran scheitert, einen Branch aus dem eigenen Repository zu klonen.

  • Das Open-Source-Ökosystem ist widerstandsfähig, aber beim Sandboxing von 3rd-Party-Code gibt es weiter Defizite.
    Bei uv wird oft hervorgehoben, wie einfach sich damit mehrere Python-Versionen verwalten lassen, aber genau das bedeutet auch, dass es ohne Isolation auf dem Host-Rechner läuft, und das macht mich unruhig.

    • Ich nutze uv immer innerhalb von Docker. Dann ist es ziemlich praktisch.

  • Ein großes aktuelles Problem der Supply Chain ist, dass viele Tools und Abhängigkeiten ohne Herkunftsprüfung heruntergeladen werden.
    Deshalb entwickle ich asfaload, eine Open-Source-Multisig-Lösung zur Dateiverifikation.
    So etwas könnte Vorfälle wie bei axios verhindern.

    • Ist das nicht genau der Zweck von Release Attestations? Siehe diese Dokumentation.
    • Der Ansatz scheint in die richtige Richtung zu gehen. Allerdings sind Code und Produkt noch nicht öffentlich, deshalb ist eine Bewertung schwierig.
    • Ich denke, statt nur bestimmte Autoren zu verifizieren, wäre es besser, automatisierte Code-Audit-Tools einzusetzen, um allen Code zu prüfen.

  • Selbst wenn man GitHub Actions auf einen Commit-SHA pinnt, bleibt es riskant, wenn diese Action weitere Abhängigkeiten nachlädt.
    Die eigentliche Lösung ist, in der CI-Pipeline den Code selbst zu besitzen oder nach einem Fork eigenständig zu pflegen.

    • Das wird im Artikel ebenfalls behandelt. Wir verfolgen einen Defense-in-Depth-Ansatz.
      Wir auditieren alle Actions und patchen oder ersetzen sie, wenn es veränderliche Abhängigkeiten gibt (ich bin bei Astral).
    • Sicherheit ist immer ein Trade-off.
      Den gesamten Stack selbst zu betreiben ist am sichersten, aber nicht realistisch.
      Hash-Pinning ist fast eine kostenlose Sicherheitsverbesserung.
      Entscheidend ist letztlich, klar zu verstehen, wo man Vertrauen setzt.
    • Wenn man ohnehin 3rd-Party-Actions verwendet, muss man den Code sowieso selbst lesen und verifizieren. Ein Fork allein löst das Problem nicht.

  • Wenn man sich die jüngsten Vorfälle bei Trivy und litellm ansieht, braucht es wirklich Sicherheitsleitfäden für Release-Prozesse.
    Die Ratschläge in diesem Text sind praxisnah und sofort anwendbar.
    Der Kern von Supply-Chain-Sicherheit hängt davon ab, wie sicher die Standardkonfigurationen der Plattformen sind, auf die wir uns verlassen.

  • Eine hervorragende Übersicht. Das dürfte auch für andere Open-Source-Projekte als Referenzmaterial nützlich sein.

  • Ich pflege das Python-CLI- und wiederverwendbare Workflow-Tool repomatic.
    Es enthält die meisten der in diesem Artikel beschriebenen Sicherheitspraktiken bereits standardmäßig.
    Ziel ist es, eine Umgebung zu schaffen, in der Sicherheit der Standard ist.
    Nach der Lektüre habe ich eine Prüfung für die Freigabepolitik von Fork-PRs ergänzt.
    Mehr dazu im GitHub-Repository.