Axios lief drei Stunden lang außer Kontrolle, und die 100 Millionen wöchentlichen Downloads haben davon nichts mitbekommen

Wichtigste Erkenntnisse

• Die schädlichen Axios-Versionen waren nur etwa drei Stunden lang im Umlauf, sodass Installationen, die vor der Entdeckung erfolgten, nicht von den auf dem Sicherheitshinweis basierenden Abwehrmaßnahmen profitieren konnten.
• Die Anzahl der Downloads gibt Aufschluss über die Verbreitung, nicht über die Überprüfung, und Axios kann über Pakete auf das System gelangen, die ein Team gar nicht ausgewählt hat.
• Verschiedene Kontrollmechanismen hätten diese Kette unterbrechen können, angefangen bei gesperrten Installationen und blockierten Installationsskripten bis hin zu Quarantänefenstern, Herkunftsprüfungen und Registrierungsüberprüfungen.
• Die wirksamsten Präventionsmaßnahmen werden bereits zum Zeitpunkt der Installation oder noch davor ergriffen – genau in diesem Bereich haben viele Teams jedoch am wenigsten investiert.

Am 31. März 2026 wurden zwei bösartige Versionen von axios veröffentlicht und blieben etwa drei Stunden lang online, bevor sie entfernt wurden. In diesem Zeitraum schlichen sie sich unbemerkt in die Abhängigkeitsbäume eines großen Teils des JavaScript-Ökosystemsschleichten sie sich unbemerkt in die Abhängigkeitsbäume eines großen Teils desJavaScript-Ökosystems ein, und fast niemand, der sie installiert hatte, konnte dies bemerken.

Niemand aus dem Projekt hat sie veröffentlicht. Die Releases stammten aus einem gehackten Maintainer-Konto und wurden manuell mit einem gestohlenen, langfristig gültigen Token veröffentlicht, das die projektinterne CI-Pipeline umging, sodass sie in der Registry wie gewöhnliche Axios-Releases aussahen. Die Versionsnummern sahen normal aus. npm audit lieferte für den ersten Teil des Zeitfensters keine Ergebnisse, da der Hinweis, der den Vorfall schließlich beschreiben sollte, noch nicht verfasst worden war.

Drei Stunden im Inneren eines Angriffs auf die npm-Lieferkette

Drei Stunden sind nicht lange. Das reicht den meisten Teams nicht einmal aus, um zu bemerken, dass eine neue Version veröffentlicht wurde, geschweige denn, sie zu bewerten.

Der allgemeine Ablauf eines Kompromitts auf der Veröffentlichungsseite ist gut dokumentiert, und Axios hat sich an diesen Ablauf gehalten, allerdings mit einer zusätzlichen Ebene, die in der generischen Version fehlt. Beide Releases haben eine brandneue Abhängigkeit namens plain-crypto-js, die zu keinem anderen Zweck diente, als eine Payload über einen Postinstall-Hook auszuführen. Etwa 18 Stunden zuvor war eine saubere Scheinvarianten dieses Pakets veröffentlicht worden, wodurch die bösartige Folgeversion weniger wie etwas völlig Neues wirkte, und die axios-Quelldateien selbst wurden nie verändert. Social Engineering verschaffte dem Angreifer zunächst Zugriff auf den Rechner des Betreuers, wodurch er auch die Veröffentlichungsrechte erhielt.

Der interessante Schritt ist die Weitergabe. Zwischen der Veröffentlichung und der Erkennung verlangt der Standardpfad von „npm install“ niemals von einem Paket den Nachweis, dass das über das Netzwerk übertragene Artefakt tatsächlich anhand der angegebenen Quelle und des angegebenen Workflows erstellt wurde. Diese Lücke bildet das gesamte Angriffsfenster.

Wiz stellte fest, dass die Malware in etwa 3 % der betroffenen Umgebungen tatsächlich ausgeführt wurde , die in seinen Telemetriedaten auftauchten, und Forscher schätzten das Expositionszeitraum auf geschätzte 600.000 Downloads. Da die beiden Zahlen aus unterschiedlichen Datenbeständen stammen, ergibt ihre Multiplikation keine tatsächliche Gesamtzahl. Nehmen Sie sie jedoch nebeneinander, beschreiben sie die bestätigte Ausführung der Payload innerhalb eines sehr kurzen Expositionsfensters und nicht nur Dateien, die auf der Festplatte liegen.

Realitätscheck: Das Zurückziehen einer schädlichen Version verhindert zukünftige Installationen. Es hat jedoch keinerlei Auswirkungen auf Rechner, auf denen die Version bereits ausgeführt wurde, auf bereits abgezweigte Token oder auf Container-Images, die bereits erstellt und bereitgestellt wurden und in denen der schädliche Code bereits integriert ist.

Warum 100 Millionen Downloads pro Woche kein Sicherheitssignal sind

Die unausgesprochene Annahme hinter der Auswahl beliebter Abhängigkeiten ist, dass Beliebtheit gleichbedeutend mit genauer Prüfung ist. Viele Augen, wenige Fehler – so lautet der Grundgedanke.

Was den Quellcode angeht, ist das ein stichhaltiges Argument. In Bezug auf die Integrität der Veröffentlichung hinkt es jedoch, da die Aufmerksamkeit auf das Repository gerichtet ist, während der Angriff in der Registry stattfindet. Das sind zwei verschiedene Artefakte, und npm verlangt nicht, dass sie übereinstimmen. In jener Nacht waren zahlreiche Scanner im Einsatz, und mehrere von ihnen haben die Veröffentlichung innerhalb weniger Minuten als verdächtig gemeldet. Im Standardinstallationspfad wartet nichts auf sie.

Es gibt noch ein zweites Problem, und genau das macht es so mühsam, auf solche Vorfälle zu reagieren. Manche Teams haben axios gar nicht direkt installiert. Sie haben etwas installiert, das wiederum etwas anderes installiert hat, das wiederum axios installiert hat.

Eine Studievon Endor Labs, die in den OWASP Top 10 für Open-Source-Software zitiert wird, beziffert den Anteil der Sicherheitslücken, die in indirekten Abhängigkeiten liegen, auf etwa 95 % und nicht in den Paketen, die ein Team bewusst ausgewählt hat. Diese Zahl bezieht sich zwar auf bekannte Sicherheitslücken und nicht auf Malware, zeigt jedoch, wie großer Teil eines Abhängigkeitsgraphen außerhalb der von Entwicklern bewusst ausgewählten Pakete liegt – und diese Graphen sind keineswegs flacher geworden. Wenn sich das kompromittierte Paket vier Ebenen tiefer in einem Graphen befindet, den niemand tatsächlich gelesen hat, wird die Frage „Verwenden wir axios überhaupt?“ überraschend schwer schnell zu beantworten.

npm ls axios –all

npm ls plain-crypto-js –all

Führe diese Tests für jedes Repo durch, nicht nur für diejenigen, bei denen du dich daran erinnerst, einen HTTP-Client hinzugefügt zu haben. Sollte bei einem der beiden der Fehler axios 1.14.1 oder 0.30.4 oder plain-crypto-js 4.2.1 zurückgibt, betrachte den Host als kompromittiert und wechsle zurück zu axios 1.14.0 oder 0.30.3 zurück und ändern Sie alle Anmeldedaten, auf die dieser Host Zugriff hat.

Was wollte ein staatlicher Akteur mit einem HTTP-Client?

Die Threat Intelligence Group von Google führte den Hackerangriff auf Axios auf UNC1069 zurück, einem finanziell motivierten, mit Nordkorea in Verbindung stehenden Akteur, der bereits wiederholt Kryptowährungsbörsen ausgeraubt hat. Microsoft verfolgt sich überschneidende Aktivitäten unter dem Namen „Sapphire Sleet“, während andere Forscher damit verbundene Aktivitäten mit Namen wie „BlueNoroff“ und „Stardust Chollima“ in Verbindung bringen. Ein HTTP-Client scheint auf den ersten Blick ein seltsames Ziel für eine Gruppe dieser Art zu sein – bis man darüber nachdenkt, welche Vorteile ein solcher Angriff mit sich bringt.

Entwicklerrechner und Build-Agenten in großem Maßstab – und auf diesen Rechnern befinden sich Anmeldedaten für Cloud-Rollen, Registry-Token, Signaturschlüssel und Quellcode für noch nicht veröffentlichte Projekte. Sich zunächst auf Entwicklertools statt direkt auf die Produktion zu konzentrieren, ist ein Muster, das sich auch durch frühere npm-Kampagnen zieht, und es funktioniert, weil Entwicklerarbeitsplätze und Build-Agenten Anmeldedaten mit ungewöhnlich weitreichendem Zugriff auf nachgelagerte Systeme enthalten.

Verizons „Data Breach Investigations Report 2026“ ergab, dass die Ausnutzung von Sicherheitslücken den Missbrauch gestohlener Zugangsdaten als häufigsten Erstzugangsweg abgelöst hat und 31 % der Sicherheitsvorfälle ausmacht, verglichen mit 13 % für den Missbrauch von Zugangsdaten. Zugangsdaten haben jedoch nichts von ihrer Bedeutung verloren. Sie gehören nach wie vor zu den häufigsten Faktoren, sobald ein Angriff im Gange ist, und ein Angriff, bei dem Token aus Tausenden von Build-Umgebungen abgegriffen werden, ist genau die Art von Vorfall, die diesen Vorrat immer wieder auffüllt.

Shai-Hulud und der Trend zu sich selbst verbreitender Malware

Bei „axios“ handelte es sich um eine einmalige Veröffentlichung. Die Wurmkampagnen sind hingegen etwas ganz anderes.

Shai-Hulud setzte im September 2025 einen neuen Maßstab mit Schadcode, der, sobald er in einer Entwicklungs- oder CI-Umgebung ausgeführt wird, nach Geheimdaten sucht, npm-Publish-Token findet und diese nutzt, um sich in weitere Pakete einzuschleusen. Eine damit verbundene Kampagne, bekannt als „Mini Shai-Hulud“ , begann am 29. April 2026 und setzte sich im Mai in zwei weiteren Wellen fort. Im Verlauf der Kampagne veröffentlichte TeamPCP den Quellcode des Wurms auf GitHub – und so etwas lässt sich nicht einfach wieder in die Flasche zurückstecken.

Die Funktionsweise ist wichtiger als das Branding. Eine sich selbst verbreitende Kampagne macht jedes Opfer mit entsprechenden Veröffentlichungsrechten zu einem weiteren Verbreitungsort, sodass die Anzahl der betroffenen Pakete weiter wächst, ohne dass der Angreifer auch nur einen Finger rühren muss.

Vorsicht: Heimliches Scannen ist ein zweischneidiges Schwert. Bei mehreren Wurmkampagnen wurden handelsübliche Scanner wie TruffleHog gebündelt, um infizierte Rechner nach Anmeldedaten zu durchsuchen – dabei handelt es sich um dieselben Tools, die auch die Verteidiger einsetzen, nur in umgekehrter Richtung.

Diese Wachstumskurve spricht für Kontrollpunkte, die nicht davon abhängen, dass bereits bekannt ist, welche Pakete fehlerhaft sind. Durch das Überprüfen von Paketen vor ihrer Auflösung und den Abgleich veröffentlichter Artefakte mit verifizierter Quelle lassen sich ganze Klassen von Sicherheitslücken aufdecken, ohne darauf warten zu müssen, dass ein Sicherheitshinweis vorliegt. Das ist der Grundgedanke hinter SecureChain für npm.

Mastra und jscrambler setzten den Trend fort

Zwei weitere Vorfälle im Jahr 2026 machten deutlich, dass der Vorfall im März kein Einzelfall war. Die Übernahme des Mastra-AI-Pakets am 17. Juni und der „jscrambler“-Angriff am 11. Juli erfolgten beide über den Zugriff auf der Veröffentlichungsseite und nicht über eine Schwachstelle im Code eines Nutzers.

Microsoft führte den Mastra-Hack auf „Sapphire Sleet“ zurück – so nennt das Unternehmen die Aktivität, die Google als UNC1069 verfolgt. Etwa elf Wochen nach dem Vorfall bei Axios tauchte derselbe Cluster mit einem sehr ähnlichen Vorgehensmuster wieder auf. Ein ehemaliges Mitwirkendenkonto, das weiterhin Veröffentlichungsrechte im @mastra-Bereich besaß, wurde genutzt, um mehr als 140 Pakete erneut zu veröffentlichen. Die einzige Änderung in jedem einzelnen Paket war eine hinzugefügte Abhängigkeit namens „easy-day-js“ – ein DayJS-Lookalike, das einen bösartigen Postinstall-Hook enthielt. Der Code der Bibliothek wurde nicht verändert, genau wie im Fall von axios.

Sonatype meldete allein im Jahr 2025 mehr als 454.600 neue bösartige Open-Source-Pakete auf npm, PyPI und anderen Registern allein im Jahr 2025 gemeldet, das Ausmaß ist also nichts Neues. Was die jüngste Entwicklung jedoch verdeutlicht, ist, wie schnell ein kompromittierter Veröffentlichungszugang dazu führt, dass diese Menge tatsächlich in einen Build gelangt.

Was hätte das eigentlich verhindern können?

Hier sind sechs mögliche Kontrollmaßnahmen, die im Hinblick auf einen dreistündigen Angriff auf die Veröffentlichungsseite ehrlich geprüft wurden.

–ignore-scripts hat sich seinen Platz verdient, und das Ökosystem hat inzwischen aufgeholt. npm 12 wurde am 8. Juli 2026 veröffentlicht, wobei Skripte zur Installation von Abhängigkeiten standardmäßig deaktiviert sind, einschließlich des impliziten „node-gyp“ „rebuild“, den ein reines binding.gyp früher auslöste. Daher blockiert npm 12 diese Funktion, ohne dass sich jemand an ein Flag erinnern muss. Abhängigkeiten, die tatsächlich Installationsskripte oder native-build-Skripte benötigen, müssen nun explizit genehmigt werden. Es lohnt sich, dies sorgfältig zu prüfen, bevor ein Upgrade unbemerkt eine Pipeline zum Absturz bringt.

Es handelt sich nach wie vor nicht um eine allgemeine Lösung – bösartiger Code, der im Modulkörper enthalten ist, wird ausgeführt, sobald das Paket importiert wird, unabhängig davon, ob das Skript blockiert wird oder nicht. Der jscrambler-Angriff im Juli ist das deutlichste Beispiel dafür. Die ersten bösartigen Versionen wurden über einen Preinstall-Hook ausgeführt, und anschließend, noch während desselben dreistündigen Veröffentlichungslaufs, verschob der Angreifer den identischen Dropper in den Code des Pakets selbst, sodass er ausgelöst wurde, sobald das Paket importiert oder seine CLI ausgeführt wurde. Das Blockieren von Installationsskripten ist notwendig. Es reicht jedoch nicht aus.

Bei der „Lockfile“-Disziplin ist eine umfassendere Einschränkung erforderlich, da es sich um eine Kontrollmaßnahme handelt, von der die meisten Teams annehmen, dass sie diese bereits abgedeckt haben.

Achtung: Ein Caret-Bereich wie ^1.7.0 in package.json wird problemlos zu einer bösartigen Patch-Version aufgelöst, wenn nichts die Version festlegt. Eine festgeschriebene Lockfile-Datei verhindert dies, und npm ci ist die strengere Methode, um daraus zu installieren, da es die Ausführung verweigert, wenn die Versionssperrdatei und package.json nicht übereinstimmen, anstatt die Auflösung stillschweigend zu ändern. Der Schutz entfällt in dem Moment, in dem die Lockdatei neu generiert oder auf eine Version aktualisiert wird, die die Sicherheitslücke enthält. Viele Pipelines lassen mindestens einen dieser Schritte aus.

Die Herkunftsangabe ist hier nützlich und macht sich gerade bei diesem spezifischen Fehlermodus bezahlt.

Wussten Sie schon: npm unterstützt die Sigstore-basierte Herkunftsbescheinigung für aus der CI veröffentlichte Pakete, und Sie können mit einem einzigen Befehl überprüfen, was Sie bereits haben: npm audit signatures.

Man sollte genau unterscheiden, was damit bewiesen wird. Die Provenienz überprüft, ob ein Artefakt tatsächlich aus der angegebenen Quelle und dem angegebenen Build-Workflow stammt – das ist eine andere und weitaus besser zu beantwortende Frage als die, ob der darin enthaltene Code bösartig ist. Im Fall von axios wäre dies hilfreich gewesen, da die letzte saubere 1.x-Version eine Herkunftsangabe enthielt, die bösartige Version hingegen nicht – sie war manuell mit einem gestohlenen Token statt über den CI-Workflow des Projekts hochgeladen worden. Es handelt sich dabei jedoch nicht um eine Malware-Kontrolle. Die „2026 Mini Shai-Hulud“-Wellen lieferten bösartige Pakete mit gültiger Herkunftsangabe aus, da die Pipeline, in der sie erstellt wurden, tatsächlich kompromittiert worden war.

Was sollte man vor dem nächsten Mal ändern?

Dafür ist kein Neuaufbau der Plattform erforderlich. Entscheiden Sie sich je nachdem, wo sich Ihre Pipeline bereits befindet.

Falls Ihre Lockfiles inkonsistent festgeschrieben wurden, beheben Sie dies zunächst und stellen Sie die CI auf npm cium. Das ist eine der einfachsten Kontrollmaßnahmen auf der Liste, und sie hätte diesen konkreten Vorfall von vornherein verhindert.

Falls Sie bereits npm ci überall einsetzt, füge bei neuen Releases ein Quarantänefenster hinzu. npm hat ein natives „min-release-age“ Einstellung integriert; pnpm 11 setzt minimumReleaseAge standardmäßig auf einen Tag ein, obwohl die Installation nicht fehlschlägt, solange man den Wert nicht selbst festlegt. Unit 42 empfiehlt, alle Veröffentlichungen aus den letzten 24 bis 72 Stunden zurückzuhalten, da die meisten schädlichen Pakete innerhalb dieses Zeitraums identifiziert und entfernt werden. Damit wären zwar nicht alle Fälle abgedeckt – schließlich dauerte die vollständige Beseitigung des ursprünglichen Shai-Hulud-Wurms mehrere Tage –, doch deckt diese Vorgehensweise den typischen Fall ab.

Wenn Sie Pakete selbst veröffentlichen, aktivieren Sie die Herkunftsnachweisfunktion und wechseln Sie zu einer vertrauenswürdigen Veröffentlichung mit OIDC anstelle von langfristig gültigen Veröffentlichungstoken. Der „axios“-Angreifer umging den normalen OIDC-Veröffentlichungsworkflow des Projekts durch die Verwendung eines gestohlenen klassischen Tokens – ein triftiges Argument dafür, diese Token vollständig aus dem Verkehr zu ziehen. Sie sind Teil der Lieferkette eines anderen, ob Sie das nun so sehen oder nicht.

Und falls Ihre Build-Agenten Anmeldedaten für Cloud-Rollen enthalten, sollten Sie deren Gültigkeitsdauer vorrangig verkürzen. Das ist der entscheidende Unterschied zwischen einer fehlerhaften Installation und einem Vorfallbericht.

Das Problem dabei ist, dass viele der wirksamsten Präventionsmaßnahmen bereits vor oder zum Zeitpunkt der Problemlösung zum Tragen kommen, während der Großteil der bisherigen Investitionen der Teams darauf abzielt, Probleme erst im Nachhinein zu erkennen. Das ist kein Vorwurf an die Software-Kompositionsanalyse, die genau die Aufgabe erfüllt, für die sie entwickelt wurde. Es handelt sich um ein zeitliches Problem, und zeitliche Probleme lassen sich nicht durch das Hinzufügen eines weiteren Scans beheben.

Wie stark sich dies auswirkt, hängt davon ab, wie schnell die Organisation tatsächlich neue Versionen von Abhängigkeiten benötigt. Teams, die KI-Tools auf Basis schnelllebiger Upstream-Pakete bereitstellen, zahlen einen hohen Preis für Quarantänefenster. Teams, die auf langsamer evolvierenden internen Plattformen arbeiten, sind davon weitaus weniger betroffen und stellen oft fest, dass sie bei den Nebenversionen bereits drei Wochen im Rückstand waren, ohne dass es jemand bemerkt hatte.

Das nächste ist irgendwo schon online

Drei Stunden kommen einem nicht besonders lang vor, bis man die Installationen zählt, die in dieser Zeit stattgefunden haben. Das ist die eigentliche Erkenntnis hier, nicht die Zuordnung zu Nordkorea oder die Bezeichnung als Wurm. Es geht um die Zeitspanne zwischen Veröffentlichung und Entdeckung – und darum, wie wenig in dieser Zeitspanne standardmäßig passiert.

Axios ist aufgefallen. Kleinere Sicherheitslücken finden in der Regel weitaus weniger Beachtung. Sie werden ohne großes Aufsehen aus dem Register entfernt, und wer sie bereits installiert hat, muss selbst herausfinden, inwieweit er davon betroffen ist. Die nächste Sicherheitslücke, die vier Ebenen tief in der Abhängigkeitsstruktur eines Nutzers verborgen ist, wird sich ebenfalls nicht von selbst bemerkbar machen.

Ein auf Sicherheitshinweisen basierendes Scanning ist am effektivsten, wenn eine Bedrohung bereits bekannt ist. Um einen npm-Supply-Chain-Angriff zu erkennen, während er noch im Gange ist, muss die Überprüfung bereits bei der Installation erfolgen, anstatt darauf zu warten, dass das Paket in einem Sicherheitshinweis namentlich genannt wird. Genau darin liegt die Lücke SecureChain für npm wurde entwickelt, um diese Lücke zu schließen.

FAQs

Was ist ein npm-Supply-Chain-Angriff?

Ein npm-Supply-Chain-Angriff ist eine Kompromittierung eines Pakets in der Registry, bevor es Sie überhaupt erreicht – in der Regel durch gestohlene Veröffentlichungszugangsdaten, ein gekapertes Konto eines Betreuers oder die Vortäuschung einer anderen Identität im Namespace und nicht durch eine Schwachstelle in Ihrem eigenen Code.

Was ist bei dem Axios-Hack passiert?

Zwei schädliche Versionen von axios, 1.14.1 und 0.30.4, wurden am 31. März 2026 veröffentlicht und etwa drei Stunden später wieder zurückgezogen. Beide fügten eine Abhängigkeit namens plain-crypto-js ein, die über einen Postinstall-Hook einen plattformübergreifenden Fernzugriffstrojaner ablegte. Die Threat Intelligence Group von Google führte den Angriff auf UNC1069 zurück, während Microsoft die damit zusammenhängenden Aktivitäten unter dem Namen „Sapphire Sleet“ verfolgt. Als sichere Alternativen stehen die Versionen 1.14.0 und 0.30.3 zur Verfügung.

Erkennt „npm audit“ schädliche Pakete?

Die Schwachstellenprüfungen stützen sich auf Meldungen aus dem Register; daher können sie Sie erst dann vor einer frisch kompromittierten Version warnen, wenn diese identifiziert und erfasst wurde. Im Fall von axios wurde zwar innerhalb des dreistündigen Zeitfensters eine Meldung eingereicht, doch die bereits erfolgten Installationen konnten dadurch nicht rückgängig gemacht werden. npm-Audit-Signaturen ist eine separate und in diesem Zusammenhang nützlichere Prüfung, da sie Registerschriften und Herkunftsnachweise überprüft.

Schützt eine Lockdatei vor einer manipulierten npm-Veröffentlichung?

Eine festgeschriebene Lock-Datei verhindert, dass eine unerwartete Version aufgelöst wird, und npm ci ist die strengere Methode zur Installation daraus, da der Vorgang abgebrochen wird, wenn die Lockdatei und package.json nicht übereinstimmen. Dieser Schutz entfällt, wenn die Lockdatei neu generiert oder auf eine Version aktualisiert wird, die den Kompromiss enthält, und ist „npm install“ ist weniger streng, da es die Auflösung ändern und die Lockdatei neu schreiben kann.

Was ist der Shai-Hulud-Wurm?

Eine sich selbst verbreitende npm-Malware-Kampagne, die geheime Daten aus infizierten Umgebungen abgreift, npm-Veröffentlichungstoken aufspürt und diese nutzt, um sich in weitere Pakete einzuschleusen, wodurch sich die Zahl der betroffenen Pakete vergrößert, ohne dass der Angreifer weitere Maßnahmen ergreifen muss. Der Quellcode wurde im Mai 2026 öffentlich veröffentlicht, sodass mittlerweile auch Nachahmerwellen zu beobachten sind.

Wie kann ich überprüfen, ob ein Paket von seinen tatsächlichen Betreuern erstellt wurde?

Ausführen npm audit signatures aus, um die Signaturen im Repository und, sofern vorhanden, die Herkunftsbescheinigungen zu überprüfen. Die Herkunftsbescheinigung kann bestätigen, dass ein Artefakt tatsächlich von der angegebenen Quelle und im angegebenen CI-Workflow erstellt wurde. Dies ist jedoch eine andere Frage als die nach der Sicherheit des Codes, da eine kompromittierte Pipeline einen ordnungsgemäß bescheinigten Build erzeugen kann.

Unbefugte Veröffentlichungen stoppen, bevor sie abgeschlossen sind

Wenn man sich ausschließlich auf Sicherheitshinweise verlässt, erfährt man möglicherweise erst dann von einer bösartigen Version, wenn diese bereits in einen Build gelangt ist. SecureChain für npm überprüft Pakete bereits bei der Auflösung und erstellt sie aus verifizierten Quellen neu, um kompromittierte und gegen Richtlinien verstoßende Artefakte zu blockieren, bevor sie so weit gelangen. Werfen Sie einen Blick auf SecureChain für npmund abonnieren Sie den TuxCare-Newsletter, um wöchentliche Updates zur Open-Source-Lieferkette zu erhalten.

Zusammenfassung

Artikel Name

Der Supply-Chain-Angriff auf Axios über npm und was dabei ans Licht kam

Beschreibung

Zwei bösartige Versionen von Axios blieben drei Stunden lang online. Erfahren Sie, was der Angriff auf die npm-Lieferkette aufgedeckt hat und welche Sicherheitsmaßnahmen ihn tatsächlich verhindern können.

Autor

Tim Walker

Name des Herausgebers

TuxCare

Logo des Herausgebers