Ivanti KI-Sicherheitsleitfaden sparte Stunden, doch sein Claude-Skill erfand Details

Ivanti räumte ein, dass sein Claude-basierter Skill zur Patch-Analyse Details erfunden hatte, obwohl er einen wiederkehrenden Arbeitsablauf von Stunden auf Minuten verkürzte. Das KI-Sicherheitsleitfadensystem von Ivanti verwechselte während der Entwicklung Microsoft-Office-Editionen und interpretierte Adobes Veröffentlichungsrhythmus wiederholt falsch.

Dieses Eingeständnis ist bedeutsam, weil die Ausgabe Sicherheitsteams dabei hilft, Schwachstellen nach Microsofts monatlichem Patch Tuesday zu priorisieren. Eine plausibel wirkende Erfindung kann verzerren, welche Systeme zuerst Aufmerksamkeit erhalten, selbst wenn jede zitierte Schwachstelle tatsächlich existiert.

Ivanti reagierte mit einer menschlichen Freigabeschleuse und benannte Claudes Rolle öffentlich in einer Grafik vom Juni. CrowdStrike und Palo Alto Networks beziehen ebenfalls Menschen in folgenreiche Sicherheitsautomatisierungen ein, doch keines der beiden Unternehmen hat öffentlich beschrieben, eine vergleichbare Fabrikation entdeckt zu haben.

Die Geschichte geht daher über die Fehler eines einzelnen Modells hinaus. Sie ist ein Test dafür, ob Anbieter offenlegen werden, wie KI operative Leitlinien prägt, was ihre Prüfer tatsächlich verifizieren und welche Fehler unsichtbar bleiben.

Ivanti KI-Sicherheitsleitfaden ging nach Monaten von Korrekturen in Produktion

Ivanti nahm seinen Claude-Skill erst in Produktion, nachdem seine Entwickler während des Trainings wiederholt erfundene oder vermischte Details entdeckt hatten.

Chris Goettl, Ivantis Vice President of Product Management for Endpoint Security, entwickelte den Skill rund um einen Prozess, den er etwa ein Jahrzehnt lang manuell ausgeführt hatte. Er verarbeitet veröffentlichte Herstellerhinweise und Ivantis eigene Tabellenkalkulationen und wendet anschließend die Methode des Unternehmens zur Priorisierung nach Bedrohungsrisiko an.

Ein Skill ist in diesem Kontext ein wiederverwendbares Set aus Anweisungen, Quellen und Workflow-Regeln, das einem KI-Modell bereitgestellt wird. Das bedeutet nicht, dass das Modell jedes Offenlegungssystem von Anbietern eigenständig versteht.

Goettl trainierte das System jeweils mit einem Anbieter. Microsoft kam zuerst, weil dessen herunterladbare Tabellenkalkulationen relativ strukturierte Eingaben boten. Adobe erforderte einen anderen Ansatz, da das Modell einzelne Seiten und deren wechselnde Layouts interpretieren musste.

Dieser Unterschied legte eine wichtige Schwäche offen. Der Skill lieferte wiederholt den falschen Veröffentlichungsrhythmus für Adobe. Außerdem vermischte er Microsoft-Office-Editionen, die Microsoft in mehrere Produktfamilien unterteilt.

Dabei handelte es sich nicht um stilistische Mängel. Veröffentlichungsrhythmus und Produktidentität beeinflussen, wie Analysten ungewöhnliche Aktivitäten, betroffene Software und die Dringlichkeit von Patches bewerten. Eine überzeugend formulierte Zusammenfassung mit dem falschen Muster kann ein Team dennoch in die falsche Richtung lenken.

Goettl beschrieb, wie er das System zur Rede stellte, als eine Antwort offensichtlich unbelegt erschien. Seinem Bericht in der KI-gestützten Pipeline zufolge räumte Claude ein, dass das erfundene Material keine zitierfähige Grundlage habe.

Ivanti zufolge verwendet der Skill ausschließlich öffentliche Herstellerhinweise und vom Unternehmen kontrollierte Tabellenkalkulationen. Er verarbeitet keine Kundendaten, und jede generierte Ausgabe bleibt ein Entwurf, bis eine Person sie freigibt.

Der Senior Product Manager Todd Schell ließ das System gegen zwei Monate von Briefings laufen, die zuvor manuell erstellt worden waren. Ivanti berichtete von einer Übereinstimmung von 98 Prozent und erkannte zugleich verbleibende Sonderfälle an.

Diese Zahl muss sorgfältig interpretiert werden. VentureBeat prüfte die Quelldaten, die Bewertungsmethode, die Fehlerklassifizierung oder die Wiederholungsergebnisse nicht unabhängig. Übereinstimmung belegt zudem nicht, dass jede relevante Schwachstelle in der generierten Ausgabe erschien.

Der erste Produktionslauf erfolgte im August 2026, während Goettl im Urlaub war. Eine Tabellenkalkulation, für die zuvor jeweils zwei Mitarbeiter rund vier Stunden benötigt hatten, lief Berichten zufolge in weniger als 30 Minuten durch.

Der umfassendere monatliche Workflow hatte rund um jeden Patch Tuesday etwa 48 gemeinsame Arbeitsstunden beansprucht. Ivanti schätzte, dass dieser Aufwand mindestens 5 Prozent der gemeinsamen Arbeitszeit von Goettl und Schell ausmachte.

Der operative Gewinn ist leicht nachzuvollziehen. Eine Maschine kann ein großes Release schneller erfassen, normalisieren und sortieren, als zwei Spezialisten Felder manuell über Tabellenkalkulationen hinweg kopieren können.

Ivanti entfernte den Spezialisten jedoch nicht aus dem Prozess. Das Unternehmen verlagerte dessen Aufgabe von der Zusammenstellung jeder einzelnen Zeile auf die Prüfung eines maschinell erzeugten Entwurfs.

Diese Unterscheidung definiert den zentralen Konflikt. Automatisierung spart Zeit, indem sie manuelle Erstellung reduziert, während verlässliche Sicherheitsleitlinien weiterhin auf menschlichem Urteilsvermögen und Überprüfung auf Quellenebene beruhen.

Ivanti hinterließ auch eine sichtbare Offenlegung, bevor die umfassendere Geschichte bekannt wurde. Der Beitrag zum Patch Tuesday im Juni kennzeichnete eine Grafik als mit Claude erzeugt, unter Verwendung von vom Autor entwickelten Prompts und Goettls Datensatz.

Keine Regulierung verlangte diese Bildunterschrift. Kein allgemeiner Industriestandard schrieb ihre Formulierung vor. Die Offenlegung blieb etwa drei Monate lang öffentlich verfügbar, bevor sie breitere Aufmerksamkeit erhielt.

Diese zurückhaltende Bildunterschrift wurde bedeutsam, als die Entwicklungsfehler bekannt waren. Sie verband ein KI-generiertes Artefakt mit einem benannten Modell, einem menschlichen Autor, einem Datum und einem klar definierten Datensatz.

Das ist transparenter als ein allgemeines Label wie „KI-unterstützt“. Dennoch legt es nicht offen, welche Zeilen geprüft wurden, wie Vollständigkeit gemessen wurde oder ob die veröffentlichten Risikostufen unabhängig validiert wurden.

Das Patch-Tuesday-Datenproblem machte Automatisierung attraktiv

Der unmittelbare Druck entstand durch einen Patch-Tuesday-Prozess, der größer, weniger standardisiert und stärker von der Interpretation jedes Anbieters abhängig wurde.

Am 8. September 2026 veröffentlichte Microsoft das, was mehrere Sicherheitsforscher als seinen bislang größten Patch Tuesday bezeichneten. Dennoch unterschieden sich die veröffentlichten Gesamtzahlen bei Organisationen, die dasselbe Release analysierten, erheblich.

Tenable zählte 964 Schwachstellen, darunter 104 als kritisch und 860 als wichtig eingestufte. Seine September-Analyse identifizierte außerdem zwei Schwachstellen, die bereits in freier Wildbahn ausgenutzt wurden, bevor Patches verfügbar waren.

Ivanti zählte 973. Senserva zählte 1.169, weil das Unternehmen Schwachstellen anhand von Knowledge-Base-Artikeln zuordnete, statt dieselbe auf Hinweisen basierende Methode wie andere Tracker zu verwenden.

Die Differenz zwischen den Gesamtzahlen von Tenable und Senserva betrug 205 Schwachstellen. Diese Lücke übertraf den von Ivanti genannten bisherigen Patch-Tuesday-Rekord von 175 Schwachstellen im Oktober 2025.

Diese Unterschiede belegen nicht, dass ein KI-Modell einen Fehler gemacht hat. Sie können aus legitimen Entscheidungen über Umfang, doppelte Einträge, Produktvarianten, Grenzen von Hinweisen und Zuordnungen in Wissensdatenbanken resultieren.

Sie zeigen jedoch, warum eine einzelne monatliche Gesamtzahl nicht als neutraler Fakt behandelt werden kann. Jede veröffentlichte Zahl spiegelt inzwischen eine Parsing-Methode und eine Definition dessen wider, was zur Menge gehört.

Microsoft verschärfte dieses Problem, als das Unternehmen aufhörte, eine konsolidierte monatliche CVE-Liste in seinem Security Update Guide bereitzustellen. Rapid7 dokumentierte die Änderung bei der Vorbereitung seiner Patch-Überprüfung im Juli.

Jeder Sicherheitsanbieter muss das Release nun anhand von Microsofts verfügbaren Daten rekonstruieren. Diese Rekonstruktion kann deterministischen Code, manuelle Analyse, ein KI-Modell oder eine Kombination aus allen drei umfassen.

Ein deterministischer Parser folgt expliziten Regeln und erzeugt bei identischen Eingaben dasselbe Ergebnis. Ein Large Language Model kann inkonsistente Seiten flexibler interpretieren, kann aber auch unbelegte Zusammenhänge erzeugen.

Dieser Zielkonflikt wird besonders wichtig, wenn die Ausgabe nicht lediglich eine Anzahl ist. Sicherheitsteams benötigen Priorisierungen auf Grundlage aktiver Ausnutzung, öffentlicher Offenlegung, Schweregrad, Angriffsfläche der Assets und geschäftlicher Bedeutung.

Eine falsche Anzahl kann die Berichterstattung verwirren. Eine falsche Priorität kann knappe Patch-Kapazitäten von einer Bedrohung weglenken, die Angreifer bereits ausnutzen.

Das Webinar-Briefing von Ivanti erreicht Berichten zufolge jeden Monat zwischen 500 und 700 Teilnehmer. Diese Teilnehmer übernehmen nicht zwangsläufig jede Empfehlung direkt in die Produktion, doch das Publikum verleiht jeder Priorisierungsentscheidung eine erhebliche Reichweite.

Auch der Zeitdruck ist real. Sicherheitsteams können nicht in Ruhe fast eintausend Einträge prüfen, bevor Angreifer aktiv werden.

CrowdStrike berichtete, dass 88 Prozent der beobachteten Ausnutzungsvorgänge mit einem öffentlichen Proof of Concept innerhalb von 48 Stunden begannen. Ein Proof of Concept ist öffentlich verfügbarer Code oder technische Dokumentation, die demonstriert, wie eine Schwachstelle ausgenutzt werden kann.

Bundesweite Anforderungen können noch strenger sein. Die Binding Operational Directive 26-04 von CISA legte für Schwachstellen mit dem höchsten Risiko bei zivilen Bundesbehörden ein Behebungsfenster von drei Tagen fest.

Unter diesen Bedingungen haben Anbieter einen starken Anreiz, Erfassung und vorläufige Klassifizierung zu automatisieren. Auf eine perfekte manuelle Prüfung zu warten, kann selbst ein Risiko schaffen.

Die Frage ist nicht, ob Organisationen KI einsetzen sollten. Sie lautet, ob sie nachweisen können, dass die Beschleunigung keine kritischen Schwachstellen ausgelassen, Produktzuordnungen verfälscht oder schwache Signale hochgestuft hat.

Ivantis Erfahrung zeigt, warum dieser Nachweis nicht aus sprachlicher Flüssigkeit abgeleitet werden kann. Die fehlerhafte Ausgabe des Modells wirkte überzeugend genug, um fachkundige Erkennung und direkte Konfrontation zu erfordern.

Sicherheitskäufer stehen daher unter Druck von beiden Seiten. Sie benötigen schnellere Leitlinien, können jedoch nicht davon ausgehen, dass ein schnelleres, gut geschriebenes Briefing eine vollständige oder korrekt priorisierte Menge enthält.

Die eigentliche Kehrtwende ist die Offenlegung, nicht die Fabrikation

Der überraschende Teil ist nicht, dass Claude Details erfand; sondern dass Ivanti die Fehler beschrieb und eine sichtbare menschliche Kontrollinstanz beibehielt.

Large Language Models erzeugen Text, indem sie wahrscheinliche Sequenzen aus ihrem Training und dem bereitgestellten Kontext vorhersagen. Sie garantieren nicht automatisch, dass jede Aussage einer bereitgestellten Quelle zugeordnet werden kann.

Fabrikation, oft als Halluzination bezeichnet, tritt auf, wenn ein Modell unbelegte Informationen so präsentiert, als seien sie fundiert. In diesem Workflow zeigte sich der Fehler als falsche Anbietermuster und vermischte Softwarefamilien.

Diese Schwächen sind aus allgemeinen KI-Systemen bereits bekannt. Die Tragweite verändert sich durch ihre Einbettung in eine Pipeline, die Sicherheitsempfehlungen erstellt.

Ein Fehler eines Consumer-Chatbots kann die Zeit eines Lesers verschwenden. Eine fehlende Schwachstellenzeile in operativen Leitlinien kann die Behebung auf einem exponierten System verzögern.

Ivantis Offenlegung beseitigte dieses Risiko nicht. Sie machte das Risiko überprüfbar.

Das Unternehmen fügte mindestens einer veröffentlichten Grafik einen Modellnamen und menschliche Verantwortlichkeit hinzu. Goettl erläuterte außerdem, welche Probleme während des Trainings auftraten und warum die Prüfschleuse weiterhin notwendig blieb.

Dieser Grad an Spezifität hilft Kunden, bessere Fragen zu stellen. Sie können zwischen modellgestützter Erfassung und autonomer Priorisierung unterscheiden und fragen, welche Phase menschlich verifiziert wird.

Das Eingeständnis erschwert auch herkömmliche Vertrauensbotschaften. Anbieter betonen bei der Ankündigung von KI-Funktionen üblicherweise Genauigkeitsgewinne, Verarbeitungsgeschwindigkeit oder Analystenproduktivität.

Entwicklungsfehler erhalten selten die gleiche Aufmerksamkeit. Dieses Ungleichgewicht verleitet Käufer dazu, einen Workflow anhand seines besten Benchmarks statt seiner bekannten Fehlermodi zu bewerten.

Ivantis berichtete Übereinstimmung von 98 Prozent verdeutlicht die Gefahr. Die Zahl klingt beruhigend, doch ihre praktische Bedeutung hängt davon ab, was in die verbleibende Differenz fiel.

Eine unwichtige Formatabweichung und eine ausgelassene, aktiv ausgenutzte Schwachstelle sollten nicht gleich gewichtet werden. Eine nützliche Bewertung muss Fehler nach ihrer operativen Konsequenz klassifizieren.

Vollständigkeit verdient eine gesonderte Betrachtung gegenüber Korrektheit. Ein Prüfer kann einen falschen Schweregrad oder eine fehlerhafte Beschreibung in einer sichtbaren Zeile erkennen, aber eine fehlende Zeile nicht ohne Weiteres bemerken.

Das ist die schärfste Herausforderung für die Argumentation zugunsten menschlicher Prüfung. Das Lesen generierter Ergebnisse ist nicht dasselbe wie deren Abgleich mit einem maßgeblichen Quelleninventar.

Kayne McGladrey, unabhängiger virtueller Chief Information Security Officer und leitendes IEEE-Mitglied, argumentierte, dass Kunden eine schriftliche Darstellung der Pipeline benötigen. Anbieter sollten seiner Ansicht nach erklären, wo das Modell arbeitet, wie CVEs geparst werden, wer die Ergebnisse prüft und welcher Anteil einer Quellenverifizierung unterzogen wird.

Seine Kritik ging über die Forderung nach einer menschlichen Unterschrift hinaus. Ein erneuter Durchlauf mit früheren, von Menschen erstellten Monatsausgaben kann Ähnlichkeiten messen, ohne die Korrektheit des aktuellen Monats zu belegen.

Ein menschlicher Prüfer kann zudem denselben blinden Fleck wie das Modell haben. Wenn beide sich auf sichtbare Einträge konzentrieren, entdeckt keiner einen Punkt, der bereits vor Beginn der Prüfung verschwunden ist.

Der maßgebliche Standard ist daher Rückverfolgbarkeit. Jede veröffentlichte Empfehlung sollte mit einer maßgeblichen Eingabe verknüpft sein, während für jede maßgebliche Eingabe ein dokumentierter Verbleib vorliegen sollte.

Diese zweite Richtung ist besonders wichtig. Sie verwandelt die Prüfung von „Wirkt dieser Entwurf plausibel?“ in „Kann jeder Quelleneintrag nachvollziehbar berücksichtigt werden?“

Hier wird diszipliniertes Knowledge Blending auch über das Patchen hinaus relevant. Das Zusammenführen von Quellen ist nur dann nützlich, wenn der Workflow die Herkunft bewahrt und Konflikte sichtbar macht, statt sie zu glätten.

Ivantis Offenlegung bietet einen Ausgangspunkt, aber keinen abgeschlossenen Standard. Sie informiert Käufer darüber, dass KI beteiligt war und dass bekannte Halluzinationen den Prüfprozess geprägt haben.

Sie belegt öffentlich jedoch weder eine zeilenweise Nachverfolgung, unabhängige Tests der Risikostufen, Falschnegativraten noch den Anteil des automatisch abgeglichenen Quellenmaterials.

Dennoch setzt das Eingeständnis Wettbewerber unter Druck. Ein Anbieter, der KI-gestützte Sicherheitsempfehlungen vermarktet, ohne seine Validierungskette zu beschreiben, liefert Kunden nun weniger Informationen als Ivanti.

Die Umkehrung ist unbequem, aber konstruktiv. Das öffentliche Eingestehen von Modellfehlern kann ein Zeichen für Prozessreife werden, während Schweigen sowohl hervorragende Kontrollen als auch völliges Fehlen von Kontrollen verbergen kann.

Menschliche Prüfung funktioniert nur, wenn sie fehlende Belege finden kann

Ein Prüfer schafft nur dann Mehrwert, wenn das Prüfdesign auf Auslassungen, unbelegte Behauptungen und schwerwiegende Klassifizierungsfehler abzielt.

Ivantis Workflow lässt eine Person zwischen Claudes Entwurf und dem veröffentlichten Briefing stehen. Das ist sicherer, als ein Modell die Priorisierung automatisch veröffentlichen zu lassen.

„Human in the loop“ ist jedoch eine Designbeschreibung, keine Qualitätsmessung. Seine Wirksamkeit hängt davon ab, was die Person sieht, prüft und stoppen kann.

Ein Prüfer, der Texte überfliegt, kann seltsame Formulierungen, ein bekanntes Produkt in der falschen Kategorie oder ein unplausibles Veröffentlichungsmuster erkennen. Goettls Fachwissen scheint diese sichtbaren Anomalien während des Trainings aufgedeckt zu haben.

Der schwierigere Fehler ist der stille Ausschluss. Wenn ein Parser oder Modell niemals eine Zeile für eine Schwachstelle erstellt, erhält ein Prüfer, der nur die endgültige Tabelle untersucht, keinen offensichtlichen Warnhinweis.

Ein robusteres System benötigt Abgleichkontrollen außerhalb des Sprachmodells. Deterministische Prüfungen können Quellkennungen vergleichen, nicht zugeordnete Datensätze markieren, doppelte CVEs erkennen und erwartete Einträge je Anbieter zählen.

Das Modell kann dann Aufgaben übernehmen, die von Interpretation profitieren. Es könnte Hinweise zusammenfassen, inkonsistente Beschreibungen vereinheitlichen oder Risikokategorien zur Freigabe durch Experten vorschlagen.

Diese Aufteilung weist Maschinen unterschiedliche Verantwortlichkeiten zu. Code schützt Vollständigkeit und Wiederholbarkeit, während das Modell bei mehrdeutiger Sprache und Priorisierungskontext unterstützt.

Sie schafft außerdem deutlichere Fehlersignale. Eine Abgleichabweichung kann die Veröffentlichung stoppen, selbst wenn die generierte Darstellung ausgefeilt wirkt.

Die Validierung von Risikostufen braucht ähnliche Strenge. Das System sollte festhalten, warum ein Eintrag seine Einstufung erhielt, welche Quellenfakten diese Entscheidung stützten und was sich nach der menschlichen Prüfung änderte.

Ohne diese Dokumentation schafft eine abschließende Freigabe zwar Verantwortlichkeit, liefert aber nur begrenzte Qualitätsnachweise. Sie kann nicht zeigen, ob der Prüfer jede Empfehlung untersucht oder lediglich die Zeilen mit dem höchsten Risiko stichprobenartig geprüft hat.

Ivanti zufolge lösen Signale zu bekannten Exploits, öffentlichen Offenlegungen und ungewöhnlichem Volumen eine Eskalation aus. Das ist ein sinnvolles Regelwerk, doch die öffentliche Berichterstattung verifiziert seine Anwendung nicht unabhängig.

Auch die Fehler bei Adobe und Office zeigen, warum anbieterspezifische Tests wichtig sind. Ein Workflow, der bei Microsoft-Tabellen gut funktioniert, kann scheitern, wenn ein anderer Herausgeber Webseiten, andere Namenskonventionen oder unregelmäßige Veröffentlichungsrhythmen verwendet.

Die Bewertung muss daher jede Datenquelle und jede Transformationsstufe abdecken. Ein gewichteter Durchschnitt kann einen schwachen Anbieter-Connector unter einer starken Microsoft-Leistung verbergen.

CrowdStrike beschrieb auf der Fal.Con 2026 ein anderes Prüfmuster. Beim Ansatz „human on the loop“ bearbeitet Berichten zufolge ein Analyst dieselbe Erkennung parallel zum Agenten und anschließend werden die Bewertungen verglichen.

Parallele Arbeit kann Meinungsverschiedenheiten aufdecken, die eine sequenzielle Prüfung übersieht. Sie bewahrt zudem mehr menschlichen Aufwand als ein Workflow, bei dem eine Person einen bereits fertiggestellten Entwurf prüft.

Palo Alto Networks stellte im Februar 2026 Cortex XSIAM AgentiX mit vorgefertigten Agenten und Freigabeschranken für Maßnahmen mit hoher Auswirkung vor. Sein agentic SOC design bewahrt ebenfalls menschliche Kontrolle, wenn automatisierte Entscheidungen weitreichendere Folgen haben.

Keines der beiden Designs löst automatisch das Problem fehlender Eingaben. Ein Mensch und ein Agent können beide auf Grundlage eines unvollständigen Feeds urteilen, während eine Freigabeschranke eine Aktion auf Basis fehlerhafter Belege autorisieren kann.

Der Vergleich zeigt dennoch einen sich abzeichnenden Konsens. Große Anbieter behandeln uneingeschränkte Autonomie nicht als akzeptablen Standard für sicherheitsrelevante Vorgänge mit hoher Auswirkung.

Dieser Konsens ist wichtig, weil Branchensprache Unterstützung und Autonomie oft verwischt. Ein System, das ein Briefing entwirft, unterscheidet sich wesentlich von einem System, das einen Patch bereitstellt, ein Gerät isoliert oder einen Vorfall schließt.

Käufer sollten jede KI-Aktion ihrer Umkehrbarkeit und ihrem potenziellen Schaden zuordnen. Zusammenfassungen mit geringer Auswirkung können leichtere Kontrollen tolerieren als Entscheidungen, die Produktionssysteme verändern.

Sie sollten außerdem Belege aus tatsächlichen Fehlerfällen verlangen. Ein Benchmark, der nur Übereinstimmung ausweist, verschleiert, ob Fehler Formulierungen, Umfang, Schweregrad oder Auslassungen betrafen.

Ivantis bekannte Funde von Halluzinationen liefern nützlichere Informationen als eine bloße Genauigkeitsbehauptung. Sie benennen konkrete Bedingungen, unter denen das System unzuverlässig wurde.

Die offene Frage lautet, ob die Produktionskontrollen neue Fehlermodi erkennen und nicht nur jene, die während des Trainings entdeckt wurden. Anbieter-Websites ändern sich, Taxonomien entwickeln sich weiter und ungewöhnliche Veröffentlichungen können die Parsing-Annahmen von gestern entkräften.

Menschliche Prüfung bleibt notwendig, sollte aber in ein messbares Kontrollsystem eingebettet sein. Andernfalls kann die Formulierung zur Beruhigung dienen, ohne zu belegen, dass die gefährlichsten Fehler auffindbar sind.

Ivantis Eingeständnis erhöht den Standard für jeden Sicherheitsanbieter

Sicherheitsanbieter stehen nun unter Druck, nicht nur offenzulegen, dass sie KI einsetzen, sondern genau zu erklären, wie KI kundenrelevante Prioritäten beeinflusst.

Ivanti ist nicht allein bei der Automatisierung von Sicherheitsanalysen. CrowdStrike, Palo Alto Networks und andere Anbieter integrieren Modelle und Agenten in Workflows für Erkennung, Untersuchung, Triage und Reaktion.

Der hier offengelegte Wettbewerbsunterschied ist Transparenz. Ivanti nannte sein Modell, beschrieb seine Eingaben, identifizierte bekannte Muster von Halluzinationen und erklärte, dass eine Veröffentlichung menschliche Freigabe erfordert.

VentureBeat berichtete, keine vergleichbare öffentliche Offenlegung von Halluzinationen durch CrowdStrike oder Palo Alto Networks gefunden zu haben. Dieses Fehlen belegt weder, dass ihre Systeme versagt haben, noch dass ihre Kontrollen schwächer sind.

Es bedeutet, dass Kunden keine vergleichbaren Informationen haben. Ein Anbieter hat einen Teil seiner Fehlerhistorie offengelegt, während andere vor allem Architektur und Schutzmaßnahmen beschreiben.

Öffentliche Offenlegung schafft ein schwieriges Anreizproblem. Ein Unternehmen, das Fehler meldet, kann weniger zuverlässig erscheinen als ein Wettbewerber, der nur erfolgreiche Bewertungen veröffentlicht.

Die Sicherheitsbeschaffung kann diesen Anreiz umkehren, indem sie Belege belohnt. Käufer können jedem Anbieter dieselben Fragen stellen und fehlende Antworten als ungelöste Kontrolllücke behandeln.

Erstens sollten Kunden fragen, welche Artefakte KI-generiert sind. Die Antwort sollte zwischen Sammlung, Parsing, Zusammenfassung, Bewertung, Empfehlung und automatisierter Aktion unterscheiden.

Zweitens sollten sie fragen, wie Vollständigkeit überprüft wird. Eine gültige Antwort sollte fehlende Zeilen, doppelte Datensätze, Quellenänderungen und fehlgeschlagene Aufnahmeprozesse behandeln.

Drittens sollten sie fragen, wer das Ergebnis prüft und was diese Prüfung umfasst. Eine benannte Freigaberolle ist nützlich, doch eine dokumentierte Checkliste und ein Audit-Trail bieten stärkere Absicherung.

Viertens sollten sie Fehlerkategorien statt einer einzigen Genauigkeitsquote verlangen. Käufer müssen wissen, ob Fehler Grammatik, Produktzuordnung, Exploit-Status, Schweregrad oder Aufnahme betreffen.

Diese Anforderungen stehen im angemessenen Verhältnis zur Tragweite der Entscheidung. Patch-Teams nutzen Priorisierung, weil sie nicht jedes Problem gleichzeitig beheben können.

Die September-Veröffentlichung verdeutlicht das Größenproblem. Tenable identifizierte 964 CVEs, Ivanti 973 und Senserva 1.169 nach einem anderen Zählansatz.

Ein Käufer muss nicht zwingend von jedem Anbieter erwarten, exakt dieselbe Zahl zu erhalten. Er muss jedoch verlangen, dass jeder Anbieter seinen Umfang erklärt und seine Empfehlungen mit diesem Umfang abgleicht.

Dieselbe Logik gilt für Risikostufen. Anbieter können Exploitierbarkeit, Exposition und Geschäftskontext vernünftigerweise unterschiedlich gewichten, doch diese Beurteilungen sollten rückverfolgbar bleiben.

Transparenz schützt Anbieter auch vor unfairen Vergleichen. Eine dokumentierte Methodik kann zeigen, dass zwei Gesamtzahlen wegen eines definierten Umfangs abweichen und nicht, weil ein System stillschweigend Daten verloren hat.

Dieses Thema reicht über die Cybersicherheit hinaus. Jede KI-generierte Recherche, Compliance-Zusammenfassung, Finanzübersicht oder Betriebsdokumentation kann plausible Auslassungen enthalten, die eine oberflächliche Prüfung übersieht.

In der Sicherheit wird das Problem besonders sichtbar, weil CVEs Kennungen und maßgebliche Hinweise haben. Diese Struktur bietet Anbietern eine praktische Möglichkeit, Vollständigkeit zu testen.

Organisationen, die mit weniger strukturierten Belegen arbeiten, stehen vor einer schwierigeren Aufgabe. Sie benötigen dennoch Herkunftsnachweise, Konflikterkennung und eine explizite Behandlung fehlenden Materials.

Ivantis Ansatz ist daher bemerkenswert, aber nicht ausreichend. Seine Offenlegung sagt Kunden mehr, als Schweigen es würde, während die berichteten Kontrollen weiterhin wichtige Fragen zur Verifizierung offenlassen.

Der frühere Sicherheitskontext des Unternehmens macht die Prüfung besonders wichtig. Kunden, die Patch-Empfehlungen bewerten, werden nicht nur die Effizienz des Modells beurteilen, sondern auch Ivantis Fähigkeit, Risiken präzise zu kommunizieren.

Diese Prüfung sollte evidenzbasiert bleiben. Der hier besprochene Claude Skill analysierte öffentliche Patch-Daten und griff Berichten zufolge nicht auf Kundenumgebungen zu.

Er war kein autonomer Agent zur Behebung von Problemen. Er erstellte Entwürfe für ein wiederkehrendes Briefing, wobei eine Person für die Veröffentlichung verantwortlich war.

Diese Kategorien gleichzusetzen, würde das Ereignis überzeichnen. Die Halluzination zu verharmlosen, weil „ein Mensch sie geprüft hat“, würde die Kontrollherausforderung unterschätzen.

Die abgewogene Schlussfolgerung liegt zwischen diesen Extremen. Ivanti schuf einen wesentlich schnelleren Prozess, erkannte reale Modellfehler, legte die KI-Beteiligung offen und behielt die fachliche Prüfung bei.

Es hat öffentlich nicht nachgewiesen, dass sein Prozess jede fehlende Schwachstelle erkennt oder jede Prioritätsentscheidung unabhängig validiert. Das ist der Standard, den Kunden nun von Ivanti und seinen Wettbewerbern verlangen sollten.

Drei Signale werden zeigen, ob KI-gestützte Patch-Empfehlungen Vertrauen verdienen

Der nächste Test besteht darin, ob Anbieter breite menschliche Aufsicht in sichtbare, wiederholbare und quellenvollständige Validierung überführen.

Das erste Signal wird mit dem nächsten Patch Tuesday am 13. Oktober 2026 eintreffen. Analysten sollten veröffentlichte Gesamtzahlen, Umfangsdefinitionen, Kennzeichnungen bekannter Exploits und den Umgang mit ungewöhnlichen Anbieterdaten vergleichen.

Wenn Ivantis Ausgabe schnell bleibt und zugleich Quellenabweichungen klar berücksichtigt, stärkt das den Fall für beaufsichtigte Automatisierung. Eine unerklärte Auslassung oder ein Zuordnungsfehler würde ihn schwächen.

Das zweite Signal sind detailliertere Offenlegungen von Ivanti oder seinen Wettbewerbern. Nützliche Dokumentation würde darlegen, wo Modelle eingesetzt werden, welche deterministischen Kontrollen die Vollständigkeit schützen und welche Entscheidungen menschliche Genehmigung erfordern.

Diese Informationen würden das Argument stärken, dass Transparenz zu einem Wettbewerbsstandard werden kann. Die fortgesetzte Abhängigkeit von allgemeiner „Human-in-the-Loop“-Sprache würde die zentrale Verifikationslücke ungelöst lassen.

Das dritte Signal sind Erkenntnisse aus Produktionsbewertungen. Anbieter sollten Fehlerkategorien, Quellenabdeckung, Übersteuerungen durch Prüfer und schwerwiegende falsch-negative Ergebnisse berichten, ohne ausnutzbare Kundendetails offenzulegen.

Solche Belege würden zeigen, ob sich die Systeme verbessern, nachdem sie auf neue Formate und Randfälle gestoßen sind. Aggregierte Übereinstimmung allein würde diese Frage nicht beantworten.

Der Bericht von CrowdStrike über schnelle Ausnutzung erklärt, warum diese Arbeit nicht vollständig zur manuellen Verarbeitung zurückkehren kann. Seine Erkenntnisse zur Ausnutzung zeigen, dass Verteidiger häufig innerhalb eines schrumpfenden Reaktionsfensters arbeiten.

Das richtige Ergebnis ist daher nicht weniger Automatisierung. Es ist Automatisierung, deren Belege geprüft werden können, bevor ihre Empfehlungen Menschen oder Maschinen beeinflussen.

Für Sicherheitsverantwortliche besteht die praktische Reaktion darin, jede externe Quelle für Empfehlungen zu erfassen, die KI nutzt. Fragen Sie, ob das Modell zählt, interpretiert, priorisiert oder handelt, denn jede Rolle schafft einen anderen Fehlerpfad.

Prüfen Sie dann die Überprüfungsbehauptung des Anbieters anhand einer schwierigen Frage: Wie würde der Prozess eine Schwachstelle erkennen, die nie im generierten Entwurf erschienen ist?

Wenn die Antwort davon abhängt, dass eine Person etwas Fehlendes bemerkt, ist die Kontrolle unvollständig. Wenn sie Quellenabgleich, Ausnahmebehandlung und dokumentierte menschliche Entscheidungen umfasst, ist der Workflow glaubwürdiger.

Die KI-Sicherheitsleitlinien von Ivanti liefern nun eine öffentliche Fallstudie für dieses Gespräch. Sein Claude Skill sparte erhebliche Analystenzeit, erfand während der Entwicklung Details und zwang das Unternehmen dazu, diese Fehler bei der Gestaltung zu berücksichtigen.

Die Offenlegung sollte nicht automatisch Vertrauen schaffen, verdient jedoch Aufmerksamkeit. Sie gibt Kunden konkrete Schwächen, die sie prüfen können, und bietet Wettbewerbern einen Transparenzmaßstab, den sie übertreffen können.

Bevor Sie sich auf das nächste KI-gestützte Sicherheitsbriefing verlassen, fragen Sie nach der Rolle des Modells, der Prüfung der Quellenvollständigkeit und der tatsächlichen Aufgabe des Prüfers. Diese Antworten werden mehr verraten als jeder Schlagzeilenwert zur Genauigkeit.