Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
In Horrorfilmen sind die furchterregendsten Bedrohungen nicht diejenigen, die die Haustür eintreten – es sind diejenigen, die bereits drinnen sind, die Geister, die sich in den Wänden verstecken und die niemand bemerkt hat.
Moderne Software-Lieferketten funktionieren genauso.Wenn wir heute Anwendungen entwickeln und ausliefern, vertrauen wir in der Regel unserem Team und den Bibliotheken, die wir bewusst installieren.
BDoch unter der Oberfläche deiner package.json verbirgt sich ein riesiger, unsichtbarer Eisberg aus Code.Das ist die Welt der transitiven Abhängigkeiten, und genau dort beginnen viele moderne Supply-Chain-Angriffe.
Die Illusion der Kontrolle: Deine direkten Abhängigkeiten
Wenn Sie folgenden Befehl ausführen npm installausführst, fügst du vielleicht fünf oder zehn Bibliotheken hinzu, die du kennst und denen du vertraust. Das sind deine direkten Abhängigkeiten. Du hast dir ihre GitHub-Sterne angesehen, ihre Wartungshäufigkeit überprüft und bist von ihnen überzeugt.
Allerdings könnte jede dieser fünf Bibliotheken auf zehn weitere angewiesen sein. Und diese zehn wiederum auf weitere zehn. Ehe man sich versieht, kann sich eine „einfache“ Web-App leicht auf über 1.000 Pakete ausweiten, die in Ihrem node_modules Verzeichnis. Das sind Ihre transitiven Abhängigkeiten, die „Pakete Ihrer Pakete“, und sie machen den Großteil des Codes aus, den Sie tatsächlich in die Produktion ausliefern.
Wenn Sie überprüfen möchten, welche direkten Abhängigkeiten Sie installiert haben, ohne dafür Ihre package.json, können Sie npm lsausführen. Dieser Befehl listet im Terminal die von Ihnen installierten direkten Abhängigkeiten auf.
Warum transitive Abhängigkeiten der perfekte „Geist“ sind
Die Gefahr transitiver Abhängigkeiten besteht darin, dass sie im Arbeitsablauf eines durchschnittlichen Entwicklers weitgehend unsichtbar bleiben. Wir überprüfen selten die dritte oder vierte Ebene unseres Abhängigkeitsbaums. Angreifer wissen das und haben ihre Taktik geändert, um drei spezifische „Schwachstellen“ auszunutzen.
Typo-Squatting:
Registrierung eines Paketnamens, der fast identisch mit einem beliebten Namen aussieht (z. B. lodash vs. lodas_h). Ein kleiner Tippfehler in einer tief liegenden Abhängigkeit, und schon läuft ein bösartiges Skript in Ihrer Build-Pipeline.
Nehmen wir an, Sie möchten Express installieren, um eine API oder einen Backend-Dienst zu erstellen. Aus Gewohnheit öffnen Sie Ihr Terminal, um `express` zu installieren, und statt `npm install express` zu tippen, geben Sie `npm install expres` ein. Der Unterschied besteht darin, dass Ihnen das zweite „s“ im Wort fehlt. Wahrscheinlich werden Sie Ihren `node_modules`-Ordner nicht überprüfen – Sie vertrauen einfach darauf, dass das Paket korrekt installiert wurde. Genau hier können Probleme entstehen.
Achten Sie stets darauf, welche Pakete Sie installieren. Wenn möglich, bevorzugen Sie Pakete mit eingeschränkter Gültigkeit. Scoped-Pakete werden oft aus privaten oder von der Organisation kontrollierten Registern, was eine zusätzliche Vertrauensstufe bietet.
Verwirrung hinsichtlich der Abhängigkeiten
Ein Build-System dazu bringen, eine bösartige „öffentliche“ Version eines Pakets anstelle Ihrer „privaten“ internen Version abzurufen. Pakete mit Bereichsangabe tragen dazu bei, Angriffe durch Verwechslungen bei Abhängigkeiten zu mindern. Ein Paket mit Bereichsangabe sieht in etwa so aus: `@scope/your-awesome-package`.
Wenn eine Organisation sowohl private (interne) als auch öffentliche (npm) Registries nutzt, veröffentlicht ein Angreifer ein öffentliches Paket mit demselben Namen wie ein privates, jedoch mit einer höheren Versionsnummer. Laut Spectral„sind fast 49 % der Unternehmen dem Risiko eines Dependency-Confusion-Angriffs ausgesetzt.“
Das „Verfluchte“-Update
Ein Angreifer verschafft sich Zugriff auf eine legitime, kleine Utility-Bibliothek, die von einem großen Framework als Abhängigkeit genutzt wird. Ein Beispiel für ein solches kleines Utility wäre das Paket `@ctrl/tinycolor`. Ein aktuelles Beispiel ist der Shai-Hulid-Supply-Chain-Angriff, bei dem eine kompromittierte Utility-Bibliothek zur Verbreitung von Schadcode genutzt wurde. Sie veröffentlichen einen „Patch“, der eine Hintertür enthält. Plötzlich sind über Nacht Tausende von Apps „besessen“, ohne dass ein einziger Entwickler seine eigene `package.json` geändert hat.
Eine Hintertür (ursprünglich „Trapdoor“ genannt) ist eine versteckte Methode, um die normale Authentifizierung zu umgehen und privilegierten Zugriff auf ein System zu erlangen. Malwarebytes hat einen großartigen Artikel über Backdoors, und dieses Zitat fasst es sehr gut zusammen.
„Eine Hintertür bezeichnet jede Methode, mit der autorisierte und nicht autorisierte Benutzer die üblichen Sicherheitsmaßnahmen umgehen und sich Zugriff auf einem Computersystem, einem Netzwerk oder einer Softwareanwendung auf höchster Ebene (auch als Root-Zugriff bezeichnet) verschaffen können.“
Die Geschichte der Hintertüren
Hintertüren, auch als „Trapdoors“ bezeichnet, tauchten erstmals in den 1960er- und 1970er-Jahren auf. Ursprünglich wurden Hintertüren entwickelt, um legitimen Softwareentwicklern während der Systementwicklung und bei Fehlerbehebungen Zugriff auf Wartungs- und Fehlerbehebungsfunktionen sowie die Umgehung von Authentifizierungsverfahren zu ermöglichen.
Hintertüren entwickelten sich erstmals in den 1980er Jahren. Sie wurden zunehmend für böswillige Aktivitäten genutzt. Einer der bekanntesten Vorfälle der 1980er Jahre war der Morris-Wurm von 1988, der Systeme im frühen Internet infizierte. Robert Morris entwickelte den Morris-Wurm im Jahr 1988. Der Wurm infizierte zahlreiche Systeme im Internet, darunter die NASA, Harvard und Stanford. Morris verstieß gegen den Computer and Fraud Abuse Act von 1986, doch obwohl er verurteilt wurde, musste er keine Gefängnisstrafe verbüßen.
In den 1990er Jahren nutzte die Regierung Hintertüren in größerem Umfang. Der Clipper-Chip war ein gescheiterter Versuch, die Kommunikation abzuhören. Es kam lediglich ein einziges Telefon auf den Markt, und 1996 wurde das Projekt aufgegeben.
Seit den 2000er Jahren bis hin in die 2020er Jahre nutzen Hacker Hintertüren für groß angelegte Angriffe im gesamten Internet. Sie haben sogar begonnen, Cloud- und IoT-Geräte zu infiltrieren.
Auswirkungen von Backdoor-Angriffen
Hintertüren sind gefährlich, weil sie verborgen sind. In der Populärkultur werden Hintertüren schon seit langem thematisiert – im Film „WarGames“ aus dem Jahr 1983 gibt es sogar eine Szene, in der erklärt wird, wie versteckte Zugriffsmechanismen funktionieren. Manchmal sind sie so tief verborgen, dass es Monate oder Jahre dauern kann, sie aufzuspüren.
Über npm audit
Während Tools wie npm audit ein guter erster Schritt sind, finden sie oft nur die Geister, die bereits Chaos angerichtet haben. Um Ihre Lieferkette wirklich zu sichern, müssen wir von reaktiven zu proaktiven Verhaltensweisen.
Integrität der Sperrdatei
Bearbeite deine package-lock.json oder yarn.lock als geschütztes Dokument. Ignoriere niemals Änderungen daran und stelle sicher, dass deine CI/CD-Pipeline diese Versionen strikt durchsetzt. Beachte dabei, dass du deine Lock-Dateien immer committen solltest. Wenn du deine Lock-Datei committest, „sicherst“ du die Versionen der installierten Pakete, sodass jeder im Team genau dieselben verwendet.
Integrität bedeutet jedoch mehr als nur die Übereinstimmung der Versionsnummern. Die Sperrdatei enthält eine aufgelöste URL und eine Integritäts- (in der Regel SHA-512). Dieser Hash ist Ihr wichtigster Schutz gegen „Registry Poisoning“. Wenn eine Registry kompromittiert wird und ein Angreifer ein legitimes Paket durch ein bösartiges derselben Version ersetzt, ändert sich der Hash. Durch die Verwendung von npm clean-install (oder npm ci) in Ihren Build-Pipelines verwenden, schlägt die Installation fehl, wenn der Hash des heruntergeladenen Pakets nicht mit dem Lockfile übereinstimmt. Dies entspricht einem „digitalen Fingerabdruck“ für Ihren Code; wenn der Fingerabdruck nicht übereinstimmt, wissen Sie, dass der Angreifer die Datei manipuliert hat.
Darüber hinaus sollten Sie sich vor „Lockfile-Injection“-Angriffen in Acht nehmen. Dabei reicht ein böswilliger Mitwirkender einen Pull Request ein, der wie eine einfache Aktualisierung der Abhängigkeiten aussieht, jedoch eine geänderte Lockfile-Datei enthält, die für eine transitive Abhängigkeit auf eine bösartige URL verweist. Überprüfen Sie Änderungen an Ihrer Lockfile-Datei stets genauso gründlich wie Ihren Quellcode. Wenn ein PR 5.000 Zeilen zu einer Lockfile-Datei für einen „kleinen Patch“ hinzufügt, ist es an der Zeit, Fragen zu stellen.
SBOMs (Software-Stücklisten)
Wenn Sie nicht wissen, was sich in Ihrer „Abhängigkeitsgalaxie“ befindet, können Sie diese nicht schützen. Durch die Erstellung einer SBOM erhalten Sie einen klaren Überblick über jede Komponente in Ihrer Software-Lieferkette. Stellen Sie sich eine SBOM als die „Zutatenliste“ auf der Rückseite einer Tiefkühlpizza. Wenn Sie später herausfinden, dass „roter Farbstoff Nr. 40“ giftig ist, können Sie Ihre Vorratskammer überprüfen und sofort wissen, welche Produkte Sie wegwerfen müssen. Wenn in der Softwarebranche eine neue CVE (Common Vulnerabilities and Exposures) für eine tiefliegende transitive Abhängigkeit bekannt gegeben wird, ermöglicht Ihnen eine SBOM, Ihr gesamtes Ökosystem in Sekundenschnelle zu durchsuchen, anstatt jedes Projekt manuell zu prüfen.
Es gibt zwei wichtige Industriestandards für SBOMs: SPDX (Software Package Data Exchange) und CycloneDX. Während SPDX ein ISO-Standard ist, der häufig für Lizenzierung und Compliance bevorzugt wird, ist CycloneDX ein schlankes, auf Sicherheit ausgerichtetes Format, das speziell für Anwendungssicherheit und Lieferkettenanalysen entwickelt wurde.
Eine wirklich ausgereifte Sicherheitsstrategie beschränkt sich nicht darauf, lediglich eine SBOM zu erstellen, sondern nutzt diese in Verbindung mit VEX (Vulnerability Exploitability eXchange). VEX ist ein Begleitdokument, das Ihnen mitteilt, ob eine in Ihrer SBOM gefundene Schwachstelle tatsächlich „erreichbar“ oder „ausnutzbar“ ist. Dies verhindert „Sicherheitslücken-Müdigkeit“ – das überwältigende Gefühl, 400 Warnmeldungen der Stufe „Hoch“ zu sehen und nicht zu wissen, welche man zuerst beheben soll. Durch die Kombination einer SBOM mit VEX können Sie Ihren Anwendern nachweisen, dass sich zwar ein „Geist“ in einer von Ihnen verwendeten Bibliothek befinden mag, dieser jedoch in einem Raum eingeschlossen ist, in dem er niemandem Schaden zufügen kann.
Minimalismus
Der sicherste Code ist der, den man gar nicht erst installiert. Bevor du eine neue Abhängigkeit hinzufügst, frag dich: „Kann ich dieses Dienstprogramm selbst schreiben?“ oder „Bringt diese Bibliothek 500 transitive Abhängigkeiten mit sich, nur um ein Datum zu formatieren?“
Das Fazit: Beuge dem Spuk vor, bevor er beginnt
Die meisten Angriffe auf die Lieferkette, die wir heute beobachten, kommen nicht von der Vordertür, sondern von den transitiven Abhängigkeiten, die wir ohne zu zögern zugelassen haben.
Als Entwickler sind wir die Torwächter. Wir müssen genauso sorgfältig mit dem Code umgehen, den wir übernehmen , genauso gewissenhaft wie bei dem Code, den wir selbst schreiben. Es ist an der Zeit, Licht in die dunklen Ecken von node_modules und sicherzustellen, dass sich keine Geister in der Maschine verstecken.
