KW 19/2026: Supply-Chain-Angriffe auf dem Vormarsch

Diese Woche in der IT-Security lässt sich in einem Satz zusammenfassen: Vertrauen war einmal. Drei Vorfälle – kompromittierte Softwarepakete bei NPM und PyPI, ein verseuchtes Jenkins-Plugin und der ewige Irrglaube, Passwortänderungen beseitigten Angreifer aus Active Directory – zeigen, wie dünn die Sicherheitsdecke vieler Unternehmen inzwischen geworden ist. Besonders erschreckend: In allen Fällen kommen Angreifer über legitime, vermeintlich sichere Quellen. Und genau das macht die Situation so gefährlich.

Laut Golem wurden Hunderte Pakete in den Repositories NPM und PyPI kompromittiert. Hinter dem Angriff steckt offenbar eine Gruppe mit dem Namen TeamPCP, die Schadcode in zahlreiche Open-Source-Pakete eingeschleust hat. Der Code sammelt Anmeldeinformationen und Umgebungsdaten – insbesondere in Build-Systemen. Heißt im Klartext: Wer diese Pakete in seine Software einbindet, füttert Angreifer unfreiwillig mit Zugangsdaten zu Produktionssystemen.

Technisch ist das kein Hexenwerk. Die meisten dieser Pakete werden automatisch in CI/CD-Pipelines eingebunden – Stichwort: npm install. Wenn dort ein präpariertes Paket landet, ist der Schaden schnell groß. In der Lieferkette ist kaum auffällig, ob ein Modul echten Code oder Schadfunktionen enthält. Eine Signaturprüfung oder Paketvalidierung ist oft nicht aktiv – und genau das nutzen Angreifer.

Ehrlich gesagt, überrascht mich das nicht. Wir sprechen seit Jahren davon, dass Lieferketten-Security mehr ist als nur Versionierung. Trotzdem sehe ich in vielen Unternehmen in NRW und auch hier in der Städteregion Aachen immer wieder: Niemand überprüft, welche Dependencies im Build-Prozess landen. Dabei wäre das eine Basismaßnahme. Aus meiner Sicht ist das Problem nicht fehlende Technik, sondern fehlendes Bewusstsein. Supply-Chain-Sicherheit klingt komplex – ist aber längst Pflicht.

Das Bittere daran: Angriffe wie dieser richten sich nicht an Endanwender, sondern treffen Entwickler und Integratoren. Eine infizierte Abhängigkeit landet blitzschnell in Dutzenden Projekten. Und damit ist das Risiko nicht mehr theoretisch – es betrifft reale Produktionssysteme. Wenn ein Node.js-Modul plötzlich Credentials abgreift, geht es schnell um mehr als nur Quellcode-Leaks.

Ein zweites Beispiel aus dieser Woche zeigt, wie verwundbar unsere Build-Systeme wirklich sind. Laut BleepingComputer wurde ein offizielles Checkmarx-Plugin für Jenkins kompromittiert und im Jenkins Marketplace veröffentlicht. Dieses Plugin enthielt einen Infostealer, also Malware, die gezielt Zugangsdaten abgreift. Besonders kritisch: Jenkins-Server sind das Herzstück vieler CI/CD-Prozesse. Sie haben Zugriff auf Repositories, SSH-Schlüssel, Deployment-Zugangsdaten – kurz: auf alles, was man für einen erfolgreichen Angriff braucht.

Die Ironie dabei? Checkmarx ist eigentlich ein Anbieter für Anwendungssicherheit. Ein Plugin, das Sicherheitsanalysen durchführen soll, wird selbst zum Angriffsvektor – das ist fast schon schwarz-humorig. Aber genau solche Widersprüche sind im Security-Bereich Alltag. Software, die Vertrauen schaffen soll, wird zum Risiko. Das ist fast schon ein Paradebeispiel für die Abhängigkeit der Branche von Drittsystemen.

Wenn also ein Angreifer ein kompromittiertes Plugin über den offiziellen Marktplatz verteilt, greifen herkömmliche Schutzmechanismen zu kurz. Kein Virenscanner springt an, kein Admin bekommt einen Alarm – schließlich kommt die Software von einer legitimen Quelle. Hier zeigt sich auch die Parallele zum NPM-Vorfall: Der Angreifer nutzt Vertrauen als Waffe. Aus meiner Sicht ist das die neue Form des Social Engineering – nicht im Posteingang, sondern im Code-Repository.

Unternehmen in der Region sollten ihre Jenkins-Installationen prüfen, insbesondere Plugins, die in den letzten Wochen aktualisiert wurden. Wer CI/CD ernst nimmt, muss auch das Plugin-Management ernst nehmen. Und ganz ehrlich: Die häufig anzutreffende Haltung „Das wird schon passen“ ist in 2026 einfach keine Option mehr.

Wer glaubt, Security-Probleme seien nur eine Frage des Patch-Levels, wird beim dritten Thema dieser Woche eines Besseren belehrt. BleepingComputer beschreibt, warum selbst eine umfassende Passwortänderung nach einem Angriff auf Active Directory oft nichts bringt. Die Gründe liegen im Kerberos-Protokoll: Es generiert sogenannte Tickets – also kryptografische Zugangsberechtigungen, die oft tagelang gültig bleiben. Wer ein solches Ticket (oder gar die Ticket-Granting-Datenbank) besitzt, kann sich auch nach einer Passwortänderung weiter authentifizieren.

Noch gravierender sind persistente Angriffsmechanismen wie der Golden Ticket oder Skeleton Key. Dabei manipulieren Angreifer den Domain Controller so, dass sie dauerhaft Zugang behalten – unabhängig vom Passwort. Das heißt: Selbst wenn alle Passwörter neu gesetzt werden, kommt der Angreifer weiterhin rein. Wer das übersieht, wiegelt sich in trügerischer Sicherheit.

Aus meiner Sicht ist das einer der gefährlichsten Irrtümer in der Praxis. Ich sehe es häufig in Incident-Response-Fällen: Nach der Passwortänderung klopft niemand mehr kritisch nach, ob Kerberos-Tickets widerrufen oder SPN-Schlüssel rotiert wurden. Solange Active Directory-Komponenten nicht gründlich forensisch überprüft werden, bleibt der Feind im System. Und hier schließt sich der Kreis zu den anderen Themen: Vertrauen in bestehende Infrastruktur kann fatal sein, wenn deren Integrität nicht geprüft wird.

Diese drei Vorfälle zeigen glasklar, dass Supply-Chain- und Infrastruktur-Sicherheit zusammenhängen. DevOps, IT-Operations und Security müssen enger zusammenarbeiten. Wenn Sie Jenkins oder eine ähnliche CI/CD-Landschaft betreiben, stellen Sie sicher, dass jedes Plugin geprüft, jede Abhängigkeit signiert und jeder Build-Prozess überwacht wird. Integrität kann nicht an Dritte ausgelagert werden – auch nicht an Marktplätze oder Open-Source-Repositories.

NPM- und PyPI-Nutzer sollten auf Auffälligkeiten in Build-Skripten achten und Sicherheitsfeeds abonnieren, die kompromittierte Pakete melden. Bei Jenkins empfiehlt es sich, nur Plugins aus bekannten Quellen mit überprüften Zertifikaten einzusetzen und regelmäßig auf Integritäts-Hashes zu achten. Und wenn ein Plugin Zugriff auf Secrets braucht: prüfen, ob das wirklich notwendig ist. Weniger Berechtigungen bedeuten weniger Risiko.

Für Active Directory gilt: Passwortänderungen sind nur ein Teil der Bereinigung. Wer sichergehen will, dass Angreifer nicht mit alten Tickets zurückkehren, muss KDC-Schlüssel rotieren, Tickets invalidieren und Anomalien im Kerberos-Traffic überwachen. Es mag aufwendig klingen, ist aber essentiell. Vor allem für Unternehmen in der Region Aachen, wo viele Produktions- und Forschungsnetzwerke noch immer auf klassischen AD-Strukturen basieren.

Aus diesen Fällen lernen wir auch, dass Security nicht an der Firewall endet. Angriffe beginnen längst im Code und in der Build-Kette. Was früher der infizierte E-Mail-Anhang war, ist heute das scheinbar harmlose NPM-Paket oder Jenkins-Plugin. Die Grundlage bleibt dieselbe: Vertrauen ist gut, Validierung ist besser.

Diese Woche verdeutlicht, wie sich die Bedrohungslage verschoben hat. Angreifer setzen nicht mehr auf simple Exploits, sondern infizieren die Tools, mit denen wir Software entwickeln, testen und ausliefern. Das ist clever, effizient – und brandgefährlich.

Aus meiner Sicht ist das größte Problem nicht technische Komplexität, sondern die Bequemlichkeit vieler Organisationen. Wir sind es gewohnt, Software zu installieren und zu vertrauen. Doch genau dieses Vertrauen wird zunehmend ausgenutzt. Wenn selbst offizielle Marktplätze kompromittiert werden, müssen wir unsere Prozesse hinterfragen: Prüfen wir, was wir installieren? Wissen wir, wessen Code wir in unsere Systeme holen?

Die gute Nachricht: Wir können handeln. Mit reproduzierbaren Builds, Paket-Signaturen, kontrollierten Zugriffsrechten und forensischer Wachsamkeit lässt sich viel erreichen. Aber es braucht den Willen dazu – und die Zeit. Wenn Sie unsicher sind, ob Ihre Build- oder AD-Umgebungen gegen solche Angriffe gewappnet sind, sprechen Sie mich an. Ein Security-Audit für CI/CD-Prozesse oder AD-Infrastrukturen ist kein Luxus, sondern eine Versicherung gegen den nächsten Lieferketten-GAU.