Jedes npm install, pip install oder jeder Maven-Build holt Code von Menschen, die Sie nie getroffen haben, in Ihr Produkt. Im März 2026 hat die ENISA das Technical Advisory for Secure Use of Package Managers veröffentlicht, einen kurzen, praxisnahen Leitfaden, wie das sicher gelingt. Dieser Artikel fasst ihn zusammen und ergänzt einige Anmerkungen aus unserer eigenen SCA-Arbeit.
Was die Empfehlung abdeckt
Die Empfehlung liegt in Version 1.1 vor. Sie wurde nach einer Konsultation zwischen Dezember 2025 und Januar 2026 mit 15 Beiträgen überarbeitet und steht unter der Lizenz CC BY 4.0.
Der Umfang ist bewusst eng: das Nutzen von Paketen und das Verwalten von Abhängigkeiten auf Anwendungsebene. Paketmanager von Betriebssystemen, das sichere Veröffentlichen von Paketen, die Sicherheit der Registries selbst und Secure Coding sind ausgeklammert. Die Beispiele nutzen vor allem npm und GitHub, die Prinzipien gelten aber für jedes Ökosystem.
Sie installieren mehr, als Sie denken
Die Empfehlung beginnt mit einem einfachen Beispiel. Ein zehnzeiliger Node.js-Webserver mit dem Framework express zieht etwa 27 direkte Abhängigkeiten nach sich und insgesamt 68 Pakete, sobald die transitiven Abhängigkeiten aufgelöst sind. Jedes davon ist jetzt Teil Ihres Produkts.
Die ENISA macht dazu zwei Punkte, die sich zu wiederholen lohnen:
- Fremder Code gehört nicht mehr jemand anderem, sobald er in Ihrem Build steckt. Er wird Teil Ihrer vertrauenswürdigen Codebasis und verdient dieselbe Prüfung wie Ihr eigener Code.
- Installierter Code ist nicht gleich erreichbarer Code. Ihre Anwendung führt vielleicht nur einen kleinen Teil eines Pakets aus. Eine Schwachstelle in Code, der nie ausgeführt wird, ist weniger wahrscheinlich ausnutzbar, aber “nicht direkt erreichbar” ist keine Garantie: Reflection, Fehlkonfigurationen oder präparierte Eingaben können unerwartete Pfade öffnen.
Dieselbe Vernetzung, die Paketmanager nützlich macht, verbreitet auch Probleme. Fast 100.000 Pakete hängen direkt von express ab, und weit über eine Million Projekte, wenn man die transitive Nutzung mitzählt.
Zwei Arten von Risiken
Die ENISA teilt die Risiken der Paketnutzung in zwei Kategorien ein.
Pakete mit eigenen Schwachstellen
Die erste Kategorie sind Schwächen in den Paketen selbst: unsicherer Code oder unsicheres Design, zu großzügige Standardeinstellungen oder offene Debug-Modi. Sie landen in Ihrer Angriffsfläche, obwohl Sie sie nicht geschrieben haben.
Nicht gepflegte Pakete machen es schlimmer. Die Beispiele der Empfehlung:
- node-serialize: Die letzte Version, vor elf Jahren veröffentlicht, hat eine bekannte kritische Schwachstelle bei der Deserialisierung. Die einzige Abhilfe ist, das Paket nicht zu nutzen, und doch wird es weiterhin jede Woche heruntergeladen.
- tokio-tar: Die Schwachstelle “TARmageddon” stammte aus dieser verwaisten Rust-Bibliothek, Jahre nachdem die Pflege eingestellt worden war.
- crypto-js: laut eigenem Repository eingestellt, aber immer noch millionenfach pro Woche heruntergeladen.
Angriffe auf die Lieferkette
Die zweite Kategorie sind Angriffe, bei denen jemand einen Lieferanten kompromittiert, um dessen Kunden zu erreichen:
| Angriff | Funktionsweise | Beispiele aus der Empfehlung |
|---|---|---|
| Schadpakete | Ein Angreifer veröffentlicht ein neues Paket mit Schadcode und wartet, bis Entwickler es installieren, direkt oder als transitive Abhängigkeit. | crypto-encrypt-ts; die Malware GlassWorm in VS-Code-Erweiterungen |
| Kompromittierte legitime Pakete | Ein Angreifer erlangt Veröffentlichungsrechte über ein gestohlenes oder per Social Engineering erschlichenes Maintainer-Konto, oder ein Maintainer richtet das Paket gegen die eigenen Nutzer. | event-stream, ua-parser-js, der npm-Angriff vom September 2025 auf 18 Pakete mit 2,6 Milliarden Downloads pro Woche, colors und faker |
| Typosquatting | Ein Schadpaket mit einem Namen ähnlich dem eines beliebten Pakets, das auf einen Tippfehler wartet. | crossenv als Imitat von cross-env |
| Dependency Confusion | Ein öffentliches Paket mit demselben Namen wie ein internes und einer höheren Versionsnummer, das von Build-Tools übernommen wird, die beide Registries abfragen. | Die Forschung von 2021, die Dutzende großer Unternehmen erreichte |
In beiden Fällen pflanzt sich die Wirkung fort. Die Empfehlung verweist auf CVE-2025-55182 in React mit CVSS 10,0, die erste Schätzungen mit über 12 Millionen Websites in Verbindung brachten.
Vier Phasen der Paketnutzung
Kern der Empfehlung ist ein einfacher Lebenszyklus für jede Abhängigkeit: auswählen, integrieren, überwachen und abmildern. Die ersten beiden Phasen bauen Sicherheit ein, die letzten beiden erhalten sie. Für jede Phase gibt die ENISA Empfehlungen und ein Cheatsheet mit Beispielbefehlen.
1. Auswählen: vertrauenswürdige Pakete wählen
Fragen Sie sich zuerst, ob Sie das Paket überhaupt brauchen. Weniger Abhängigkeiten bedeuten eine kleinere Angriffsfläche und weniger Verwaltungsaufwand. Prüfen Sie dann:
- dass es aus einer offiziellen Registry stammt, idealerweise über einen sicheren Workflow mit Provenance veröffentlicht, etwa Trusted Publishing von npm
- die bekannten Schwachstellen, in OSV, der EU Vulnerability Database (EUVD), der NVD oder einer kommerziellen Datenbank
- dass Paket und Registry Signaturen und Integritäts-Hashes unterstützen und Sie nicht direkt aus einem Git-Repository oder einer Tarball-URL installieren, die diese Prüfungen umgeht
- die Maintainer: Vorsicht bei Paketen von neuen Konten mit nur einem Projekt
- Anzeichen aktiver Pflege: aktuelle Commits, getaggte Releases, bearbeitete Issues, eine SECURITY.md-Datei. Die ENISA warnt, dass Sterne und Downloadzahlen aufgebläht sein können und nicht allein ausschlaggebend sein sollten.
- Installationsskripte, die zusätzlichen Code oder Binärdateien von externen URLs laden
Zum Beispiel mit npm:
npm audit signatures # Signaturen und Provenance prüfen
npm view <package> scripts # nach Pre- und Post-Install-Skripten suchen
npm view <package> maintainers
npm ls --all # den vollständigen Abhängigkeitsbaum prüfenDie ENISA empfiehlt außerdem, wo möglich eine interne Allowlist genehmigter Pakete oder Maintainer zu führen.
2. Integrieren: kontrollieren, was Sie installieren
- Erzeugen Sie bei jedem Build eine SBOM, damit Sie für Sicherheit und Compliance einen Nachweis jeder Abhängigkeit haben.
- Lassen Sie den Build scheitern, wenn er Komponenten mit bekannten hohen oder kritischen Schwachstellen enthält.
- Erzwingen Sie Integrität: npm prüft die SHA-512-Hashes in der Lockfile automatisch; pip braucht dafür
--require-hashes. - Beschränken Sie Installationen auf vertrauenswürdige Registries, idealerweise über eine lokale Registry oder einen Proxy wie Nexus Repository, JFrog Artifactory oder Verdaccio. Ein Caching-Proxy hält Ihre Builds auch dann am Laufen, wenn ein Paket upstream verschwindet.
- Deaktivieren Sie Installationsskripte, wo es geht, und nehmen Sie in Kauf, dass manche Pakete dann nicht funktionieren.
- Pinnen Sie Versionen mit einer eingecheckten Lockfile und nutzen Sie diese in der CI (
npm ci). Lesen Sie Changelogs, bevor Sie aktualisieren.
npm ci --ignore-scripts # genau die Lockfile installieren, ohne Installationsskripte
npm audit --omit=dev --audit-level=high # bei hohen oder kritischen Befunden scheitern
pip install --require-hashes -r requirements.txtDie ENISA benennt den Zielkonflikt beim Pinnen: Es schützt vor ungeprüften Updates, verlängert aber Ihre Gefährdung durch bekannte Schwachstellen, wenn niemand Updates regelmäßig prüft und einspielt. Außerdem nennt sie eine optionale, situationsabhängige Maßnahme: nur Versionen zu installieren, die vor mindestens einigen Tagen veröffentlicht wurden. Das gibt der Community Zeit, ein bösartiges Release zu bemerken, bevor es Ihren Build erreicht.
3. Überwachen: Veränderungen bemerken
Abhängigkeiten, die am Tag ihrer Aufnahme sicher waren, bleiben es nicht. Die ENISA empfiehlt:
- SBOM-Daten für kontinuierliche Schwachstellenprüfungen zu nutzen, etwa mit Grype oder OSV-Scanner
- Abhängigkeiten nach Zeitplan in der CI zu scannen, nicht nur bei Codeänderungen
- Schwachstellen-Feeds wie EUVD, OSV und die NVD sowie maschinenlesbare Herstellerhinweise im CSAF-Format zu verfolgen
- veraltete Versionen im Blick zu behalten
- Benachrichtigungen für neue CVEs in gepinnten Versionen, für veraltete oder nicht gepflegte Releases, fehlende Maintainer-Aktivität und Wechsel von Maintainern oder Eigentümern
Die letzte Gruppe wird leicht übersehen. Ein neuer Maintainer war der Ausgangspunkt des event-stream-Angriffs, und nur wenige Teams achten auf Eigentümerwechsel.
4. Abmildern: erst bewerten, dann beheben
Die Empfehlung ist erfrischend ehrlich in Bezug auf SCA-Befunde. Eine verwundbare Version in Ihrem Abhängigkeitsbaum bedeutet, dass das Paket Code enthält, der unter bestimmten Bedingungen ausgenutzt werden könnte. Sie bedeutet nicht automatisch, dass Ihre Anwendung verwundbar ist.
Die Schritte der ENISA zur Abmilderung:
- Bewerten Sie den Befund mit mehr als dem CVSS-Wert: EPSS für die Wahrscheinlichkeit einer Ausnutzung, der Known-Exploited-Vulnerabilities-Katalog der CISA, VEX-Aussagen des Lieferanten und Erreichbarkeitsanalysen mit Tools wie CodeQL oder Semgrep.
- Priorisieren Sie anhand einer festgelegten Risikoschwelle, etwa “CVSS 7,0 oder höher oder EPSS 0,3 oder höher hat hohe Priorität”, und konzentrieren Sie sich auf erreichbare, ausnutzbare Schwachstellen in Produktionsabhängigkeiten.
- Mildern Sie ab, indem Sie aktualisieren, eine vorübergehende Maßnahme wie eine WAF-Regel oder ein Feature-Flag einsetzen oder das Paket entfernen, zurückrollen oder isolieren, wenn es keine Korrektur gibt.
- Dokumentieren und informieren Sie: Halten Sie einen VEX-Status fest (affected, not affected, under investigation oder fixed), erzeugen Sie die SBOM neu, aktualisieren Sie die Release Notes und informieren Sie bei Bedarf Kunden, Behörden oder interne Teams.
Automatisierung und KI-gestützte Entwicklung
Die Empfehlung schließt mit zwei Ausblicken. Manuelle Prüfungen skalieren nicht auf Hunderte Abhängigkeiten in vielen Repositories, deshalb gehören SBOM-Erzeugung (Syft, CycloneDX), Scans (Grype, OSV-Scanner) und Installationskontrollen in die CI/CD-Pipeline.
Und KI-Codeassistenten verändern, wer Abhängigkeiten auswählt. Wenn Code mit wenig menschlicher Prüfung entsteht, weiß vielleicht niemand, warum ein Paket hinzugefügt wurde. Die ENISA nennt “Slopsquatting”: Angreifer registrieren Paketnamen, die KI-Tools erfinden. Ihr Rat: den Überblick über jedes Paket behalten, das KI-generierter Code einführt, prüfen, ob jedes davon nötig ist, die Prüfungen bei Auswahl und Integration automatisieren und Erkennung und Reaktion stärken, um die geringere Prüfung im Vorfeld auszugleichen.
Warum das für den CRA wichtig ist
Der Cyber Resilience Act macht vieles davon für Hersteller verpflichtend. Sie müssen bei der Integration von Komponenten Dritter, auch Open Source, die gebotene Sorgfalt walten lassen, eine SBOM erstellen und Schwachstellen in den gelieferten Komponenten während des gesamten Unterstützungszeitraums erkennen und beheben. Die Empfehlung nennt den CRA nicht beim Namen, aber ihre vier Phasen lesen sich wie eine praktische Umsetzung dieser Pflichten. Unser CRA-Leitfaden für KMU behandelt sie ausführlich.
Unsere Einschätzung
Für Teams, die mit npm, Python oder Java arbeiten, ist das eine gute Checkliste neben der CI-Pipeline. Sie ist kurz und konkret, und die Cheatsheets machen aus jeder Empfehlung einen Befehl, den Sie heute ausprobieren können. Der Abschnitt zur Abmilderung verdient besondere Aufmerksamkeit: Teams, die jeden SCA-Befund als gleich dringend behandeln, reiben sich an False Positives auf und übersehen die wenigen, die zählen.
Zwei Einschränkungen. Die Beispiele sind stark auf npm ausgerichtet; laut Empfehlung gelten die Prinzipien auch anderswo, und das stimmt, aber die passenden Maßnahmen in Ihrem eigenen Ökosystem müssen Sie selbst finden. Und C und C++ kommen gar nicht vor, obwohl sie ein eigenes Problem mitbringen: SBOM-Komponenten fehlen oft die Identifier, die Schwachstellendatenbanken brauchen. Unser Artikel zur CPE-Anreicherung für C++-Bibliotheken in Conan-Builds schließt diese Lücke, und unsere Anleitung zum Betrieb von OWASP Dependency-Track zeigt einen Weg zu SBOM-basierter Überwachung. Zu SBOMs allgemein haben wir einen Überblick über die ENISA-Empfehlung zu Software Bills of Materials geschrieben.
Die ENISA betont außerdem, dass die genannten Tools Beispiele sind, keine Empfehlungen. Es geht um die Maßnahme, nicht um die Marke.