Webentwicklung

Supply-Chain-Angriffe auf npm: Ein ständiges Sicherheitsrisiko

Ein hell erleuchtetes, modernes Arbeitszimmer mit einem entspannten Entwicklerteam, das konzentriert vor großen Bildschirmen sitzt, während warme Sonnenstrahlen durch große Fenster fallen und eine Atmosphäre von Vertrauen, Zusammenarbeit und digitaler Sicherheit schaffen.

Millionen von JavaScript-Entwicklern verlassen sich auf das Node Package Manager (npm)-Ökosystem – und genau das macht es zu einem beliebten Ziel für Cyberkriminelle. Die zunehmende Zahl an Supply-Chain-Angriffen auf npm zeigt: Die Sicherheit unserer Software beginnt nicht beim eigenen Code, sondern weit früher in der Lieferkette.

Ein wachsendes Problem: Supply-Chain-Angriffe auf Open-Source-Ökosysteme

In den letzten Jahren hat sich das Bedrohungsszenario für Softwareentwicklung dramatisch verändert. Besonders im Fokus stehen dabei sogenannte Supply-Chain-Angriffe. Statt direkt auf Unternehmensinfrastrukturen abzuzielen, manipulieren Angreifer immer häufiger öffentlich zugängliche Pakete in Open-Source-Repositories wie dem npm-Register, um anschließend über legitime Abhängigkeiten Zugang zu Millionen von Softwareprojekten zu erhalten.

Laut einem Bericht des Sicherheitsunternehmens ReversingLabs aus dem Jahr 2023 wurden im Zeitraum von Q1 bis Q3 allein im npm-Repository über 11.000 böswillige Pakete identifiziert, ein Anstieg von über 50 % gegenüber dem Vorjahr (Quelle: ReversingLabs, Software Supply Chain Threat Landscape Report 2023).

Ein Beispiel für einen solchen Angriff ist „IconBurst“ aus dem Jahr 2022, bei dem mehr als zwei Dutzend npm-Pakete mit bösartigem Code ausgestattet wurden, der Formulardaten stahl – darunter sensible Informationen wie Kreditkartennummern. Diese Pakete wurden millionenfach heruntergeladen, bevor sie entdeckt und entfernt wurden.

Die Sicherheitsinitiativen von GitHub und npm

Seit dem Erwerb von npm im Jahr 2020 hat GitHub – ein Tochterunternehmen von Microsoft – erheblich in die Sicherheit der Plattform investiert. Ziel ist es, Entwickler besser vor den wachsenden Risiken durch bösartige Pakete zu schützen. Zu den wichtigsten Maßnahmen gehören:

  • Mandatory Two-Factor Authentication (2FA): Seit Mai 2022 müssen Maintainer populärer Pakete zwingend 2FA aktivieren.
  • Automatisierte Malware-Scans: GitHub setzt auf Machine Learning, um potenziell schädliche Pakete automatisch zu erkennen. Diese Scans finden unter anderem beim Upload von Paketen statt.
  • Package Provenance Tracking: In Verbindung mit GitHub Actions ist es möglich, die Herkunft eines Pakets kryptografisch zu verifizieren. So kann nachgewiesen werden, dass ein veröffentlichtes Paket tatsächlich aus einem bestimmten Repository und Build-Prozess stammt.

Darüber hinaus beteiligt sich GitHub aktiv an der Open Source Security Foundation (OpenSSF), die gemeinschaftlich an einem sichereren Open-Source-Ökosystem arbeitet. Ein Ergebnis dieser Arbeit ist Sigstore – eine quelloffene Infrastruktur zum Signieren und Verifizieren von Softwareartefakten. Auch npm untersucht aktuell die Integration kryptografischer Signaturen als verpflichtende Komponente.

Gefahr erkannt – was Entwickler konkret tun können

Auch wenn Plattformbetreiber wie GitHub und npm erhebliche Schutzmaßnahmen etablieren, bleibt ein nicht unerheblicher Teil der Verantwortung bei den Entwicklerteams selbst. Sicherheit beginnt im Projekt – und hier können bereits einfache Maßnahmen erheblich zur Absicherung beitragen.

  • Verwendung von Lockfiles: Tools wie package-lock.json oder yarn.lock fixieren die konkreten Paketversionen und verhindern unbemerktes Einschleusen manipulierter Updates.
  • Abhängigkeiten regelmäßig updaten und prüfen: Automatisierte Tools wie npm audit, Snyk oder Dependabot informieren zuverlässig über bekannte Schwachstellen und stellen Pull Requests zur raschen Behebung bereit.
  • Vertrauenswürdige Maintainer prüfen: Kritische Pakete sollten idealerweise von aktiven, bekannten Maintainergruppen mit klarer Historie stammen. Vorsicht ist bei neuen oder kaum gepflegten Projekten geboten.

Eine statistische Analyse des Forschungsinstituts Endor Labs von 2024 zeigt, dass rund 91 % der gemeldeten Sicherheitsprobleme in Abhängigkeiten auf transitive Dependencies (also indirekte Abhängigkeiten) zurückgehen – ein Hinweis darauf, wie intransparent Software-Lieferketten aufgebaut sein können (Quelle: Endor Labs State of Dependency Report 2024).

Security by Design: Supply-Chain-Sicherheit in Entwicklungsprozesse integrieren

Softwareentwicklung braucht neue Sicherheitsarchitekturen. Wer Projekte professionell betreut, sollte die Sicherheit von Abhängigkeiten als festen Bestandteil des Lifecycles betrachten. Dazu gehört unter anderem das automatisierte Scannen jeder neuen Commit-Änderung, das Überwachen von Build-Prozessen sowie das Setzen klarer CI/CD-Policies.

In größeren Teams bietet sich die Integration von Security Gateways innerhalb der Build-Pipeline an. Diese prüfen, ob neue Pakete bestimmte Kriterien erfüllen, etwa hinsichtlich Herkunft, Lizenzierung und Sicherheitsrating. Tools wie Artifactory, Sonatype Nexus oder Tidelift bieten hier umfangreiche Funktionen – vom Pull-Request-Scanning bis zur zentralisierten Abhängigkeitskontrolle.

Mit Blick auf die Zukunft plant GitHub darüber hinaus noch tiefere Verknüpfungen zwischen Repository-Herkunft, Vertrauensmodellen und kryptografischer Signierung – ein deutliches Signal, dass Supply-Chain-Sicherheit nicht nur technisch, sondern auch prozessual gefasst werden muss.

Fazit: Sicherheit ist keine Nebensache

npm ist ein integraler Bestandteil moderner Webentwicklung – aber auch eine Angriffsfläche, die sich mit der Größe des Ökosystems multipliziert. Die gute Nachricht: Durch das wachsende Sicherheitsbewusstsein, verstärkte Schutzmaßnahmen durch GitHub und etablierte Best Practices in der Community ist ein robusterer Umgang mit Softwarelieferketten möglich.

Wer heute Software entwickelt, muss nicht nur Code schreiben – sondern auch Verantwortung im Umgang mit Abhängigkeiten tragen. Das bedeutet: aufklärung, strukturierte Prozesse und Bereitschaft zur kontinuierlichen Verbesserung. Die Community ist gefragt, diese Sicherheit gemeinsam weiter auszubauen.

Welche Tools und Strategien nutzt ihr, um eure Projekte vor Supply-Chain-Angriffen zu schützen? Teilt eure Erfahrungen mit uns in den Kommentaren oder auf unseren Social-Media-Kanälen!

Schreibe einen Kommentar