Future{hacks}: Der Unterschied zwischen Angreifer und Verteidiger: einer hat einen Plan

TL;DR: AI erhöht das Tempo. Angriffe werden schneller, günstiger und häufiger. Gleichzeitig kann Verteidigung schneller werden, wenn Zuständigkeiten und Abläufe klar sind. Die letzten Wochen zeigen das an zwei Beispielen: „Dirty Frag“ im Linux Unterbau und die Angriffe im npm Umfeld rund um TanStack.

Entscheidend ist am Ende nicht, wie gut eure Tools sind, sondern wie handlungsfähig ihr seid. Wisst ihr, woraus euer Produkt besteht? Ist klar, wer im Ernstfall entscheidet? Könnt ihr Lärm von echten Warnsignalen trennen? Open Source bleibt dabei die bessere Ausgangslage, weil sie Kontrolle und Alternativen ermöglicht. Sie hilft nur dann, wenn ihr Verantwortung nicht wegdelegiert, sondern sie aktiv organisiert.

AI beschleunigt Angriffe. Und zeigt gnadenlos, welche Unternehmen keine Antwort auf die Frage haben: Wer entscheidet, wenn es brennt?

Ende April kursierte im Linux-Umfeld eine Schwachstelle unter dem Namen „Dirty Frag“. Linux ist kein Nischenzeug. Es ist Basisbetrieb: Server, Appliances, Cloud-Images, Netzkomponenten, überall dort, wo man Stabilität erwartet und selten hinschaut.

Zur gleichen Zeit dokumentierten Sicherheitsforscher einen Angriff im npm-Ökosystem rund um TanStack, ein Werkzeug, das in unzähligen Frontend-Projekten steckt. Zwei Fälle, verschiedene Schichten. Das Muster ist dasselbe: Dinge kippen schneller, als Organisationen entscheiden können. Und AI sitzt dabei mit am Tisch.

Was AI hier wirklich macht

Security-Probleme sind kein neues Phänomen. Lieferkettenprobleme auch nicht. Was sich verändert, ist die Geschwindigkeit, mit der aus einer Idee ein Angriff wird und mit der aus einer Vermutung ein Exploit entsteht, der öffentlich landet.

AI senkt die Hürden: Recherche, Varianten, automatisierte Tests, überzeugendere Phishing-Mails. Das alles wird für Angreifer einfacher. Man muss daraus kein Weltuntergangsnarrativ machen. Die Logik reicht: Wenn mehr Menschen schneller mehr probieren können, steigt die Anzahl realer Vorfälle. Gleichzeitig kann dieselbe Technologie der Verteidigung helfen: Analyse wird schneller, Mustererkennung wird besser, Fixes lassen sich rascher testen und gute Teams gewinnen Zeit.

Wer profitiert, entscheidet nicht das Modell. Es entscheidet, wer vorbereitet ist.

Linux: Wenn das Fundament wackelt, wird es sofort teuer

Linux ist im Unternehmensalltag so unsichtbar erfolgreich, dass man es als gegeben betrachtet. Genau deswegen wirken Schwachstellen auf dieser Ebene so stark.

Solche Lücken sind oft der Verstärker nach einem ersten Einbruch. Ein Angreifer, der schon einen Fuß in der Tür hat, kann sich unter Umständen mehr Rechte verschaffen. Ab diesem Moment stehen mehr Systeme, mehr Daten und mehr Vertrauen auf dem Spiel.

In der idealen Welt gibt es Zeit für Teams, um zu prüfen, zu patchen, auszurollen und zu kommunizieren. In der realen Welt wird so etwas manchmal schneller öffentlich, als es Unternehmen lieb ist. Dann kippt der Modus von geordnetem Abarbeiten zu hektischem Krisenmanagement. Und Hektik ist besonders gefährlich dort, wo Verfügbarkeit Umsatz bedeutet.

In solchen Situationen zeigt sich, ob eine Firma führen kann. Security will das Risiko sofort senken. Operations will die Produktion stabil halten. Produktteams wollen Releases nicht einfrieren. Legal will keine Sätze freigeben, die in drei Wochen falsch aussehen. Irgendwer muss diesen Konflikt entscheiden. Wenn diese Rolle nicht klar ist, passiert das, was in vielen Unternehmen reflexartig passiert: Man wartet. Zeit ist im Security-Kontext selten ein Freund.

npm: Der Einfallstor ist nicht das Paket, sondern der Prozess

Wer nicht aus der Technik kommt, unterschätzt oft, wie sehr moderne Produkte aus Bausteinen bestehen. Teams ziehen Libraries, Frameworks, Plugins, Tools. Das ist der Grund, warum kleine Mannschaften heute sehr schnell liefern können.

Der Preis dafür ist eine Lieferkette, die sich nicht wie eine Lieferkette anfühlt. Im Einkauf würdest du kritische Lieferanten klassifizieren, Freigaben regeln, Risiken regelmäßig prüfen. Bei Softwarebausteinen passiert das oft informell. Es wirkt wie eine Entwicklerentscheidung, dabei ist es längst eine Betriebsentscheidung.

npm ist dafür das Paradebeispiel. Das Ökosystem ist riesig, die Abhängigkeiten sind tief, der Verteilweg ist schnell. Vorfälle in diesem Umfeld sind kein Ausreißer, sondern ein wiederkehrendes Muster.

Beim jüngsten Fall rund um TanStack war das Unangenehme nicht nur die Malware-Frage. Unangenehm ist der Hinweis, dass der Veröffentlichungsprozess selbst zum Einfallstor werden kann. Dann geht es nicht mehr nur darum, ob jemand ein falsches Paket installiert hat. Dann geht es um CI/CD, um Release-Workflows, um Tokens, um Rechte, kurz: ob die eigene Pipeline wie eine Bankfiliale gesichert ist oder wie eine WG-Küche.

In einem Betrieb lässt man niemals dieselbe Person Lieferanten anlegen, Rechnungen freigeben und Bankdaten ändern. In Build- und Release-Prozessen sehen Rollen und Rechte in vielen Firmen genau so aus. Nicht aus Fahrlässigkeit, weil es schnell gehen musste, und weil „funktioniert“ zu lange als Sicherheitskonzept durchging.

Abschotten als Reflex: verständlich, selten ausreichend

Cal.com hat angekündigt, Teile des produktiven Codes zu schließen, mit Sicherheitsargumenten rund um AI. Das ist aus Anbieterperspektive nachvollziehbar. Kundendaten, Vertrauen, Reputation hängen an Vorfällen.

Es löst trotzdem nichts von dem, was die letzten Wochen gezeigt haben. Abgeschlossener Code macht eine Pipeline nicht sicherer. Er macht Probleme unsichtbarer. Wer die Lieferkette nicht im Griff hat, hat sie mit weniger Sichtbarkeit genauso wenig im Griff. Die entscheidenden Fragen bleiben dieselben: Wie schnell erkennst du, ob du betroffen bist. Wer entscheidet. Ob die Pipeline kompromittiert werden kann. Abschotten kann in Einzelfällen ein sinnvoller Schritt sein, als Ersatz für diese Arbeit taugt es nicht.

Warum offene Systeme die bessere Ausgangslage sind

Open Source ist nicht automatisch sicher. Das zeigen die letzten Wochen sehr deutlich. Der Vorteil liegt woanders: Offene Systeme geben dir Optionen. Du kannst prüfen lassen. Du kannst vergleichen. Du kannst im Ernstfall ausweichen, weil du nicht vollständig an die Informationspolitik eines einzigen Anbieters gebunden bist. In der Vertragsrealität ist das Verhandlungsmacht. In der Betriebsrealität ist es Reaktionsfähigkeit.

Closed Source kann exzellent betrieben sein. Open Source kann miserabel betrieben sein. Das ist nicht der Punkt. Der Punkt ist: Willst du eine Welt, in der du dir Klarheit organisieren kannst, oder eine, in der du sie einkaufst und hoffen musst, dass sie stimmt.

Wachsamkeit ist keine Stimmung

„Security ist wichtig“ steht in Leitbildern. Einmal im Quartal klickt sich jeder durch das Pflicht-E-Learning, und alle fühlen sich kurz entschuldigt. Das ist keine Wachsamkeit. Wachsamkeit hat drei beobachtbare Bestandteile.

Erstens wissen, woraus eure Produkte bestehen, nicht als Architekturdiagramm, sondern so, dass man im Ernstfall nicht raten muss.

Zweitens wissen, wer entscheidet, wenn ein Release gestoppt werden muss. Wenn ein Update unbequem ist. Wenn Kunden informiert werden sollten, bevor sie es aus den Nachrichten erfahren.

Drittens wissen, was bei euch als brauchbare Information gilt. AI erhöht die Menge an Meldungen, Reports und Alarmen weiter. Wer alles gleich behandelt, versinkt. Wer nicht triagieren kann, verliert die Fähigkeit zu unterscheiden, was wirklich brennt und was Beschäftigungstherapie ist. Das trifft inzwischen auch die Open-Source-Welt selbst: Maintainer berichten, dass sie in Report-Fluten untergehen, weil die Hürden fürs Einsenden drastisch gefallen sind.

Viele Unternehmen wollen mehr Tools. Was fehlt, sind Zuständigkeiten. Viele wollen mehr Gewissheit. Was fehlt, ist Reaktionsfähigkeit.

Unser Future{hacks} Fazit

Hoffnung war in Security noch nie ein gutes Konzept. Mit AI wird sie nur schneller bestraft.

Markus Kirchmaier ist Prokurist & Partner bei LEAN-CODERS und beschäftigt sich seit Jahren intensiv mit dem IT-Arbeitsmarkt sowie modernen IT-Systemen und technologischen Entwicklungen. Hier geht es zu den anderen Beiträgen aus der Future{hacks}-Reihe.