Was Astrals Sicherheits-Playbook über die Stärke von SBOMs verrät
Ritesh Noronha
In der SBOM-Community gibt es ein Sprichwort, auf das wir immer wieder zurückkommen: SBOMs sind keine Wunderwaffe. Das stimmt. Sie werden weder Ihr Organigramm in Ordnung bringen, noch 2FA durchsetzen oder einen abtrünnigen Insider davon abhalten, ein fehlerhaftes Release zu pushen.
Aber nachdem wir Astrals bemerkenswerte Analyse dazu gelesen hatten, wie sie Ruff, uv und ty absichern, ist uns etwas aufgefallen: Unserer Analyse zufolge können etwa 60 % der von ihnen beschriebenen Praktiken direkt durch SBOMs, Attestierungen und verwandte Supply-Chain-Artefakte erreicht, erweitert oder auditierbar gemacht werden.
Das ist nicht alles. Aber es ist viel — besonders wenn man bedenkt, dass das meiste von dem, was Astral heute tut, tiefes institutionelles Wissen, manuelle Prüfung und maßgeschneiderte Werkzeuge erfordert, die nur wenige Projekte nachbilden können.
Hier ist unsere Analyse dazu, wo sich SBOMs mit Astrals Praktiken überschneiden, wo sie es nicht tun und warum diese Schätzung wichtiger ist als der verbleibende Anteil, der weiterhin von menschlichen und organisatorischen Kontrollen abhängt.
Sichtbarkeit von Abhängigkeiten: Das Fundament
Der SBOM-nativste Abschnitt in Astrals Beitrag behandelt die Sicherheit von Abhängigkeiten. Sie beschreiben den Einsatz von Dependabot und Renovate für Updates, die Pflege sozialer Verbindungen zu Upstream-Maintainern, einen zurückhaltenden Umgang mit dem Hinzufügen neuer Abhängigkeiten und sogar die finanzielle Unterstützung von Projekten, von denen sie abhängen, über ihren OSS Fund.
All das beginnt mit einer grundlegenden Frage: wovon hängen Sie eigentlich ab?
Ein SBOM kann dies beantworten, wenn es mit ausreichender Abdeckung erstellt wird. Ein gut erzeugtes CycloneDX- oder SPDX-Dokument für uv listet nicht nur direkte Cargo-Abhängigkeiten auf — es kann auch transitive Abhängigkeiten, vendorte Bibliotheken, Build-Tools und plattformspezifische Komponenten erfassen, die bei manueller Prüfung oft übersehen werden. Bei Interlynk nimmt unsere SBOM-Management-Plattform diese Dokumente auf und bietet kontinuierliche Transparenz im Abhängigkeitsgraphen, wodurch Folgendes möglich wird:
Trends bei der Anzahl von Abhängigkeiten über Releases hinweg verfolgen (reduzieren Sie Ihre Angriffsfläche tatsächlich?)
Komponenten kennzeichnen, die binäre Blobs einführen oder übermäßig viele transitive Abhängigkeiten einbinden
Verwaiste oder nicht gepflegte Upstream-Projekte identifizieren, bevor sie zu Risiken werden
Priorisieren, welche Upstream-Projekte finanzielle Unterstützung verdienen, basierend auf der tatsächlichen Kritikalität in Ihrem Abhängigkeitsbaum
Was Astral durch institutionelles Wissen und soziale Verbindungen erreicht, können SBOMs wiederholbarer und auditierbarer machen — besonders wichtig, wenn Organisationen über die Fähigkeit eines einzelnen Teams hinaus wachsen, mentale Modelle ihrer Lieferkette aufrechtzuerhalten.
Abkühlzeiten für Abhängigkeiten: Eine Richtlinie, die SBOMs durchsetzen können
Eine der interessanteren Praktiken, die Astral beschreibt, sind Abhängigkeits-Abkühlphasen — also das absichtliche Verzögern der Einführung neuer Abhängigkeitsversionen, um das Zeitfenster zu vermeiden, in dem vorübergehend kompromittierte Pakete am gefährlichsten sind. Sie weisen darauf hin, dass Renovate, Dependabot und uv selbst alle Abkühlphasen unterstützen.
Dies ist eine Richtlinie für das Risikomanagement, deren Durchsetzung durch SBOMs unterstützt werden kann. Eine Plattform wie Interlynk bezieht die neuesten Release-Metadaten direkt von Paketmanagern — PyPI, crates.io, npm und anderen — und kann Richtlinien definieren, die Komponenten kennzeichnen oder blockieren, die zu früh nach der Veröffentlichung übernommen werden. Anstatt sich nur auf Renovate- oder Dependabot-Konfigurationen zu verlassen, die driften oder überschrieben werden können, schafft dies eine kontinuierliche, auditierbare Durchsetzungsebene: Wenn eine Komponente in Ihrer SBOM vor 12 Stunden veröffentlicht wurde und Ihre Abkühlrichtlinie 72 Stunden erfordert, kann die Richtlinie sie erfassen, solange die Komponente und Version erfasst sind und die Release-Metadaten verfügbar sind.
Release-Integrität: Wo SBOMs und Attestierungen zusammenkommen
Astrals Abschnitt zur Release-Sicherheit beschreibt Sigstore-Attestierungen, unveränderliche Releases, Trusted Publishing und in ihren eigenständigen Installer eingebettete Prüfsummen. All dies sind Mechanismen, um festzustellen, dass ein Artefakt authentisch ist — dass es aus einem bekannten Build-Prozess stammt und nicht manipuliert wurde.
SBOMs fügen sich natürlich in diese Kette ein. In der Praxis ist das Artefakt typischerweise das Subjekt der Attestierung, während die SBOM als signierte Aussage über dieses Artefakt angehängt oder referenziert wird. Gut umgesetzt beantwortet dies gleichzeitig drei Fragen:
Was ist in diesem Artefakt enthalten? (das Komponenteninventar der SBOM)
Woher stammt es? (die Builder-Identität und der Workflow-Verweis der Attestierung)
Wurde es manipuliert? (die kryptografische Signatur, die beide miteinander verknüpft)
Astral erzeugt bereits Sigstore-Attestierungen für ihre Binär- und Docker-Releases. Die Kombination dieser Attestierungen mit SBOMs — und die Bereitstellung dieser SBOMs über eine Management-Plattform — würde nachgelagerten Nutzern ermöglichen, nicht nur zu verifizieren, dass sie einen legitimen Build von uv erhalten haben, sondern auch zu prüfen, was in diesen Build eingeflossen ist. Das ist besonders relevant für Astrals Nutzer in regulierten Branchen, in denen Herkunftsdokumentation nicht optional ist.
Bei Interlynk ist dies grundlegend.
CI/CD als Lieferkette: Das Build-SBOM
Einige der aufwendigsten Sicherheitsarbeiten von Astral zielen auf ihre CI/CD-Pipelines ab — Hash-Pinning von GitHub Actions, manuelle Überprüfung von Actions auf veränderliche Entscheidungen, Isolierung von Geheimnissen in Bereitstellungsumgebungen, Verbot gefährlicher Workflow-Trigger. Dies sind arbeitsintensive Aufgaben, die hohe Fachkenntnisse erfordern.
CycloneDX führte in Version 1.5 formulation ein und hat es seitdem kontinuierlich erweitert, wodurch das Format eine Möglichkeit erhielt, Build-Pipelines als strukturierte Daten zu beschreiben — die Werkzeuge, Actions, Umgebungen und Konfigurationen, die an der Erstellung eines Artefakts beteiligt sind. Das befindet sich im Ökosystem noch in einem frühen Stadium, aber die Richtung ist klar: Build-Prozesse selbst sind Komponenten der Lieferkette und sollten als solche inventarisiert werden.
Ein SBOM, das Formulation-Daten enthält, könnte Teile von Astrals CI/CD-Härtung für nachgelagerte Verbraucher besser auditierbar machen, sofern die Tooling-Unterstützung vorhanden ist. Anstatt sich vollständig auf die Darstellung eines Projekts zu verlassen, könnten Verbraucher strukturierte Build-Metadaten zusammen mit anderen Lieferkettenartefakten prüfen. Das schafft auch Verantwortlichkeit: Wenn Ihr Build-SBOM eine nicht gepinnte Action zeigt, sinkt Ihr SBOM-Qualitätswert — und genau diese Art von Signal soll unser SBOM-Qualitätstool sbomqs sichtbar machen.
Schwachstellenmanagement in der Tiefe der Abhängigkeiten
Astral beschreibt die Pflege sozialer Verbindungen mit Projekten wie dem Python Security Response Team und PyPA, um Schwachstelleninformationen projektübergreifend auszutauschen — zum Beispiel, wenn ein Bericht zu pip auch uv betrifft.
Dies ist ein sozialer Prozess zur Lösung eines Datenproblems. Mit SBOMs wird die Schwachstellenkorrelation über Projekte hinweg deutlich systematischer. Wenn sowohl pip als auch uv eine gemeinsame Komponente nutzen und diese Komponente eine CVE hat, kann eine SBOM-fähige Schwachstellenplattform beide Projekte gleichzeitig kennzeichnen. Das ersetzt keine Mailinglisten, Vertrauensbeziehungen oder koordinierte Offenlegung, reduziert aber, wie viel davon von ihnen abhängt.
Bei Interlynk macht unsere Schicht für Schwachstellenintelligenz genau das. Wir gleichen SBOM-Komponenten mithilfe von PURLs und CPEs mit NVD, OSV und Herstellerhinweisen ab, und wir behandeln die schwierigen Randfälle — falsch positive Treffer durch Distro-Backports, eingebundene Forks mit nicht standardisierter Versionierung, CPE-Abdeckungslücken bei eingebetteten und Nischenkomponenten — die ein naives Schwachstellen-Matching unzuverlässig machen.
VEX (Vulnerability Exploitability eXchange) fügt hier eine weitere Ebene hinzu. Wenn Astral feststellt, dass eine CVE in einer Abhängigkeit uv tatsächlich nicht betrifft, weil der verwundbare Codepfad nicht erreichbar ist, kann diese Bewertung als VEX-Aussage erfasst und an die SBOM angehängt werden. Dadurch wird eine einmalige Triage-Entscheidung in ein wiederverwendbares, maschinenlesbares Artefakt verwandelt, von dem jeder nachgelagerte Verbraucher profitiert.
Die anderen 40 %: Was SBOMs nicht abdecken – und warum genau das der Punkt ist
Hier zeigt sich, warum die Ehrlichkeit „kein Allheilmittel“ wichtig ist. In unserer Analyse fällt ein erheblicher Teil von Astrals Sicherheitslage klar außerhalb des SBOM-Bereichs:
Organisatorische Kontrollen — Durchsetzung von 2FA, Einschränkung von Admin-Berechtigungen, Verbot für Admins, Schutzmechanismen zu umgehen. Das sind Probleme des Identitäts- und Zugriffsmanagements.
CI/CD-Trigger-Richtlinien —
pull_request_targetundworkflow_runorganisationsweit verbieten. Das ist Plattform-Governance.Vier-Augen-Freigabe für Releases — Eine menschliche Prozesskontrolle, die kein Dokumentformat ersetzen kann.
Kein Caching in Release-Builds — Eine Entscheidung zur Build-Richtlinie.
Isolation von GitHub Apps — Ein architektonisches Muster, um privilegierte Operationen von CI/CD zu trennen.
SBOMs behaupten nicht, diese Probleme zu lösen, und wer Ihnen etwas anderes sagt, 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 Aussagen über Artefakte, und das Vulnerability-Management 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 absichern.
Das große Ganze: 60 % sind viel
Was Astrals Beitrag beeindruckend macht, ist zugleich das, was ihn ernüchternd macht: der enorme Umfang an manueller Arbeit, institutionellem Wissen und maßgeschneiderten Werkzeugen, der erforderlich ist, um ein gut ausgestattetes Open-Source-Projekt abzusichern. Die meisten Projekte — insbesondere im Bereich Embedded Firmware und IoT, mit denen wir bei Interlynk arbeiten — verfügen nicht über die Ressourcen, dies nachzubilden.
SBOMs bringen Sie nicht auf 100 %. Nichts wird das. Sicherheit besteht aus Schichten, und wer ein Patentrezept verspricht, ignoriert den Anteil, der weiterhin menschliches Urteilsvermögen, organisatorische Disziplin und Kontrollen auf Plattformebene erfordert.
Aber der Bereich, den SBOMs abdecken — Abhängigkeits-Transparenz, Schwachstellenkorrelation, Release-Herkunft, Durchsetzung von Cooldown-Phasen, Auditierbarkeit von Builds, VEX-gesteuerte Triage — stellt den Teil der Lieferkettensicherheit dar, der automatisiert, gemessen und kontinuierlich überwacht werden kann, anstatt sich auf heldenhaften individuellen Einsatz zu verlassen. Und für die große Mehrheit der Projekte, die Astrals Investition nicht erreichen können, ist das oft der Unterschied zwischen einer vorhandenen Sicherheitslage und bloßer Hoffnung.
SBOMs sind kein Allheilmittel. Sie sind das Fundament, das alles andere überprüfbar macht.