Zwei Jahre Vertrauen, eine Hintertür: Sicherheitschecks von Bibliotheken

Der wirksamste Angriff auf eine Lieferkette braucht keinen Einbruch. Er braucht Geduld. Jemand arbeitet an einem offenen Projekt mit, liefert über Jahre gute Arbeit und wird dafür Mitbetreuer. Erst danach kommt die Hintertür, versteckt in Testdaten, die beim Bauen der Software mitlaufen. Dieser Ablauf ist nicht ausgedacht: Er wurde 2024 in einer Kompressions-Bibliothek dokumentiert, die auf fast jedem Linux-System liegt [1].

Aufgefallen ist die Sache durch einen Zufall. Einem Entwickler kam eine Anmeldung an seinem eigenen Rechner eine halbe Sekunde zu langsam vor. Er ging der Sache nach.

Kein Auswahlkriterium hätte das gefangen. Das Projekt war alt, verbreitet, aktiv gepflegt und in jeder grossen Distribution enthalten. Wer hinter dem Namen des Mitbetreuers stand, ist bis heute ungeklärt.

So ehrlich muss ein Beitrag über Bibliotheksauswahl anfangen. Diesen einen Fall verhindert kein Verfahren. Fast alles andere lässt sich verhindern.

1. Die Lücke vor dem Gate

Unsere Lieferkette hatte bis vor kurzem zwei Prüfungen. Ein Lizenz-Gate liest die Lizenz jeder Abhängigkeit. Nur eine feste Liste unbedenklicher Lizenzen kommt durch, etwa MIT und Apache. Lizenzen mit Copyleft-Pflicht fallen durch. Ein Namens-Gate prüft jeden neu hinzugekommenen Paketnamen gegen eine Sperrliste, gegen Tippfehler-Abstände zu bekannten Paketen und gegen den Nachweis, dass der Name überhaupt existiert.

Beide greifen erst, wenn die Bibliothek schon drin ist. Die Entscheidung davor war ungeprüft. Niemand musste begründen, warum die Wahl auf diese Bibliothek fiel. Niemand hielt fest, was geprüft worden war. Der Schritt mit dem grössten Hebel war der einzige ohne Protokoll.

2. Der Widerspruch

Die stärksten Hinweise auf Schadcode brauchen Live-Daten. Wie alt ist das Paket wirklich. Wie viele andere Projekte hängen daran. Liegt eine ungepatchte Sicherheitsmeldung vor. Gibt es einen Herkunftsnachweis für die veröffentlichte Datei. Diese Werte ändern sich täglich und stehen in keinem Repository.

Die stärksten Prüfungen dürfen trotzdem nicht ins Netz. Der Grund ist ganz praktisch. Wer beim Prüfen eine fremde Datenquelle abfragt, macht sich von ihr abhängig. Ist die Quelle gerade nicht erreichbar, fällt die Prüfung aus. Wer ihre Antworten beeinflussen kann, täuscht die Prüfung. Und dieselbe Zeile Code bekommt an zwei Tagen zwei verschiedene Urteile. Ein Ergebnis, das gestern grün war und heute rot ist, obwohl niemand den Code angefasst hat, taugt nichts.

Genau daran ist die Auswahl bisher ungeprüft geblieben. Man braucht die Daten aus dem Netz. Man darf sie beim Prüfen nicht holen.

3. Die Auflösung: zwei Phasen mit verschiedenen Regeln

Der Ausweg teilt die Prüfung in zwei Schritte. Einer darf ins Netz, der andere nie.

Einmal mit Netz, beim Hereinkommen. Ein Mensch startet die Prüfung, sobald eine Bibliothek zur Aufnahme vorgeschlagen wird. Sie darf ins Netz. Lizenz, Sicherheitsmeldungen, Bewertungen, Nutzerzahlen und Zeitstempel kommen aus einer Quelle, die diese Werte bündelt [2]. Jeder Wert wird zusammen mit dem Zeitpunkt seines Abrufs in ein Protokoll geschrieben. Dieses Protokoll kommt als Datei ins Repository.

Danach für immer ohne Netz. Die Prüfung in der Baustrecke fragt nichts mehr ab. Sie vergleicht nur noch das Protokoll mit den tatsächlichen Abhängigkeiten: Hat jede neu hinzugekommene Bibliothek ein gültiges Protokoll. Sind die Fristen eingehalten. Ist die Freigabe unterschrieben.

Das Protokoll ist der Kniff. Es hält nachlesbar fest, was zu einem bestimmten Zeitpunkt im Netz stand. Zwei Rechner mit demselben Stand kommen damit zum selben Urteil, ohne Netz, auf Dauer.

4. Was hart blockiert

Fünf Befunde beenden die Prüfung sofort, unabhängig von allem anderen:

• Die Lizenz ist verboten oder unbekannt. Unbekannt zählt als Befund, eine nicht nachweisbare Lizenz ist keine Freigabe.
• Der Name steht auf der Sperrliste oder liegt verdächtig nah an einem bekannten Paketnamen.
• Für die geprüfte Fassung liegt eine bekannte, ungepatchte Schwachstelle hoher Schwere vor.
• Es gibt kein öffentliches Quell-Repository. Was niemand lesen kann, prüft auch niemand.
• Das Paket ist jünger als 90 Tage.

Eine unterschriebene Ausnahme mit Begründung und Namen kann jeden dieser Befunde aufheben. Einen nicht: Die Sperrliste bleibt unantastbar. Wer sie aufweichen dürfte, bräuchte sie nicht.

5. Was gewichtet wird und warum es nie blockiert

Der Katalog ist nicht hier erfunden worden. Die OpenSSF beschreibt in ihrem Leitfaden zur Bewertung offener Software dieselben Fragen: Wird das Projekt gepflegt, werden Fehler zeitnah behoben, ist die Lizenz klar [5]. Das Rahmenwerk S2C2F von Microsoft, seit 2022 bei der OpenSSF, ordnet die Aufnahme fremder Software als eigene Disziplin ein und nennt die Prüfung beim Hereinkommen als erste von acht Praktiken [6]. Was hier dazukommt, ist die Verbindlichkeit: aus einer Empfehlung wird eine Datei, die ein Gate liest.

Neben den Ausschlusskriterien steht eine Punktzahl aus rund einem Dutzend Signalen. Sie warnt und blockiert nie. Unter einem Schwellenwert wird das Protokoll nur mit ausdrücklicher menschlicher Freigabe gültig, mit Namen und Begründung.

Der Grund dafür steht in einem anderen Beitrag dieses Blogs: Wird eine Kennzahl zum Ziel, taugt sie nicht mehr als Kennzahl [3]. Reputation ist die käuflichste Kennzahl der Lieferkette. Nutzerzahlen lassen sich kaufen, Sterne auch, Commits erst recht. Eine Punktzahl, die blockiert, ist eine Punktzahl, die jemand angreift. Deshalb fragt keine der fünf harten Regeln danach, wie beliebt eine Bibliothek ist. Die Punktzahl allein entscheidet nichts.

Wir bei Betteryields entscheiden in neun von zehn Fällen nach Reputation. Eine Bedingung macht dabei den Unterschied: Wir lesen sie nie auf der Projektseite, sondern immer von hinten. Auf seine eigene Webseite schreibt ein Projekt, wen es als Nutzer nennen möchte. Die Gegenprobe zählt die Projekte, die tatsächlich davon abhängen.

Vier weitere Signale prüfen wir dazu:

Wie viele Leute arbeiten daran und wie verteilt. Kommen 90 % der Commits von einer Person, ist das Projekt verwaist, sobald diese Person geht. Viele Namen im Verlauf nützen nichts, wenn einer davon alles schreibt.

Wann war der letzte Commit. Die Schwelle hängt an der Art des Projekts. Bei einem komplexen, lebenden Projekt erwarten wir Aktivität in der letzten Woche. Bei einer ausentwickelten Bibliothek, die höchstens noch Fehler behebt, sind drei bis vier Monate in Ordnung. Jahre sind es nie. Dagegen hilft auch der Name eines grossen Herstellers nicht.

Wie steht es um die offenen Meldungen. Alte Funktionswünsche dürfen offen liegen. Echte Fehler, älter als ein Jahr, sind ein Warnzeichen.

Wer trägt das Projekt. Eine Open-Source-Stiftung im Rücken ist ein starker Pluspunkt. Mitarbeit unter Firmenkonten statt Privatkonten ebenso. Aufnahme in den geprüften Teil einer grossen Linux-Distribution auch, weil dort jemand regelmässig hinschaut.

6. Der Erwartungswert

Ein Signal steht quer zu allen anderen, weil es nichts zählt, sondern liest.

Die Frage lautet: Tut die Bibliothek genau das, was sie tun müsste. Eine Bibliothek zum Einlesen von Bildern muss auf das Dateisystem zugreifen, das ist erwartbar. Wenn dieselbe Bibliothek eine Netzverbindung aufbaut, passt das nicht zu ihrem Zweck. Der erste Blick gilt deshalb immer den Importen. Der nächste Blick gilt dem Nachladen zur Laufzeit, weil dynamisch nachgeladener Code sich der Prüfung entzieht.

Bei Millionen von Zeilen lohnt dieser Blick nicht. Bei kleinen Bibliotheken lohnt er. Ein Sprachmodell beschleunigt ihn. Deshalb läuft die Sichtung nur unterhalb einer Zeilenschwelle, in einer abgeschotteten Umgebung. Ihr Ergebnis landet als Text im Protokoll.

Dieses Verfahren hat eine Grenze. Sie liegt in seiner Unschärfe: Wer gut genug ist, täuscht sie. Der Fall vom Anfang beweist das.

7. Die Wartefrist

Neu veröffentlichte Fassungen kommen 14 Tage zu spät ins Projekt, mit Absicht.

Der Grund liegt in der Zeitrechnung der Angriffe. Bei der Übernahme des npm-Pakets axios wurden die bösartigen Fassungen rund drei Stunden nach ihrer Veröffentlichung entdeckt [4]. Beim Angriff auf s1ngularity waren die verseuchten Pakete rund vier Stunden verfügbar [4]. Eine Wartefrist von zwölf Stunden hätte beide Angriffe vollständig geblockt, so die Analyse [4]. Als Faustwert empfiehlt sie eine Woche.

Wer wartet, lässt die Weltöffentlichkeit für sich prüfen. Der Preis ist ehrlich zu nennen: Auch der dringende Sicherheits-Patch kommt 14 Tage zu spät. Dafür gibt es die unterschriebene Ausnahme, die genau eine Fassung freigibt.

8. Die Herkunftsfrage

Ein Kriterium ist bewusst nicht automatisiert.

Wer steht hinter dem Projekt. Manche Bibliotheken gehören einer Firma, die selbst kaum mehr ist als eine Adresse, während die Arbeit ganz woanders geschieht. Das allein ist kein Ausschlussgrund, sondern ein Anlass zum genaueren Hinsehen. Der erweiterte Check zählt. Er fällt oft beruhigend aus. Bei einer solchen Bibliothek ergab er, dass ein grosser Hersteller sie in eigenen Produkten einsetzt. Bei einer anderen fand ein vollständiges Quellcode-Review nichts Kritisches.

Daraus wird kein automatisches Urteil. Nach Herkunft erst recht keines. Das Protokoll hat ein Feld für diese Recherche, das ein Mensch ausfüllt. Das Gate erzwingt nur, dass das Feld nicht leer ist. Ein leeres Feld kostet Punkte. Ein Urteil spricht es nie. Bei einzelnen, vorab benannten Fällen folgt eine Auflage statt eines Verbots: Aufnahme nur mit wiederkehrender Code-Prüfung.

Die Zurückhaltung hat einen nüchternen Grund. Die Güte einer Zeile Code hängt an ihrem Inhalt, nicht an ihrer Herkunft. Wer nach Landkarte urteilt, prüft nicht, sondern rät.

9. Vier Ausgänge statt zwei

Die Prüfung endet mit einem von vier Ergebnissen.

Aufnehmen. Der Regelfall.

Ablehnen. Das Protokoll bleibt liegen. Taucht der Name später wieder in den Abhängigkeiten auf, ist das ein Befund. Eine Ablehnung, die man vergisst, wird beim nächsten Mal zur Aufnahme.

Ausnahme. Aufnahme trotz eines Befunds, mit Begründung und Namen im Protokoll.

Forken und selbst pflegen. Der interessanteste Ausgang. Wer eine kleine Bibliothek selbst geprüft hat, kann sie kopieren und ab dann selbst verantworten. Das ist nicht dasselbe wie Eigenbau: Das Rad bleibt erfunden, nur die Wartung wandert ins Haus. Das Protokoll verlangt dann zwei zusätzliche Angaben: wo der Fork liegt und wer ihn pflegt.

10. Eine ehrliche Grenze

Über allem steht ein Satz, den wir uns selbst sagen: Trotz aller Kriterien wird es uns früher oder später treffen.

Das Verfahren senkt die Trefferwahrscheinlichkeit und beseitigt sie nicht. Gefangen wird der Tippfehler-Angriff, das frisch angelegte Paket, die verwaiste Bibliothek, die verbotene Lizenz und die bekannte Schwachstelle. Nicht gefangen wird, wer jahrelang Vertrauen aufbaut.

Was es zusätzlich leistet, ist unscheinbarer und im Zweifel wichtiger. Jede aufgenommene Bibliothek hat ab jetzt ein Protokoll mit Datum, Werten und einem Namen darunter. Taucht ein ähnlicher Fall wieder auf, steht dort, was zum Zeitpunkt der Entscheidung bekannt war und wer sie getroffen hat. Aus einer Liste von Namen ist eine Akte geworden.

11. Quellen

[1] National Vulnerability Database, "CVE-2024-3094", 2024. Hintertür in einer weit verbreiteten Kompressions-Bibliothek, öffentlich gemeldet am 29. März 2024.

[2] Google Open Source Insights, "Announcing the deps.dev API: critical dependency data for secure supply chains", Google Online Security Blog, 2023.

[3] Betteryields, "Goodharts Gesetz: warum Kennzahlen kippen und was Spec Coding dagegen braucht", agentic-gates Blog, 2026.

[4] K. Toomey, "The case for dependency cooldowns in a post-axios world", Datadog Security Labs, 2026.

[5] Open Source Security Foundation, "Concise Guide for Evaluating Open Source Software", OpenSSF Best Practices Working Group, 2022.

[6] Open Source Security Foundation, "Secure Supply Chain Consumption Framework (S2C2F)", 2022.

12. Download: die Freigabe-Checkliste

Die Freigabe einer neuen Fremdbibliothek von oben nach unten. Die ersten fünf Punkte beenden die Prüfung sofort, die weichen Kriterien darunter tragen nur zum Urteil bei.

Hart, jeder Punkt beendet die Prüfung

Lizenz. Verboten oder unbekannt heißt Befund. Eine nicht nachweisbare Lizenz ist keine Freigabe.

Name. Steht er auf der Sperrliste oder liegt er verdächtig nah an einem bekannten Paketnamen, ist Schluss.

Bekannte Schwachstelle. Für die geprüfte Fassung liegt eine ungepatchte Lücke hoher Schwere vor.

Quellcode. Es gibt kein öffentliches Quell-Repository. Was niemand lesen kann, prüft auch niemand.

Alter. Das Paket ist jünger als 90 Tage.

Eine unterschriebene Ausnahme mit Begründung und Namen hebt jeden dieser Befunde auf. Einen nicht: die Sperrliste.

Weich, jeder Punkt geht ins Urteil ein

Wer schreibt daran. Kommen neun von zehn Commits von einer Person, ist das Projekt verwaist, sobald diese Person geht.

Letzter Commit. Bei einem lebenden Projekt erwarten wir Aktivität in der letzten Woche. Bei einer ausentwickelten Bibliothek sind drei bis vier Monate in Ordnung. Jahre nie.

Offene Meldungen. Alte Funktionswünsche dürfen liegen. Echte Fehler, älter als ein Jahr, sind ein Warnzeichen.

Wer trägt es. Eine Stiftung im Rücken zählt. Mitarbeit unter Firmenkonten zählt. Aufnahme in den geprüften Teil einer großen Distribution zählt.

Vor dem Einbau

Wartefrist. Neue Fassungen kommen 14 Tage zu spät ins Projekt, mit Absicht. Bei zwei untersuchten Angriffen auf Paketverzeichnisse waren die verseuchten Fassungen nur Stunden verfügbar.

Protokoll. Jeder abgefragte Wert steht mit dem Zeitpunkt seines Abrufs in einer Datei im Repository. Danach fragt die Baustrecke nichts mehr ab, sie vergleicht nur noch.

Ausgang. Aufnehmen, ablehnen, Ausnahme mit Unterschrift, oder forken und selbst pflegen. Eine Ablehnung, die man vergisst, wird beim nächsten Mal zur Aufnahme.