Ein Softwarepaket ist schnell heruntergeladen. Schwieriger ist die Frage, ob die Datei tatsächlich aus dem behaupteten Projekt und seinem vorgesehenen Bauprozess stammt. Ein Projektname oder ein grünes Symbol neben einem Download beantwortet das nicht von selbst. Digitale Herkunftsnachweise sollen die Verbindung zwischen fertiger Datei und Herstellungsprozess überprüfbar machen.
Dafür gibt es inzwischen konkrete Umsetzungen in mehreren Softwareökosystemen. GitHub stellte Artifact Attestations im Mai 2024 vor, PyPI ergänzte digitale Attestationen im November desselben Jahres, und npm dokumentiert heute die Verbindung von vertrauenswürdigem Veröffentlichen und Provenance. Zusammen zeigen diese Schritte eine Verschiebung: Vertrauen wird stärker am einzelnen ausgelieferten Paket befestigt. Die Nachweise bleiben allerdings eng begrenzt. Sie können einen Ursprung bestätigen, ohne den Inhalt für gut oder ungefährlich zu erklären.
Zwischen Quellcode und Download bleibt eine Lücke
Ein öffentliches Quellcodeprojekt und eine daraus angebotene Datei sind zwei verschiedene Gegenstände. Der Quellcode zeigt, was ein Projekt enthält. Der Download zeigt, was jemand tatsächlich bereitstellt. Dazwischen liegen ein Bauprozess, seine Umgebung und ein Veröffentlichungsschritt. Wer nur das Repository betrachtet, hat diesen Übergang noch nicht geprüft.
Diese Lücke ist besonders anschaulich bei einem gedachten Werkzeug, dessen Quellcode man bereits gelesen hat. Auf einer Paketplattform erscheint eine neue Version mit derselben Bezeichnung. Um beide Gegenstände sinnvoll zu verbinden, braucht es mehr als den passenden Namen: Welche Quellfassung wurde verwendet, welcher Ablauf hat gebaut und welche konkrete Datei kam dabei heraus?
Ein Herkunftsnachweis ergänzt solche Angaben um eine überprüfbare Bindung. Der kryptografische Fingerabdruck der Datei macht erkennbar, auf welche Bytes sich der Nachweis bezieht. Die zugehörige Identität und die Aussagen über den Bauprozess müssen ebenfalls überprüft werden. Ein gültiger Nachweis für eine andere Datei hilft schließlich ebenso wenig wie eine korrekte Adresse auf dem falschen Paket.
Was die Plattformen tatsächlich umsetzen
GitHub beschrieb in Introducing Artifact Attestations das Erzeugen und Prüfen signierter Attestationen für Ergebnisse aus GitHub Actions. Damit wird ein bestehender automatischer Bauablauf zum Ort, an dem Herkunftsinformationen erzeugt werden können. Wichtig ist die zweite Hälfte: Die Informationen müssen auf der Empfängerseite geprüft werden. Ihr bloßes Vorhandensein erzwingt noch keine Entscheidung beim Download.
Die Plattform PyPI erläuterte mit PyPI now supports digital attestations die Einführung digitaler Attestationen für Python-Pakete. Diese können veröffentlichte Dateien mit Angaben zur Projekt- und Workflowidentität verbinden. Die aktuelle PyPI-Dokumentation beschreibt das Modell als überprüfbare Verbindung zwischen Paketdatei und Herkunft. Daraus wird keine Pflicht abgeleitet, dass bereits jede angebotene Python-Datei einen solchen Nachweis besitzt.
npm verbindet in Trusted publishing for npm packages das Veröffentlichen mit kurzlebiger Identitätsbestätigung über OpenID Connect. Ein erlaubter automatischer Ablauf kann sich dadurch gegenüber der Plattform ausweisen, statt dauerhaft ein klassisches Veröffentlichungstoken mitzuführen. Die automatische Erzeugung von Provenance hängt vom unterstützten CI-Anbieter ab. Trusted Publishing und Provenance sind daher verwandte Funktionen, deren Umfang konkret geprüft werden muss.
Bei Viewing package provenance kann npm Herkunftsinformationen zum Paket, zum Workflow und zur Quellfassung anzeigen. Solche Angaben erleichtern den Vergleich zwischen erwartetem Projekt und tatsächlichem Veröffentlichungsweg. Sie ersetzen weder eine Prüfung des Quellcodes noch die Entscheidung, welchem Workflow man überhaupt vertrauen möchte.
Identität ist noch keine Qualität
Der Nutzen eines Nachweises wird klarer, wenn man seine Grenzen an zwei erfundenen Fällen prüft. Im ersten Fall hat jemand eine Datei nach dem Bau verändert. Ein Nachweis, der die ursprünglichen Bytes bindet, passt dann nicht mehr zur veränderten Datei. Die Prüfung kann den Unterschied sichtbar machen, ohne den Programmcode inhaltlich zu verstehen.
Im zweiten Fall enthält das Projekt selbst eine schädliche Änderung, und der reguläre Bauprozess verarbeitet sie wie vorgesehen. Der Herkunftsnachweis kann vollkommen gültig sein. Er bestätigt dann gerade, dass die Datei aus diesem Prozess stammt. Ob die Änderung erwünscht, fehlerhaft oder bösartig ist, bleibt eine andere Frage.
Dasselbe gilt für eine kompromittierte, aber formal erlaubte Bauumgebung. Eine nachvollziehbare Herkunft ist wertvoll, doch ihre Aussage hängt auch davon ab, wie diese Umgebung geschützt und freigegeben wird. Die präzise Aussage lautet deshalb: Diese Datei passt zu diesem nachgewiesenen Herstellungszusammenhang. Eine pauschale Aussage über sichere Software geht darüber hinaus.
Auch kurzlebige Identitätsbestätigungen lösen nicht jede Aufgabe. Sie verkleinern die Rolle langfristig verwalteter Zugangstoken, arbeiten aber weiterhin mit kryptografischen Schlüsseln und Zertifikaten. Wer das Verfahren als schlüssellos im wörtlichen Sinn beschreibt, könnte den Mechanismus missverstehen. Die Verbesserung liegt in der Verwaltung und Bindung der Identität, während die eigentliche Vertrauensentscheidung bestehen bleibt.
Aus einem Nachweis muss eine überprüfbare Erwartung werden
Ein Empfänger braucht einen Maßstab. Erwartet er eine Veröffentlichung aus einem bestimmten Repository und einem bestimmten Workflow, kann er den Nachweis daran messen. Ohne solche Erwartungen sagt eine gültige Signatur zunächst nur, dass eine bestätigte Identität eine bestimmte Aussage abgegeben hat. Ob diese Identität die richtige für den eigenen Zweck ist, ergibt sich daraus noch nicht.
Für ein Unternehmen kann das bedeuten, erlaubte Veröffentlichungswege festzulegen. Für einen einzelnen Entwickler kann es zunächst darum gehen, die Herkunft eines neu aufgenommenen Pakets genauer nachzuvollziehen. Beide nutzen denselben Grundgedanken, doch die automatisierte Durchsetzung und der Umfang der Prüfung unterscheiden sich.
Darin steckt auch eine organisatorische Verschiebung. Die Verantwortung endet nicht beim Team, das einen Nachweis erzeugt. Jemand muss festlegen, welche Nachweise akzeptiert werden, wie Abweichungen behandelt werden und was bei fehlenden Informationen geschieht. Ein System kann sehr gute Daten bereitstellen und dennoch wirkungslos bleiben, wenn niemand eine Konsequenz daran knüpft.
Die fehlende Attestation ist umgekehrt kein Beweis für bösartige Software. Kleine Projekte können andere Veröffentlichungswege nutzen oder die Funktion noch nicht eingerichtet haben. Herkunftsnachweise geben zusätzliche Information; die Bewertung fehlender Information muss zum Einsatzzweck passen. Eine strenge Unternehmensrichtlinie und eine private Erprobung können vernünftigerweise unterschiedliche Entscheidungen treffen.
Welche Entwicklung die Belege tragen
Die Signale sind über die Zeit verteilt: eine GitHub-Einführung 2024, ein unabhängiger Schritt im Python-Ökosystem später 2024 und die gegenwärtig dokumentierte npm-Umsetzung. GitHub und npm gehören zur selben Unternehmensfamilie und sind deshalb keine vollständig unabhängigen Marktsignale. PyPI erweitert das Bild um ein anderes Ökosystem. Die Belege zeigen reale Funktionen, keine repräsentative Verbreitungsquote.
Daraus lässt sich eine begrenzte These ableiten: Herkunftsinformationen werden enger mit ausgelieferten Softwaredateien und automatischen Veröffentlichungswegen verbunden. Nicht belegt ist, dass sich dadurch bereits eine bestimmte Zahl von Angriffen verhindern ließ oder dass alle Installationswerkzeuge die Angaben automatisch durchsetzen. Eine solche Wirkung müsste gesondert gemessen werden.
Die überzeugendste Weiterentwicklung wäre deshalb nicht bloß ein weiteres Abzeichen auf einer Paketwebseite. Sie müsste die Verbindung zwischen Datei, erwarteter Identität und nachvollziehbarem Prozess leichter überprüfbar machen. Ebenso wichtig wären verständliche Fehlermeldungen und klare Zuständigkeiten, wenn der Nachweis nicht zur Erwartung passt.
Für Leser verändert sich damit eine einfache Frage. Neben der Frage, was eine Software tut, steht nun stärker die Frage, wie genau dieser Download entstanden ist. Ein Herkunftsnachweis kann auf die zweite Frage eine belastbarere Antwort liefern. Erst zusammen mit Inhaltsprüfung und einer passenden Vertrauensentscheidung wird daraus ein sinnvoller Schutz für die Nutzung.
Quellen
- GitHub: Introducing Artifact Attestations—now in public beta (2024-05-02; GA-Update 2024-06-25)
- PyPI: PyPI now supports digital attestations (2024-11-14)
- PyPI: Digital attestations: Introduction
- npm: Trusted publishing for npm packages
- npm: Viewing package provenance
Für diesen Artikel wurden KI-gestützte Recherche- und Editierwerkzeuge verwendet. Der Inhalt wurde redaktionell geprüft.
