Im zweiten Quartal 2026 hat Aikido Intel rund 7,5 Millionen Paketversionen analysiert. Mithilfe unserer automatisierten Systeme und unserer Forscher konnten wir 19.500 schädliche Pakete identifizieren. Angreifer nutzen Open-Source-Abhängigkeiten aus, um in Software einzudringen, und Lieferkettenangriffe verzeichnete ab Mitte 2025 einen starken Anstieg. Beliebte Pakete wie „axios“ und Sicherheitstools wie Trivy und „ Checkmarx “ wurden kompromittiert.
Dieser Leitfaden führt Sie durch bewährte Verfahren zur Sicherheit in der Lieferkette, mit denen sich die Angriffe der letzten 18 Monate hätten verhindern lassen. Wenn Sie sich eingehender mit dem Thema befassen möchten, sehen Sie sich die praktische Checkliste zur Abwehr von „ Lieferkettenangriffe “ an. Die vollständige praktische Checkliste umfasst 30 Kontrollmaßnahmen in den Bereichen Container, Absicherung von CI und mehr, die nach Priorität geordnet sind, damit Sie wissen, wo Sie anfangen sollen.
{{cta}}
Stoppen Sie die Malware, bevor sie sich installiert
Ein Mindestalter von 48 Stunden für das Paket festlegen
Eine Sperrfrist blockiert alle kürzlich veröffentlichten Versionen. Die meisten kompromittierten Versionen werden innerhalb weniger Stunden nach ihrer Veröffentlichung markiert und zurückgezogen, was bedeutet, dass eine 48-stündige Sperrfrist diese abfängt. Die Sperrfrist schafft einen zeitlichen Abstand zwischen Veröffentlichung und Einsatz. Setzen Sie diese im privaten Repository oder im Paketmanager durch. npm verfügt über Mindestalter für die Freigabe Seit Version 11.10.0 verfügen sowohl Yarn als auch Bun über eigene Altersbeschränkungen.
Blockieren von Hooks nach der Installation mit „ignore-scripts“
Sie müssen kein Paket verwenden, damit Code auf Ihrem Rechner ausgeführt wird – Sie müssen es lediglich installieren. Wenn Sie „npm install“ ausführen, führt npm alle vom Paketautor geschriebenen Postinstall-Skripte mit Ihren Berechtigungen aus. Deaktivieren Sie Installationsskripte mit --ignore-scripts und fügen Sie die wenigen Pakete, die tatsächlich etwas kompilieren müssen, zur Whitelist hinzu. Wenden Sie dieselbe Einstellung auch in der CI und auf den Entwicklerrechnern an, um Zugangsdaten zu erfassen, die auf dem Laptop gespeichert sind.
Die Standardwerte des Ökosystems entwickeln sich in die richtige Richtung
pnpm hat in Version 10 im Januar 2025 die Skripte zur Installation von Abhängigkeiten standardmäßig deaktiviert und anschließend standardmäßig eine 24-stündige Wartezeit aktiviert in v11 im April 2026. npm v12 wurde am 8. Juli 2026 ausgeliefert, wobei die Skripte zur Installation von Abhängigkeiten standardmäßig deaktiviert sind – Ihre eigenen Skripte werden jedoch weiterhin ausgeführt –, und es gibt keine Standard-Wartezeit, sodass Sie weiterhin Mindestalter für die Freigabe selbst. Die Aktualisierung Ihres Paketmanagers ist der kostengünstigste Weg, um einen Teil beider Kontrollmechanismen abzudecken. Teams, die ältere Versionen oder andere Ökosysteme nutzen, benötigen die oben genannten expliziten Einstellungen. Was eine Abklingzeit verhindert hätte
Der axios Der Angreifer veröffentlichte eine saubere Köderdatei, plain-crypto-js@4.2.0, am 30. März, und ersetzte dann die schädliche plain-crypto-js@4.2.1 um 23:59 Uhr UTC. Die automatische Erkennung hat den Vorfall sechs Minuten später gemeldet. axios@1.14.1 wurde am 31. März um 00:21 Uhr UTC veröffentlicht, und axios@0.30.4 Es folgte um 01:00 Uhr. npm entfernte beide Axios-Versionen etwa drei Stunden nach der Veröffentlichung der ersten Version. Eine 48-Stunden-Sperrfrist hätte die Teams von beiden Versionen ferngehalten, wobei noch etwa 45 Stunden Zeit geblieben wären.
CanisterWorm veröffentlichte inkrementierte Patch-Versionen aller Pakete, die von seinen Opfern gepflegt wurden, und erreichte damit innerhalb von 24 Stunden mehr als 60 Pakete. Die meisten wurden innerhalb weniger Minuten nach ihrer Veröffentlichung markiert, sodass eine 48-Stunden-Sperre sie aus Ihrem Resolver ferngehalten hätte. Mindestens eines blieb etwa 53 Stunden lang unentdeckt, weshalb die Sperre am besten in Verbindung mit einer Malware-Erkennung bei der Installation funktioniert.
Befestige alles, was wegtreiben könnte
Sichern Sie eine Sperrdatei und setzen Sie diese in Ihrer Pipeline durch
Eine Lockdatei erfasst die genaue Version und den Integritäts-Hash jeder Abhängigkeit, einschließlich transitiver Abhängigkeiten. Die Durchsetzung bedeutet, dass Ihre Pipeline „npm ci“ anstelle von „npm install“ ausführt, da „npm ci“ ausschließlich anhand der Lockdatei installiert und sofort fehlschlägt, wenn sich „package.json“ davon entfernt hat. Jedes andere Ökosystem verfügt über denselben Modus unter einem anderen Namen, wie beispielsweise --frozen-lockfile in pnpm, --unveränderlich in „Yarn“, --gesperrt in „Cargo“ und --require-hashes in pip. Das sollte vor dem Merge zwingend überprüft werden, damit diese Regel für das gesamte Team gilt.
Pinnen Sie Ihre Pipeline an Commit-SHAs
Jede CI-Plattform ermöglicht es Ihnen, Abhängigkeiten einzubinden, und in den meisten Fällen verweisen Sie dabei auf ein Tag oder einen Zweignamen. Beides sind Verweise, die derjenige, der das Quell-Repo verwaltet, jederzeit verschieben kann. Die Fixierung an einen Commit-SHA verhindert Abweichungen, da sich ein SHA auf einen bestimmten Code-Baum bezieht und nicht umgeleitet werden kann. GitHub Actions, GitLab, Buildkite und Jenkins akzeptieren alle einen SHA anstelle eines Tags. CircleCI funktioniert anders, da veröffentlichte Orb-Versionen nach ihrer Freigabe unveränderlich sind; daher ist eine exakte Version ausreichend.
Der Nachteil dabei ist, dass Sie keine automatischen Upstream-Korrekturen mehr erhalten. Kombinieren Sie diese Korrektur daher mit einem Bot, der Pull-Requests eröffnet, um den SHA weiterzuentwickeln. „Renovate“ unterstützt unter anderem „Actions“ und „GitLab-Includes“ und kann die anfängliche Konvertierung von Tags in SHAs für Sie übernehmen. Dependabot Hält bestehende Action-Pins auf dem neuesten Stand, ist jedoch ausschließlich für GitHub Actions verfügbar.
Bilder an Zusammenfassungen anheften
Ein „ container “-Image-Tag ist ebenfalls ein veränderblicher Zeiger. „node:22-alpine“ verweist diesen Monat auf ein anderes Image als noch im letzten Monat, und in Ihrem Dockerfile ist nirgends vermerkt, auf welches Image Sie beim Erstellen zurückgegriffen haben.
Verknüpfen Sie die „FROM“-Zeile mit einem Digest, damit der Build reproduzierbar ist und Änderungen aus dem Upstream Ihre Genehmigung erfordern. Richten Sie anschließend einen automatisierten Zeitplan für den Neubauf ein, da ein verknüpfter Digest auch bedeutet, dass Sie keine Patches aus dem Upstream mehr erhalten, bis Sie die Verknüpfung bewusst aufheben.
Was hätte durch das Feststecken verhindert werden können?
Im März 2025, Angreifer haben sich Zugang verschafft die tj-actions/changed-files Action hat alle Versions-Tags auf einen böswilligen Commit umgeleitet, der CI- secrets en in die Workflow-Protokolle geschrieben hat. Etwa 23.000 Repositorys verweisten darauf, und in öffentlichen Repositorys waren diese Protokolle für jedermann einsehbar.
Jeder Workflow, der auf ein Tag verwies, lud bei seiner nächsten Ausführung den Schadcode herunter. Die Repositorys, die an einen Commit-SHA gebunden waren, blieben davon unberührt.
Zugriff und Identität sichern
Gültigkeitsbereich-Token
Ein Token mit organisationsweiten Veröffentlichungsrechten ist gefährlich, da jeder, der es in die Hände bekommt, alles veröffentlichen kann, was Ihnen gehört. Verwenden Sie detailliert definierte Token, die auf bestimmte Repositorys und Pakete beschränkt sind, und vergeben Sie für jede Pipeline separate Zugangsdaten, anstatt ein einziges Token für alle Runner und Rechner gemeinsam zu nutzen. Führen Sie die Token nach einem festgelegten Zeitplan und bei jedem Verdacht sofort neu aus, und widerrufen Sie sie, sobald jemand ein Projekt verlässt.
Ein ehemaliger CrowdSec-Entwickler behielt seinen GitHub-Zugang, um einige Arbeiten abzuschließen, und sein Laptop wurde im Rahmen des TanStack-Angriffs kompromittiert. Ein Angreifer nutzte das Token dieses Computers, um innerhalb von etwa neun Minuten 170 private Repositorys von CrowdSec zu klonen. Das Unternehmen erfuhr erst vier Monate später davon, als der Code in einem Forum auftauchte.
Kontoverwalterkonten auf FIDO2 oder Passkeys umstellen
Ein zeitbasiertes Einmalpasswort (TOTP) ist besser als gar nichts, aber es kann durch Phishing ausgemacht werden. Ein Angreifer erfasst den Code auf einer überzeugend gefälschten Anmeldeseite und gibt ihn innerhalb des 30-Sekunden-Fensters auf der echten Website wieder – das reicht aus, um die Kontrolle über ein Konto zu übernehmen, ohne dass dabei Malware zum Einsatz kommt. FIDO2 und Passkeys sind kryptografisch an die legitime Domain gebunden. Wenn Sie ein weit verbreitetes Paket betreuen, halten Sie die E-Mail-Adresse des Kontos auf dem neuesten Stand und behalten Sie sie im Auge, da npm einflussreiche Konten nach einem E-Mail-Wechsel oder einer 2FA-Wiederherstellung für 72 Stunden sperrt und die Benachrichtigung an die vorherige Adresse sendet.
Behandeln Sie den Entwickler-Rechner wie eine Produktionsumgebung
Richten Sie Endpunktüberwachung auf jedem Entwicklerrechner ein
Ein Entwickler-Laptop enthält Quellcode, Cloud-Zugangsdaten, Veröffentlichungstoken und eine authentifizierte Sitzung für den Großteil Ihrer Infrastruktur. Aus diesem Grund gehören Entwickler-Endpunkte mittlerweile zu den größten Angriffszielen von „ Lieferkettenangriffe “. Herkömmliche EDR-Tools erkennen Bedrohungen erst, wenn diese bereits ausgeführt werden. Dadurch entsteht ein Zeitfenster, in dem Zugangsdaten abgegriffen oder schädliche Pakete installiert werden können, bevor ein Alarm ausgelöst wird.
Suchen Sie nach Endpunkt-Tools, die npm- und pip-Installationen unmittelbar nach ihrer Durchführung überprüfen und die Richtlinien zum Zeitpunkt der Installation durchsetzen können, wie beispielsweise Mindestanforderungen an das Alter von Paketen oder Zulassungslisten für IDE-Erweiterungen und Browser-Plugins.
Die Zulassungsliste für Erweiterungen zentral durchsetzen
IDE-Erweiterungen und Browser-Plugins werden mit echten Berechtigungen ausgeführt und aktualisieren sich selbst, ohne nachzufragen. Führen Sie eine Liste zugelassener Erweiterungen und geben Sie diese über eine zentrale Richtlinie vor. Unser Sicherheitsleitfaden für Browser-Erweiterungen geht speziell auf die Browser-Seite näher ein.
Was dadurch verhindert worden wäre
Im April 2026 entdeckteAikido eine gefälschte WakaTime-Erweiterung auf OpenVSX, die eine native Binärdatei enthielt, die vor jeglicher legitimen Erweiterungslogik geladen wurde, eine zweite Payload von einer GitHub-Releases-Seite abrief und diese mithilfe des jeweiligen Befehlszeilen-Installationsprogramms jedes Editors zwangsweise in jeden kompatiblen Editor auf dem Rechner installierte. Eine einzige Installation genügte, und VS Code, Cursor, Windsurf und VSCodium waren alle infiziert. Eine zentrale Zulassungsliste hätte dies verhindert, da eine gefälschte WakaTime-Erweiterung, die von einem unbekannten Konto veröffentlicht wurde, nicht auf der Liste der zugelassenen Erweiterungen gestanden hätte.
Die Einschränkung einer Whitelist besteht darin, dass sie nur so lange hilft, wie eine zugelassene Erweiterung sauber bleibt. GlassWorm hat auch legitime Erweiterungen kompromittiert, die viele Teams zugelassen hätten, und diese aktualisieren sich selbst, ohne dass jemand die Änderungen überprüfen kann. Deshalb ist neben der Liste auch die Ebene der Installationsphase von Bedeutung.
Schützen Sie Ihre Mitarbeiter
Berechtigungen zum Zeitpunkt der Konfiguration festlegen und die Laufzeit in einer Sandbox ausführen
Ein Agent, der beliebige Shell-Befehle ausführen und auf Ihre Produktionsdatenbank zugreifen kann, ist nur einen kompromittierten Befehl von einem vollständigen Sicherheitsverstoß entfernt. Erteilen Sie nur die Berechtigungen, die für die jeweilige Aufgabe erforderlich sind, und überprüfen Sie diese genauso, wie Sie ein Dienstkonto überprüfen würden. Führen Sie den Agenten anschließend in einer Sandbox mit Kontrollen für den ausgehenden Netzwerkverkehr aus, damit ein kompromittierter Agent dennoch nichts außerhalb der von Ihnen festgelegten Grenzen erreichen kann.
Die Festlegung des Gültigkeitsbereichs bei der Konfiguration und die Sandbox-Umgebung zur Laufzeit lösen jeweils eine der beiden Hälften des Problems. Ersteres schränkt ein, was der Agent anfordern darf. Letzteres schränkt ein, was geschieht, wenn der Agent dazu veranlasst wird, mehr anzufordern.
MCP-Server als Abhängigkeiten behandeln
MCP-Server bergen dieselben Lieferkettenrisiken wie jede andere Abhängigkeit. Daher sollten Sie MCP-Server nur aus verifizierten Quellen wie der offiziellen GitHub-MCP-Registry installieren. Bei über npm vertriebenen MCP-Servern sollten Sie diese in Ihrer Lockfile-Datei anhand des Integritäts-Hashes festlegen. Bei Git-basierten Servern sollten Sie einen vollständigen Commit-SHA anstelle eines Branches oder Tags festlegen. Vergewissern Sie sich vor der Installation, dass das Repository gepflegt wird und der Herausgeber bekannt ist. Wenn Sie aus einer Registry beziehen, behandeln Sie einen nicht verifizierten MCP-Server genauso wie ein nicht verifiziertes npm-Paket.
Im September 2025 tauchte auf npm ein Paket namens „postmark-mcp“ auf, das sich als offizieller MCP-Server ausgab, den ActiveCampaign für den E-Mail-Dienst Postmark betreibt. Seine Aufgabe bestand darin, einem KI-Assistenten das Versenden von E-Mails über Ihr Postmark-Konto zu ermöglichen, und über fünfzehn Versionen hinweg tat es genau das und nichts anderes. In Version 1.0.16 wurde eine Zeile hinzugefügt. Jede vom Server versendete E-Mail wurde über das eigene Konto des Opfers als Blindkopie an eine vom Angreifer kontrollierte Adresse weitergeleitet. Das bedeutete, dass Passwort-Zurücksetzungen, Rechnungen und alles andere, was ein Mitarbeiter versenden sollte, ebenfalls an einen Fremden gingen.
Behandle nicht vertrauenswürdige Eingaben, die bei einem Agenten eingehen, als Codeausführung
AikidoDie „PromptPwnd“-Studie war der erste bestätigte Praxistest, bei dem durch Prompt-Injection CI/CD-Pipelines kompromittiert wurdenI, wovon mindestens fünf Fortune-500-Unternehmen betroffen waren. Ein bösartiger Issue-Titel, der in einen Gemini-CLI-Workflow eingegeben wurde, führte dazu, dass der Agent unter Nutzung seines eigenen legitimen Zugriffs die Repository- secrets en in einen öffentlichen Issue-Thread schrieb.
Überprüfen Sie jeden Workflow, der einen Issue-Titel oder eine Pull-Request-Beschreibung an eine Agenten-Eingabeaufforderung weiterleitet. Behandeln Sie die Ausgabe des Agenten, die zu einem Shell-Befehl oder einem Dateischreibvorgang führt, als nicht vertrauenswürdig, bis sie validiert wurde.
Schädliche Pakete bereits bei der Installation und später im Repository erkennen
Programmierer denken sich Paketnamen aus, die plausibel klingen und nicht existieren, und Angreifer haben begonnen, diese Namen im Voraus zu registrieren und abzuwarten. Der Agent installiert das Paket, ohne weiter darüber nachzudenken, da der Name mit dem übereinstimmt, was er erwartet hat.
Um Slopsquatting zu verhindern, ist eine Malware-Erkennung an zwei Stellen erforderlich. Die erste erfolgt auf dem Rechner zum Zeitpunkt der Installation; dabei wird erfasst, wenn der Agent während einer Sitzung Daten abruft – dies entspricht der bereits erwähnten Kontrolle während der Installation. Die zweite erfolgt im Repository, wo ein Pull-Request, der eine neue Abhängigkeit einführt, überprüft wird, bevor er von jemandem zusammengeführt wird. Die zweite Ebene ist notwendig, da ein falscher Paketname von dem Rechner eines Entwicklers in die Codebasis gelangen kann, auf dem die Kontrolle bei der Installation von vornherein nie konfiguriert wurde.
Erstellen Sie einen Plan für die erste Stunde nach einem Malware-Angriff
Auditprotokolle erfassen
Leiten Sie das Audit-Protokoll Ihrer Organisation an ein SIEM weiter. Die wichtigsten Ereignisse sind Änderungen an der Registrierung und die Verwendung von Tokens, da sich eine Kompromittierung hier früher als anderswo bemerkbar macht. Welche Ereignisse konkret als Warnung gemeldet werden sollten, erfahren Sie in unserer GitHub-Actions-Sicherheitscheckliste, in der die zu überwachenden Ereignisse aufgeführt sind.
Der Axios-Angreifer veröffentlichte die Software manuell mit einem langfristig gültigen npm-Token, das er vom kompromittierten Rechner des Betreuers entwendet hatte, sodass keine verdächtige Anmeldung zu entdecken war. Den Zeitablauf konnten die Ermittler anhand des Registry-Eintrags rekonstruieren: Die E-Mail-Adresse des Kontos wurde in eine vom Angreifer kontrollierte Adresse geändert, woraufhin zwei Versionen im Abstand von 39 Minuten veröffentlicht wurden, die beide mit einem Zeitstempel versehen waren.
Erstellen Sie signierte SBOMs, damit die Frage nach der Sicherheitsanfälligkeit beantwortet werden kann
Wenn eine neue CVE veröffentlicht wird oder ein kompromittiertes Paket auftaucht, verbringen Teams ohne eine aktuelle „ Software-Stückliste “ (SBOM) Stunden damit, Abhängigkeiten manuell nachzuverfolgen, um herauszufinden, ob sie betroffen sind. Erstellen Sie für jedes Build-Artefakt eine solche Liste, einschließlich transitiver Abhängigkeiten, da die meisten Kompromittierungen mehrere Ebenen tief liegen. Die Axios-Payload gelangte über ein Paket ins System, das niemand explizit installiert hatte. Signieren Sie die „ SBOM “ zum Zeitpunkt des Builds, damit sie kryptografisch an den Build gebunden ist, der sie erzeugt hat, und speichern Sie sie zusammen mit dem Artefakt in Ihrer Registry, damit beide synchron bleiben.
Üben Sie die Rotationsstrategien, bevor Sie sie brauchen
Dokumentieren Sie, welche Zugangsdaten für jede Pipeline rotiert werden und wer befugt ist, die jeweilige Art von Zugangsdaten zu rotieren. Halten Sie anschließend fest, wie Sie überprüfen, ob eine Rotation tatsächlich abgeschlossen wurde, und führen Sie die Übung durch. Machen Sie sich im Voraus mit Ihrer Notfallmaßnahme vertraut. GitHub Enterprise unterstützt die Massenwiderrufung von Zugangsdaten für einen kompromittierten Benutzer oder für alle Benutzer im Unternehmen auf einmal. Diese Vorgehensweise ist zwar recht drastisch, aber besser als eine Rotation Dienst für Dienst, wenn Sie noch nicht wissen, wie weit die Kompromittierung reicht.
Wie „ Aikido Security“ zum Schutz vor folgenden Bedrohungen beiträgt Lieferkettenangriffe
Aikido Die Sicherheit umfasst die in diesem Beitrag beschriebenen Ebenen „Installationszeit“ und „Repository“. Die Erkennung erfolgt auf „ Aikido “ Intel, das alle neuen Pakete in durchschnittlich sechs Minuten analysiert und bösartige Pakete oft bereits innerhalb von ein bis zwei Minuten nach ihrer Veröffentlichung kennzeichnet.
„Device Protection“ überwacht, was auf den Computern der Entwickler installiert wird, und blockiert schädliche Pakete und Erweiterungen im gesamten Unternehmen. „Safe Chain“ ist die kostenlose Open-Source-Version für Privatpersonen, die schädliche Pakete bereits bei der Installation blockiert.
Die gleiche „Aikido “-Erkennung von Intel wird auf Ihre Repositorys angewendet, sodass eine bösartige Abhängigkeit, die in einen Pull-Request gelangt, markiert wird, bevor jemand sie zusammenführt – einschließlich eines „halluzinierten“ Paketnamens, der von einem Rechner stammt, auf dem kein Schutz bei der Installation vorhanden war. SAST deckt die Konfigurationsebene ab und markiert nicht vertrauenswürdige Eingaben, die in eine Agent-Eingabeaufforderung gelangen – dies ist das „PromptPwnd“-Muster.
