foto magnific

Vorstände und CIOs drängen Sicherheitsteams dazu, interne KI-Penetrationstest-Tools selbst zu entwickeln – aber lohnt sich das?

Mit jedem neuen Frontier Model Release – sei es Mythos von Anthropic oder ChatGPT 5.5 – stehen Sicherheits- und Penetrationstest-Teams unter dem zunehmenden Druck seitens von Vorständen, CEOs und CIOs, interne KI-Tools zu entwickeln. Bevor sie sich für die Eigenentwicklung entscheiden, gilt es Fragen zu klären.

Synack beleuchtet die fünf häufigsten Fragen, die sich Sicherheitsteams stellen sollten, wenn sie zwischen »selbst entwickeln« und »kaufen« bei KI-Penetrationstests entscheiden müssen.

Kann ich einfach Claude oder GPT verwenden und es auf meine Umgebung anwenden?

Ein Frontier-Modell allein ist keine Penetrationstest-Plattform. Ohne maßgeschneiderte Orchestrierung, spezialisierte Sub-Agenten und eine unabhängige Triage-Ebene kommt es zu hohen False-Positive-Raten und oberflächlichen Ergebnissen. Einige Unternehmen wenden sich daher Open-Source-Agenten-Frameworks zu, die in kontrollierten Laborumgebungen vielversprechend wirken, aber bei realen Anwendungen mit Authentifizierungsprozessen, benutzerdefinierter Geschäftslogik und nicht standardisierten APIs durchweg versagen. Eine Demo dauert ein Wochenende, aber eine Lösung so zu gestalten, dass sie gegenüber einer echten Angriffsfläche zuverlässig ist, macht die anderen 80 Prozent der Arbeit aus.

Genau hier liegt die technische Komplexität – und hier explodieren die Gesamtbetriebskosten (TCO). Synack hat Jahre damit verbracht, jedes wichtige agentenbasierte Framework zu evaluieren, bevor es sein eigenes entwickelt hat. Die Kluft zwischen einem Laborergebnis und einem Produktionsergebnis ist der Kern der technischen Komplexität. Bevor Unternehmen diesen Weg einschlagen, sollte sie sich fragen: Welche konkreten Schwachstellen hoffen die Sicherheitsverantwortlichen zu finden, und können sie den gesamten Workflow von der ersten Erkundung bis zu einem validierten Befund abbilden?

Mein Entwicklerteam ist stark. Kann es das umsetzen?

In der Regel liegt das Problem nicht in den technischen Fähigkeiten. Das eigentliche Problem ist oft die Methodik hinter der offensiven Sicherheit in Verbindung mit der langfristigen Aufrechterhaltung. Der Aufbau eines effektiven KI-Penetrationstest-Systems erfordert tiefgreifendes Wissen darüber, wie echte Angriffsketten funktionieren, und ein gewartetes System, das rund um die Uhr an 365 Tagen im Jahr läuft. Es muss dynamisch skalierbar sein, ungewöhnliche architektonische Herausforderungen autonom bewältigen und nahtlos pausieren, wenn eine Herausforderung nicht überwunden werden kann.

Gleichzeitig muss es wissen, wie sich Schwachstellen kombinieren, welche OSINT-Signale (Model Context Protocol) von Bedeutung sind und was einen echten Exploit von einem False Positive unterscheidet. Dies muss konsistent erfolgen, was angesichts der nichtdeterministischen Natur der Agenten keine geringe Herausforderung darstellt. Dieses Wissen stammt aus jahrelanger praktischer Erfahrung mit Penetrationstests und Systementwicklung, nicht allein aus KI-Fachwissen.

Behalte ich die Kontrolle über meine Daten und die von uns verwendeten Modelle?

Das ist eine berechtigte Anforderung, und es lohnt sich, genau zu definieren, was »Kontrolle« für das eigene Programm tatsächlich bedeutet. Es braucht klare Richtlinien zum Umgang mit Daten, Isolierung der Umgebungen, Sicherheitsvorkehrungen sowie festgelegte Prozesse für die Speicherung und den Zugriff auf Ergebnisse.

Weniger offensichtlich ist jedoch, dass die interne Entwicklung eine andere Art von Risiko auf das Team überträgt. Wer Eigentümer des Tools ist, ist auch für den gesamten Lebenszyklus verantwortlich. Dazu gehören die Modellauswahl, das Token-Kostenmanagement, die Stilllegung von Modellen, die schnelle Wiederherstellung nach Upgrades, Risiken wie das versehentliche Löschen von Daten sowie das Benchmarking jeder Änderung. Die Kontrolle über das Tool bedeutet auch die Verantwortung für dessen Ausfälle.

Ist die Eigenentwicklung kostengünstiger?

Die anfänglichen Entwicklungskosten sind real. Bei den Gesamtbetriebskosten kommt jedoch die Mathematik ins Spiel. Der Token-Verbrauch bei offensiver Sicherheit ist in großem Maßstab erheblich. Der Betrieb von Hunderten von Agenten über ein echtes Anwendungsportfolio hinweg ist teuer, und ohne präzise Orchestrierung eskalieren die Kosten schnell.

Die Optimierung zugunsten der Kosten geht zu Lasten der Wirksamkeit. Die Optimierung zugunsten der Wirksamkeit erhöht die Kosten. Der Praxiserfahrung nach werden Entwickler kostenbewusst und führen weniger Tests durch, was den Zweck verfehlt. Hinzu kommt, dass KI-Anbieter ältere Modelle regelmäßig auslaufen lassen. Die darauf abgestimmten Prompts und Schutzmechanismen lassen sich nicht nahtlos auf die nächste Version übertragen. Jeder Wechsel des MCP-Tools (Model Context Protocol), jede Änderung der Schutzmechanismen oder jede Modellmigration ist ein Regressionsereignis, das erneutes Testen und Anpassen in großem Maßstab erfordert.

Rechnet man noch den Personalaufwand für die Wartung des Systems hinzu, baut man kein Tool auf, sondern stellt ein Produktteam zusammen. Eine kommerzielle Lösung bietet feste, vorhersehbare Kosten, sodass Unternehmen genau wissen, wofür sie bezahlen. Ein selbst entwickeltes System in großem Maßstab lässt sich viel schwerer kalkulieren.

Kann ich eine schlanke Lösung für mein internes Red-Team entwickeln?

Interne Experimente, um das eigene Team effizienter zu machen, sind ein vernünftiger Ausgangspunkt, doch zwei Dinge sollten Unternehmen bedenken, bevor sie größere Änderungen an ihrem Sicherheitsplan vornehmen.

Erstens verlangen die meisten Compliance-Rahmenwerke, darunter PCI DSS, SOC 2, ISO 27001, FedRAMP und die meisten Sicherheitsrichtlinien in Unternehmen, eine unabhängige Bewertung durch Dritte. Ein internes Tool gilt – egal wie ausgefeilt es auch sein mag – als Selbstbewertung. Die meisten Auditoren akzeptieren dies nicht, und die meisten CISOs wünschen sich eine gewisse geteilte Verantwortung, wenn sie sagen: »Es wurde getestet.«
Zweitens bleiben schlanke interne Tools in der Regel schlank oder werden aufgegeben. Das liegt daran, dass Innovatoren in der Regel Schwierigkeiten mit der Aufrechterhaltung haben. Der Wartungsaufwand steigt, wenn sich Modelle ändern, sich die Anwendungsumgebung weiterentwickelt und das Interesse des Teams, das das Tool entwickelt hat, nachlässt. Ein Proof of Concept ist kein Programm.

Stunde der Wahrheit: Eigenentwicklung muss sich an den Compliance-Anforderungen messen

Bevor sich ein Team festlegt, lohnt es sich zu prüfen, ob eine Eigenentwicklung die Compliance-Anforderungen tatsächlich erfüllen würde oder ob das Unternehmen am Ende doch ein internes Tool warten und für Bewertungen durch Dritte bezahlen müsste. Eigenentwicklungen können von Vorteil sein, aber auch eine enorme finanzielle und ressourcenbezogene Belastung darstellen.

Synack hat Sara AI Pentest, einen autonomen Red Agent, unter Nutzung seiner bestehenden Infrastruktur entwickelt, die jährlich Zehntausende von Tests unterstützt. Jeder Test orientiert sich an der Methodik echter Produktionstests und fasst die Intuition der Forscher in einem strukturierten Workflow zusammen, der über Hunderte spezialisierter Agenten kodiert ist. Diese auf 13 Jahren basierende Wissensbasis ist nicht von der Stange erhältlich. Die Frage, die es zu stellen gilt, ist, ob das interne Team über genügend engagierte Ingenieure für offensive Sicherheit sowie KI/ML verfügt, um dies voranzutreiben.

256 Artikel zu „Penetrationstest“

News | Trends 2025 | Trends Wirtschaft | Trends Security | IT-Security

Penetrationstests senken Kosten für Cyberversicherungen

10. Dezember 2025

69 Prozent der Firmen überzeugt: Kontinuierliches Pentesting hat Einfluss auf Versicherungsprämien BaFin: Markt für betriebliche Cyberversicherungen wächst rasant, Prämien steigen stetig Sicherheitsexperte Dennis Weyel: »Angesichts der sich verschärfenden Bedrohungslage werden kontinuierliche Pentest-Nachweise bald Voraussetzung sein, um Cyberrisiken überhaupt noch versichern zu können.« Unternehmen können ihre Kosten für Cyberversicherungen deutlich senken, indem sie regelmäßige Penetrationstests…