Was das Sicherheits-Playbook von Astral über die Macht von SBOMs verrät
Ritesh Noronha
Die meisten Softwareteams ku00f6nnen das Sicherheitsprogramm von Astral nicht kopieren. Sie verfu00fcgen nicht u00fcber die gleiche Zeit der Maintainer, das institutionelle Wissen oder die massgeschneiderten Tools. Was sie jedoch tun ku00f6nnen, ist, mehr von ihrer Lieferkette sichtbar, messbar und durchsetzbar zu machen.
Das ist es, was uns bei der Aufschlu00fcsselung von Astral, wie sie Ruff, uv und ty sichern, besonders aufgefallen ist. Unserer Ansicht nach hu00e4ngt die Mehrheit der von ihnen beschriebenen Praktiken entweder direkt von den Metadaten der Lieferkette ab oder wird in Kombination mit SBOMs, Attestierungen, VEX und verwandten Artefakten besser pru00fcfbar.
Wir wollen die Pru00e4zision dieser Schu00e4tzung nicht u00fcberbewerten. Es geht nicht darum, ob die genaue Zahl bei 55 % oder 65 % liegt. Der Punkt ist, dass ein grosser Teil des Playbooks von Astral einfacher zu operationalisieren ist, sobald das Artefakt, sein Inhalt und seine Herkunft maschinenlesbar sind.
Hier ist eine kompakte Mu00f6glichkeit, diese Aufteilung zu betrachten:
Kategorie | Beispiel aus dem Beitrag von Astral | SBOM-bezogene Auswirkungen |
|---|---|---|
Abhu00e4ngigkeitsinventar | Konservative Auswahl an Abhu00e4ngigkeiten, Update-Hygiene | Direkt unterstu00fctzt durch SBOMs und Abhu00e4ngigkeitsmetadaten |
Umgang mit Schwachstellen | Projektu00fcbergreifende Auswirkungsanalyse, Triage | Verstu00e4rkt durch SBOM-Korrelation und VEX |
Release-Herkunft | Sigstore-Attestierungen, Pru00fcfsummen, Trusted Publishing | Verstu00e4rkt durch die Verknu00fcpfung von Artefakten mit SBOMs und Attestierungen |
Transparenz beim Build-Prozess | Action-Pinning, Hu00e4rtung der Pipeline | Teilweise unterstu00fctzt durch Build-Metadaten wie die CycloneDX-Formulierung |
Organisatorische Kontrollen | 2FA, Admin-Einschru00e4nkungen, Vier-Augen-Prinzip | Ausserhalb des SBOM-Rahmens |
Sichtbarkeit von Abhängigkeiten: Das Fundament
Der am ehesten SBOM-spezifische Abschnitt des Beitrags von Astral befasst sich mit der Sicherheit von Abhängigkeiten. Es wird beschrieben, wie Dependabot und Renovate für Updates genutzt werden, soziale Kontakte zu Upstream-Maintainern gepflegt werden, man bei der Hinzufügung neuer Abhängigkeiten zurückhaltend bleibt und sogar Projekte, von denen man abhängt, über den eigenen OSS-Fonds finanziell unterstützt werden.
All dies beginnt mit einer grundlegenden Frage: Wovon hängst du eigentlich ab?
Ein SBOM kann dies beantworten, wenn es mit ausreichender Abdeckung erstellt wird. Ein gut produziertes CycloneDX- oder SPDX-Dokument für uv listet nicht nur direkte Cargo-Abhängigkeiten auf — es kann transitive Abhängigkeiten, integrierte Bibliotheken, Build-Tools und plattformspezifische Komponenten erfassen, die bei einer manuellen Überprüfung meist übersehen werden. In der Praxis ermöglicht dies Folgendes:
Verfolgen von Trends bei der Anzahl der Abhängigkeiten über Releases hinweg (reduzierst du tatsächlich deine Angriffsfläche?)
Kennzeichnen von Komponenten, die Binär-Blobs einführen oder übermäßige transitive Abhängigkeiten nach sich ziehen
Identifizieren von verwaisten oder nicht gepflegten Upstream-Projekten, bevor sie zu einem Risiko werden
Priorisieren, welche Upstream-Projekte finanzielle Unterstützung verdienen, basierend auf ihrer tatsächlichen Kritikalität in deinem Abhängigkeitsbaum
Was Astral durch institutionelles Wissen und soziale Kontakte erreicht, können SBOMs wiederholbarer und prüfbarer machen – besonders wichtig, wenn Organisationen über die Fähigkeit eines einzelnen Teams hinauswachsen, mentale Modelle ihrer Lieferkette zu pflegen.
Dependency Cooldowns: Eine Richtlinie, die Software-Stücklisten (SBOMs) durchsetzen können
Eine der interessanteren Praktiken, die Astral beschreibt, sind Dependency-Cooldowns (Abkühlzeiten für Abhängigkeiten) u2013 das absichtliche Verzögern der Übernahme neuer Versionen von Abhängigkeiten, um das Zeitfenster zu umgehen, in dem temporär kompromittierte Pakete am gefährlichsten sind. Sie weisen darauf hin, dass Renovate, Dependabot und uv selbst alle Cooldowns unterstützen.
Dies ist eine Risikomanagement-Richtlinie, deren Durchsetzung durch SBOMs unterstützt werden kann. Eine Supply-Chain-Plattform kann aktuelle Release-Metadaten direkt von Paketmanagern wie PyPI, crates.io, npm und anderen abrufen und Richtlinien definieren, die Komponenten kennzeichnen oder blockieren, die zu schnell nach der Veröffentlichung übernommen wurden. Anstatt sich nur auf Renovate- oder Dependabot-Konfigurationen zu verlassen, die abweichen oder überschrieben werden können, wird dadurch eine kontinuierliche, prüfbare Durchsetzungsebene geschaffen: Wenn eine Komponente in Ihrer SBOM vor 12 Stunden veröffentlicht wurde und Ihre Cooldown-Richtlinie 72 Stunden vorschreibt, kann die Richtlinie dies abfangen, solange die Komponente und die Version erfasst sind und die Release-Metadaten verfügbar sind.
Release-Integrität: Wo SBOMs und Attestierungen konvergieren
Der Abschnitt zur Releasesicherheit von Astral beschreibt Sigstore-Attestierungen, unveru00e4nderliche Releases, Trusted Publishing und Pru00fcfsummen, die in ihrem eigenstu00e4ndigen Installer eingebettet sind. Dies sind alles Mechanismen, um festzustellen, dass ein Artefakt authentisch ist u2013 dass es aus einem bekannten Build-Prozess stammt und nicht manipuliert wurde.
SBOMs fu00fcgen sich natu00fcrlich in diese Kette ein. In der Praxis ist das Artefakt typischerweise das Subjekt der Attestierung, wu00e4hrend die SBOM als signierte Erklu00e4rung u00fcber dieses Artefakt beigefu00fcgt oder referenziert wird. Gut umgesetzt beantwortet dies drei Fragen gleichzeitig:
Was ist in diesem Artefakt enthalten? (das Komponenteninventar der SBOM)
Woher kommt es? (die Identitu00e4t des Builders der Attestierung und die Workflow-Referenz)
Wurde es manipuliert? (die kryptografische Signatur, die beide miteinander verbindet)
Astral generiert bereits Sigstore-Attestierungen fu00fcr seine Binu00e4r- und Docker-Releases. Die Verknu00fcpfung dieser mit SBOMs wu00fcrde es nachgelagerten Nutzern ermu00f6glichen, nicht nur zu verifizieren, dass sie einen legitimen Build von uv erhalten haben, sondern auch zu pru00fcfen, was in diesen Build eingeflossen ist. Dies ist insbesondere fu00fcr Nutzer in regulierten Branchen relevant, in denen eine Herkunftsdokumentation nicht optional ist.
CI/CD als Lieferkette: Die Build-SBOM
Einige der aufwendigsten Sicherheitsarbeiten von Astral zielen auf ihre CI/CD-Pipelines ab u2013 Hash-Pinning von GitHub-Actions, manuelles Überprüfen von Actions auf veränderbare Entscheidungen, Isolieren von Geheimnissen in Deployment-Umgebungen, Blockieren gefährlicher Workflow-Trigger. Dies sind arbeitsintensive, hochqualifizierte Aufgaben.
CycloneDX hat formulation in Version 1.5 eingeführt und seitdem kontinuierlich erweitert, was dem Format eine Möglichkeit gibt, Build-Pipelines als strukturierte Daten zu beschreiben u2013 die Werkzeuge, Aktionen, Umgebungen und Konfigurationen, die an der Erstellung eines Artefakts beteiligt sind. Dies befindet sich im Ökosystem noch in einem frühen Stadium, aber die Richtung ist klar: Build-Prozesse selbst sind Supply-Chain-Komponenten und sollten als solche inventarisiert werden.
Ein SBOM, das Formulierungsdaten enthält, könnte letztendlich Teile des CI/CD-Härtungsprozesses von Astral für nachgelagerte Verbraucher überprüfbarer machen, sofern die entsprechenden Tools dies unterstützen. Anstatt sich ausschließlich auf die Darstellung eines Projekts zu verlassen, könnten Verbraucher strukturierte Build-Metadaten zusammen mit anderen Supply-Chain-Artefakten prüfen. Dies schafft auch Verantwortlichkeit: Wenn Ihr Build-SBOM eine nicht gepinnte Action anzeigt, sollten deren Qualität und Vertrauenswürdigkeit entsprechend sinken.
Schwachstellenmanagement in der Tiefe von Abhängigkeiten
Astral beschreibt die Pflege sozialer Kontakte zu Projekten wie dem Python Security Response Team und der PyPA, um Sicherheitserkenntnisse über Projektgrenzen hinweg auszutauschen u2013 beispielsweise wenn ein Bericht gegen pip auch uv betrifft.
Dies ist ein sozialer Prozess, der ein Datenproblem lu00f6st. Mit SBOMs wird die Korrelation von Schwachstellen u00fcber Projekte hinweg deutlich systematischer. Wenn sowohl pip als auch uv eine gemeinsame Komponente nutzen und diese Komponente eine CVE aufweist, kann eine SBOM-sensitive Schwachstellenplattform beide Projekte gleichzeitig kennzeichnen. Das ersetzt weder Mailinglisten, Vertrauensbeziehungen noch eine koordinierte Offenlegung, aber es verringert die Abhu00e4ngigkeit davon.
Diese Art von Arbeitsablauf hu00e4ngt von einer guten Korrelation zwischen NVD, OSV und Herstellerhinweisen unter Verwendung von Identifikatoren wie PURLs und CPEs ab, plus einer sorgfu00e4ltigen Handhabung schwieriger Grenzfälle u2013 Falschmeldungen bei Distro-Backports, gecodeten Forks mit nicht-standardisierter Versionierung und schwacher CPE-Abdeckung fu00fcr eingebettete oder Nischenkomponenten u2013 die einen naiven Schwachstellenabgleich unzuverlu00e4ssig machen.
VEX (Vulnerability Exploitability eXchange) fu00fcgt hier eine weitere Ebene hinzu. Wenn Astral feststellt, dass eine CVE in einer Abhu00e4ngigkeit uv nicht tatsu00e4chlich betrifft, weil der ungesicherte Codepfad nicht erreichbar ist, kann diese Einschu00e4tzung als VEX-Erklu00e4rung erfasst werden, die an die SBOM angehu00e4ngt ist. Dies macht eine einmalige Triage-Entscheidung zu einem wiederverwendbaren, maschinenlesbaren Artefakt, von dem jeder nachgelagerte Verbraucher profitiert.
Was SBOMs nicht abdecken – und warum genau das der Punkt ist
Hier kommt die „Keine Patentlösung“-Ehrlichkeit ins Spiel. In unserer Analyse fällt ein erheblicher Teil der Sicherheitslage von Astral eindeutig außerhalb des SBOM-Bereichs:
Organisatorische Kontrollen – Durchsetzung von 2FA, Einschränkung von Admin-Rechten, Verbot für Admins, Schutzmaßnahmen zu umgehen. Dies sind Probleme des Identitäts- und Zugriffsmanagements.
CI/CD-Trigger-Richtlinien – Organisationsweites Verbot von
pull_request_targetundworkflow_run. Dies ist Governance der Plattform.Vier-Augen-Prinzip für Freigaben – Eine menschliche Prozesskontrolle, die kein Dokumentenformat ersetzen kann.
Kein Caching in Release-Builds – Eine Build-Richtlinienentscheidung.
GitHub-App-Isolierung – Ein Architekturmuster zur Trennung von privilegierten Operationen und CI/CD.
SBOMs geben nicht vor, diese Probleme zu lösen, und wer Ihnen etwas anderes erzählt, will Ihnen etwas verkaufen. Das richtige mentale Modell sind Schichten: Organisatorische Kontrollen stellen sicher, dass der Prozess sicher ist, SBOMs dokumentieren die Inhalte, Attestierungen authentifizieren Angaben über Artefakte und das Schwachstellenmanagement bewertet, ob diese Inhalte sicher sind. Jede Schicht verstärkt die anderen. Keine einzelne Schicht ist ausreichend. Aber ohne die SBOM-Schicht sagen die anderen Schichten weniger darüber aus, was sich tatsächlich in dem Artefakt befindet, das Sie sichern.
Das Gesamtbild: Ein großer Anteil ist immer noch materiell
Was Astrals Beitrag so beeindruckend macht, ist gleichzeitig das, was ernüchternd ist: der schiere Aufwand an manueller Arbeit, institutionellem Wissen und maßgeschneiderten Werkzeugen, der erforderlich ist, um ein gut ausgestattetes Open-Source-Projekt abzusichern. Die meisten Projekte verfügen nicht über die Ressourcen, um dies zu replizieren.
SBOMs bringen Sie nicht auf 100 %. Nichts tut das. Sicherheit besteht aus verschiedenen Ebenen, und wer ein Allheilmittel verspricht, ignoriert den Anteil, der immer noch menschliches Urteilsvermögen, organisatorische Disziplin und Kontrollen auf Plattformebene erfordert.
Aber der Bereich, den SBOMs betreffen – Sichtbarkeit von Abhängigkeiten, Korrelation von Schwachstellen, Herkunft von Releases, Durchsetzung von Cooldown-Phasen, Überprüfbarkeit von Builds und VEX-gestützte Triage – stellt den Teil der Lieferkettensicherheit dar, der automatisiert, gemessen und kontinuierlich überwacht werden kann, anstatt sich auf heroische Einzelleistungen zu verlassen. Und für die überwiegende Mehrheit der Projekte, die nicht mit den Investitionen von Astral mithalten können, ist dies oft der Unterschied zwischen einer echten Sicherheitslage und dem bloßen Hoffen.
SBOMs sind kein Allheilmittel. Sie sind das Fundament, das alles andere verifizierbar macht.