Bus-Faktor 1: Das Risiko in deiner Dependency-Liste

Nicht Vetting, sondern Bestandsaufnahme

Software Composition Analysis prüft, ob eine Dependency bekannte Schwachstellen enthält. Third-Party-Actions-Vetting prüft eine neue Action, bevor sie in die Pipeline kommt. Beides sind Prüfungen am Zeitpunkt der Aufnahme.

Dieser Artikel behandelt etwas anderes: Pakete, die längst in deiner package.json, requirements.txt oder go.mod stehen, produktiv laufen, keine bekannte Schwachstelle haben, und trotzdem faktisch am Durchhaltevermögen einer einzigen Person hängen. Das Risiko ist kein CVE. Es ist die Frage, was passiert, wenn diese Person aufhört, den Account verliert oder ihn verkauft. Als Kennzahl stand Bus-Faktor bereits in „Technische Schulden in der Pipeline“, dort als eine von fünf Inventar-Metriken neben Build-Dauer und Flaky Tests. Hier wird sie erstmals eigenständig behandelt, mit Vorfallshistorie und konkreten Gegenmaßnahmen.

Was Bus-Faktor 1 im Dependency-Baum bedeutet

Der Begriff Bus-Faktor beschreibt, wie viele Personen ein Projekt verlassen können (im Extremfall: vom Bus überfahren werden), bevor es faktisch zum Stillstand kommt. Bei vielen Open-Source-Paketen liegt dieser Wert bei 1: ein einzelner Mensch schreibt Code, reviewt Pull Requests, hat Publish-Rechte auf der Registry und beantwortet Issues. Das ist am Anfang eines Projekts normal. Problematisch wird es, wenn das Paket über Jahre zur stillen Grundlage in tausenden anderen Projekten wird, während sich an der Maintainer-Struktur nichts ändert.

Das Risiko ist doppelt: Verfügbarkeit (niemand patcht mehr, das Projekt stirbt langsam) und Sicherheit (ein einzelner kompromittierter Account oder eine einzelne überredete Person reicht, um bösartigen Code in die Lieferkette zu bekommen). Drei öffentlich dokumentierte Fälle zeigen beide Varianten.

Drei Vorfälle, die den Mechanismus zeigen

event-stream (2018): Der ursprüngliche Maintainer dominictarr hatte das npm-Paket event-stream nicht mehr aktiv weiterentwickelt und gab einem unbekannten Nutzer (right9ctrl) Publish-Zugriff. Dieser fügte in Version 3.3.6 die Abhängigkeit flatmap-stream hinzu: ein Paket ohne nennenswerte Download-Historie, das gezielten Schadcode gegen das Modul ps-tree enthielt. Der GitHub Security Advisory GHSA-mh6f-8j2x-4483 stuft den Fall als kritisch ein (CVSS 9.8).

ua-parser-js (2021): Ein npm-Account wurde übernommen, drei Versionen (0.7.29, 0.8.0, 1.0.0) mit eingeschleustem Schadcode wurden veröffentlicht. CISA warnte am 22. Oktober 2021 vor dem Paket (CVE-2021-4229), der zugehörige Sicherheitshinweis GHSA-pjwm-rvh2-c87w forderte explizit, jedes System mit diesen Versionen als kompromittiert zu behandeln.

xz-utils (2024): Ein Nutzer unter dem Namen „Jia Tan“ baute laut Analyse von Akamai fast zwei Jahre lang über unauffällige Bugfix-Pull-Requests Vertrauen im xz-Projekt auf, erhielt schrittweise Commit- und später Release-Rechte und schleuste in den Versionen 5.6.0 und 5.6.1 eine Backdoor in liblzma ein, die SSH-Authentifizierung umgehen konnte. Entdeckt wurde sie am 29. März 2024 von Andres Freund wegen ungewöhnlich langsamer SSH-Logins: nicht durch ein Audit. CISA stufte den Fall mit CVSS 10 ein (CVE-2024-3094).

Keiner dieser drei Fälle wäre durch ein SCA-Scan oder ein Vetting bei der ersten Aufnahme aufgefallen: die Pakete waren zum Zeitpunkt der Kompromittierung längst etabliert.

Bus-Faktor im eigenen Bestand sichtbar machen

Drei Signale lassen sich ohne großen Aufwand aus dem bestehenden Dependency-Baum ziehen:

Registry-Metadaten: npm view maintainers bzw. der Maintainers-Eintrag auf PyPI zeigen, ob ein Paket einen oder mehrere Publish-Berechtigte hat. Ein einzelner Eintrag ist kein Fehler, aber ein Signal, das man für kritische Pakete festhalten sollte.
OpenSSF Scorecard, Check „Maintained“: vergibt die höchste Punktzahl nur, wenn es in den letzten 90 Tagen mindestens einen Commit pro Woche gab; Projekte, die diese Schwelle über längere Zeit reißen, fallen im Score sichtbar ab.
OpenSSF Scorecard, Check „Contributors“: verlangt für die Höchstpunktzahl Commits von Mitwirkenden aus mindestens drei unterschiedlichen Organisationen in den letzten 30 Commits, mit je mindestens fünf Commits pro Person. Ein Paket, das diesen Schwellenwert reißt, hat in der Praxis keine breite Trägerschaft: unabhängig davon, wie viele GitHub-Stars es hat.

Scorecard lässt sich als CLI oder GitHub Action gegen die eigene Dependency-Liste fahren und liefert diese Werte pro Repository, nicht nur als Gesamturteil.

Was konkret dagegen hilft

Für Pakete, die im eigenen System kritisch sind (Build-Kette, Auth, Krypto, CI-Tooling) und im Scorecard-Check als Einzelperson-Projekt auffallen, gibt es drei praktikable Reaktionen: keine davon ist „einfach austauschen“, das verschiebt das Problem nur:

Vendoring/Pinning mit Review-Pflicht: kritische Einzelpersonen-Pakete nicht automatisch per Dependabot/Renovate mergen lassen, sondern Updates manuell gegenlesen, bevor sie in den Build gehen.
Fork-Bereitschaft statt Fork-Aktion: einen eigenen, aktuell gehaltenen Mirror/Fork nur für den Ernstfall vorbereiten (Build- und Release-Pipeline testen), nicht produktiv parallel pflegen: das bindet sonst selbst wieder Kapazität an eine Einzelperson im eigenen Team.
Aktive Beobachtung statt einmaliger Prüfung: Release- und Commit-Aktivität des Pakets in ein Monitoring aufnehmen (z. B. über die Scorecard-API oder einen einfachen Cronjob gegen die Registry-API), damit ein Aussetzen des Maintainers auffällt, bevor der nächste Sicherheitsvorfall es tut.

Der Punkt ist nicht, jedes Einzelperson-Paket zu ersetzen: die meisten laufen jahrelang stabil. Der Punkt ist, zu wissen, welche der eigenen kritischen Pfade an genau einem Menschen hängen, bevor man es aus einem Advisory erfährt.

Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Alles Weitere richtet sich nach der Lage und läuft über drei Felder: Implementation, also Delivery und Nachweis modulweise in die Pipeline einziehen, AI Governance, also Nachvollziehbarkeit bei KI-gestützten Build- und Deployment-Schritten, und Maintenance, also die Frage, wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem mehr gehört. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Kontakt: mm@mhm-dl.de

Dein Blog zum Thema digitales Business