| Liebe Leserin, lieber Leser,
|
| KI als Spürhund für bessere Pentests und Codereviews einzusetzen, klingt im ersten Moment naheliegend. Aber das ist kein Selbstläufer. Das zeigen die vielen Klagen der Open-Source-Projekte, die vor einer Flut von KI-Meldungen vermeintlicher Lücken stehen. Wie man seinen Workflow dafür anpassen muss, warum Mozilla das vorbildlich wuppt und wo jetzt der Flaschenhals liegt – das erklärt einer unserer Titelautoren Stephan Zeisberg im Interview. Einen Überblick aller Themen des neuen Hefts finden Sie im Inhaltsverzeichnis der iX 8/2026.
|  |
|
|
| |
|
|
| | | | Codereview mit KI: Verifikation ist der neue Engpass | |
| |
| |
Stephan Zeisberg ist Head of Research bei Security Research Labs (SRLabs) und forscht zu KI-gestützten Codeaudits und Schwachstellenanalyse.
Axel: Wenn KI so viele Lücken aufspürt, müsste die Softwarewelt damit doch sicherer werden. Warum geraten stattdessen viele Open-Source-Projekte und Security-Teams gerade jetzt unter Druck?
Stephan: Weil das reine Erzeugen einer Schwachstellen-Meldung inzwischen die billigste Stufe im Prozess geworden ist. Der eigentliche Wert entsteht aber erst weiter oben. Ein Befund wird erst dann zu Sicherheit, wenn ein Mensch prüft, ob er echt ist, ob er im konkreten System erreichbar ist und ob ein Patch das Problem wirklich löst. Genau dort sitzt jetzt der Engpass. curl hat sein Bug-Bounty-Programm im Januar eingestellt, HackerOne den Internet Bug Bounty im März pausiert, Node.js sein eigenes Bounty kurz danach suspendiert, und Linus Torvalds nennt die Linux-Kernel-Security-Liste im Mai öffentlich "almost entirely unmanageable".
Alle geben denselben Grund an: KI-Werkzeuge produzieren plausibel klingende Reports schneller, als die Empfängerseite sie triagieren, verifizieren und beheben kann. Der Anteil echter Schwachstellen in diesen Reports ist niedrig geblieben – was massiv gestiegen ist, ist das Volumen. Wer nur mehr Findings zählt, misst nicht mehr Sicherheit, sondern die Belastung des Systems. Sicherer wird die Welt erst, wenn die Verifikationsseite mit der Discovery-Seite mitwächst, und das tut sie gerade nicht.
Axel: Was ist denn wichtiger für den Erfolg KI-gestützter Audits – ein möglichst starkes Modell oder doch eher der Workflow?
Stephan: Beides zählt, aber der Hebel liegt eindeutig im Workflow, vor allem für Teams, die KI-Audits gerade erst einführen. Ein zusätzlicher Punkt auf einem Coding-Benchmark bringt weniger als eine ordentliche Reproduktions-Stufe im Prozess. Das zeigt Mozilla mit Firefox 150: 271 geschlossene Sicherheitsbugs in einem einzigen Release, darunter ein 20 Jahre alter Fehler in der XSLT-Engine, kamen nicht aus einem neuen Modell allein. Sie kamen aus einer Pipeline, in der jedes Modell-Finding einen reproduzierbaren Testfall mitbringen muss und die Reproduktion automatisch ausgeführt wird. Das Modell liefert Kandidaten, die Pipeline sortiert das Rauschen aus.
Umgekehrt gilt: Das stärkste Modell ohne diese Disziplin produziert mehr Rauschen, nicht mehr Sicherheit. Die 80 Prozent Falsch-Positive, die für 2024 und 2025 vielfach berichtet wurden, galten für Modelle, die ohne Reproduktions-Stufe direkt auf eine Codebasis angesetzt wurden. Mit einer disziplinierten Pipeline fällt der Wert deutlich. Welches Modell darauf läuft, ist am Ende zweitrangig gegenüber der Frage, ob überhaupt eine Pipeline da ist.
|
| |
|
|
| |
|
| |
|
|
| | Stephan Zeisberg (links) im Gespräch mit iX-Redakteur Axel Kannenberg
|
|
| |
|
| |
|
| | Axel: Mozilla wird derzeit ja oft als Vorreiter genannt. Was machen die Entwickler dort anders als die meisten anderen Projekte?
Stephan: Zwei Dinge, die nicht mit KI angefangen haben. Erstens hat Mozilla seit Jahren eine Fuzzing-Infrastruktur mit reproduzierbaren Test-Cases, automatisierter Deduplizierung und integriertem Triage-Prozess aufgebaut. Zweitens haben sie darauf eine agentische Test-Pipeline gesetzt, die das KI-Modell zwingt, jeden Befund mit einem reproduzierbaren Testfall zu belegen und die Reproduktion selbst zu fahren. Was sich nicht reproduzieren lässt, fällt raus, bevor ein Mensch es sieht. Der Punkt, der leicht übersehen wird: Neu ist nicht der Baustein, sondern die Kombination. Fuzzing-Pipelines dieser Art baut Mozilla seit über einem Jahrzehnt.
Neu ist, dass ein modernes Modell in dieser Pipeline zur eigentlichen Signal-Quelle wird. Dazu kommt ein ehrlicher Blick auf die Ressourcen: Mozilla hat über 100 Personen in die Triage der 423 Sicherheitsbugs im April eingebunden. Für die meisten Open-Source-Projekte, in denen ein oder zwei Menschen die Sicherheit mittragen, taugt so nicht als Bauplan, aber als Orientierung. Vorbildhaft ist die Reihenfolge der Investitionen: erst die Verifikationspipeline gebaut, dann KI drangeschraubt.
Axel: Und was sollte ein Team tun, das mit KI-Codeaudits starten will, aber nicht die ausgefeilte Infrastruktur Mozillas zur Verfügung hat?
Stephan: Vor allem: nicht früh und breit einsetzen. Genau das produziert die Triage-Tretmühle, in der Reviewer nur noch Tool-Output aussortieren statt selbst zu lesen. Was in der Praxis funktioniert, ist ein disziplinierter Einsatz in drei getrennten Stufen. KI vor dem Audit, um die Codebasis zu kartieren, Module und Eintrittspunkte zu identifizieren. KI während des Audits als Navigations- und Recherche-Hilfe. Und KI nach dem manuellen Review als zweite Sicht, die bekannte Muster prüft. Die Reihenfolge ist entscheidend: Wenn KI die erste Sicht liefert, prägt sie den Ersteindruck der Reviewer. Wenn sie die letzte Sicht ist, findet sie, was Menschen entgangen ist.
Dazu vier Regeln: Jedes KI-Finding braucht einen falsifizierbaren Reproduktionsfall, sonst bleibt es Hypothese. Die Findings-Menge wird pro Code-Bereich gedeckelt, damit die KI ihre Kandidaten selbst priorisiert; sonst lernen Reviewer, den ganzen Kanal zu ignorieren. Threat-Modell und die Einschätzung des Schweregrads bleiben in menschlicher Hand. Und wo KI auch Code schreibt, greift eine zusätzliche Schwelle mit dokumentierter Absicht und Negativ-Testfällen. Für Solo-Maintainer, die kritische Open-Source-Bibliotheken alleine tragen, ist das übrigens kein realistisches Programm. Dort ist die Antwort weniger ein besserer Workflow als eine gemeinschaftlich finanzierte Triage-Kapazität.
Axel: Welche Arten von Schwachstellen bleiben der KI noch verborgen?
Stephan: Drei Kategorien bleiben strukturell schwierig, auch mit den aktuellen Frontier-Modellen. Erstens Business-Logik: Modelle erkennen, was Code tut, aber nicht, was er tun sollte. Wenn ein Autorisierungs-Check an Stelle A definiert und an Stelle B umgangen wird, ohne dass die Absicht dazwischen dokumentiert ist, hat das Modell keine Referenz, gegen die es eine Abweichung erkennen könnte. Zweitens fachliche Invarianten außerhalb des Codes: In Systemen mit ökonomischen, protokollarischen oder regulatorischen Zusicherungen liegt die eigentliche Schutz-Eigenschaft in der Spezifikation, nicht in den Zeilen. Ein syntaktisch sauberer Smart Contract kann trotzdem eine Konsens-Annahme verletzen.
Drittens institutionelles Wissen: Code trägt nicht in sich, dass eine bestimmte Funktion vor drei Refaktorierungen eine Vorbedingung verloren hat, die ihre Sicherheitsgarantie trug. Interessant ist, was diese drei Klassen verbindet: In allen dreien liegt die relevante Information nicht im Code. Agentische Setups mit Zugriff auf Spezifikation, Threat-Modell und Commit-Historie schließen die Lücke schrittweise. Ohne diese Kontext-Anbindung tun sich Modelle weiter schwer, und klassische statische Analyse mit präziser Taint-Verfolgung bleibt ergänzend wichtig, weil sie genau dort scharf ist, wo KI unscharf bleibt.
|
| |
|
|
| |
|
| |
|
|
|
|
| | | | Im Heft geschmökert: Empfehlungen der iX-Redaktion | |
| |
|
| |
| | | | Auch auf der Suche nach einem kleinen NAS für Ihre Firma? KI befragt, im Web recherchiert – und trotzdem nicht schlauer? Kein Wunder: Die Auswahl ist riesig. Die Marktübersicht in der aktuellen iX zeigt, worauf es ankommt. Sortiert nach Funktionsumfang, Anzahl der Einschübe und möglichen Serveraufgaben finden Sie schnell das passende NAS.
Moritz Förster, Leitender Redakteur iX
|
| |
|
|
|---|
|
| |
|
| |
|
| | | | Generative KI treibt den Energiebedarf von Rechenzentren rasant nach oben, wobei die klassische Von-Neumann-Chiparchitektur eine Rolle spielt: Der Energieverbrauch allein für den Speicherzugriff auf üblicherweise Milliarden an Gewichten ist enorm. Die Forschung nimmt deshalb alternative Chiparchitekturen in den Blick. Neuromorphe Chips haben das menschliche Gehirn als Vorbild und arbeiten asynchron statt taktgetrieben. Sie codieren Information in Spikes, sodass nur beim Überschreiten eines Schwellenwerts Rechenaufwand entsteht. Prof. Dr. Holger Boche, Prof. Dr. Gitta Kutyniok und Pit Hoffmann geben eine Übersicht über die aktuelle Projektlandschaft.
Kornelius Kindermann, Redakteur iX
|
| |
|
|
|---|
|
| |
|
| |
|
|
|
|
| | | | Workshop-Tipp: Incident Leadership – Kommunizieren und Entscheiden im Krisenfall | |
| |
| |
Nach einem Sicherheitsvorfall zählt jede Minute. Was als technisches Problem beginnt, wird schnell zum menschlichen und organisatorischen Ausnahmezustand. Wer in solchen Momenten unklar kommuniziert oder Entscheidungen hinauszögert, verliert nicht nur Zeit, sondern die Kontrolle über die Lage. Eine klare Führungshaltung ist daher entscheidend.
Unser Workshop vermittelt, welche Herausforderungen in Krisensituationen auf IT-Teams zukommen und wie Führungskräfte sie sicher bewältigen können. Denn gerade dann müssen Führung, Kommunikation und Zusammenarbeit zuverlässig funktionieren. Und im Ernstfall zählt nicht das theoretische Wissen, sondern was sich in der Praxis wirklich abrufen lässt.
Genau hier setzt der Workshop an: Die Teilnehmer erfahren, wie sie Stress und Unsicherheit im Team erkennen. In realitätsnahen Simulationen erleben sie, wie Führungskräfte gezielt gegensteuern können. Dazu trainieren sie, wie sie in dynamischen Situationen Aufgaben priorisieren, eindeutige Rollen verteilen und trotz unübersichtlicher Informationslage wichtige Entscheidungen sicher treffen und klar kommunizieren.
Nach dem Workshop verfügen die Teilnehmer über praktische Erfahrungen, wie sie ihre IT-Teams zielsicher steuern, um im Ernstfall handlungsfähig zu bleiben und gemeinsam auf eine Rückkehr zum Normalbetrieb hinzuarbeiten.
|
| |
| |
|
|
| |
|
| |
|
|
| | | | Weitere Themen in der iX 8/2026 | |
| |
| |
Außerdem befassen wir uns in der neuen iX mit GPU-Scheduling unter Kubernetes, zeigen, wie man Fakten aus Wikidata in eigenen Apps nutzen kann, und stellen das Firmenportal Apple Business auf den Prüfstand. Alle Themen finden Sie im Inhaltsverzeichnis der iX 8/2026.
Haben Sie Anregungen zum Newsletter oder zum Heft allgemein? Schreiben Sie mir unter axk@ix.de! Ich wünsche Ihnen einen August, in dem Sie nur echte Fundstücke auf dem Tisch haben, Ihr
|
|
| |
|
| |
| | Neugierig geworden? Sie erhalten die iX 8/2026 ab dem 23. Juli im heise Shop und ab dem 24. Juli am Kiosk:
|
| |
|
| |
|
| |
| Sie sind unter folgender Adresse eingetragen: unknown@unknown.invalid - .
Hier können Sie sich von künftigen Zusendungen abmelden.
| |
| Verantwortlich für den Inhalt:
Heise Medien GmbH & Co. KG
Karl-Wiechert-Allee 10
30625 Hannover
Telefon: +49 [0]511 5352-0
E-Mail: infoservice@heise.de
Registergericht:
Amtsgericht Hannover HRA 26709
|
| | Persönlich haftende Gesellschafterin:
Heise Medien Geschäftsführung GmbH
Registergericht:
Amtsgericht Hannover, HRB 60405
Geschäftsführer: Ansgar Heise, Beate Gerold
|
|
|---|
|
| |
| Herausgeber: Christian Heise, Ansgar Heise
Chefredakteur: Dr. Oliver Diedrich (verantwortlich)
Alle Rechte vorbehalten. Jegliche Vervielfältigung oder Weiterverbreitung in jedem Medium als Ganzes oder in Teilen bedarf der schriftlichen Zustimmung des Verlags. Copyright © 2026 Heise Medien GmbH & Co. KG
| |
|
|
