Sind Sie CISO oder Engineering-Leiter und besorgt über die Sicherheit und Kosten von LLM-generiertem Code?

Prüfen Sie den SCW AI Trust Index, unsere proprietären LLM-Benchmarking-Daten, bevor Sie sich vollständig auf ein KI-Modell festlegen

Die Cyber-Branche ist derzeit völlig überlastet. Tools wie Mythos von Anthropic (und das kurzzeitig gesperrte und dann wieder freigegebene Fable 5) zwingen viele Sicherheitsverantwortliche dazu, ihre Sicherheitsprogramme schnell zu erweitern, um mit der rasanten Entwicklung bei der Geschwindigkeit von Exploits Schritt zu halten – ganz zu schweigen von dem durch KI-Technologie massiv gestiegenen Code-Volumen.

Unter diesen Umständen ist es verlockend, sich in präventive (und, seien wir ehrlich, reaktive) Sicherheitsmaßnahmen zu stürzen, um der vermeintlichen Flut an KI-gestützten Angriffsrisiken zu begegnen. Es gibt jedoch ein weitaus tieferliegendes Problem, das heute wahrscheinlich jeden CISO betrifft: die Wahl der LLM-Modelle in Software-Produktionsumgebungen. Während die Folgen von Shadow AI allgemein gut dokumentiert sind, ist dies nur ein Teil des besorgniserregenden Risikobildes. Wir sollten nicht erst Tokens bezahlen, um Code zu generieren, dann weitere Tokens, um mit KI nach Sicherheitslücken zu suchen, und schließlich erneut Tokens, um Sicherheitsfixes zu erstellen und anzuwenden. Jedes KI-Modell neigt dazu, Schwachstellen und Sicherheitslücken in unterschiedlichem Maße zu erzeugen, insbesondere wenn man die Leistung über verschiedene Frameworks oder Programmiersprachen hinweg vergleicht. Hier muss eine fundierte Entscheidung für das richtige Modell getroffen werden, das den bestehenden Tech-Stack, die Sprachen und die verwendeten Frameworks unterstützt – eine Information, die bisher nur schwer zu beschaffen war.

Secure Code Warrior hat sich mit führenden Forschern der RMIT University zusammengetan und monatelang eine täuschend einfache Frage untersucht: Wie viel Sicherheitsrisiko übernimmt man eigentlich, wenn man seinen Code einem KI-Modell anvertraut? Die Antwort, basierend auf unserer empirischen Studie von über 1700 vollständigen Anwendungscodebasen, die von führenden Frontier- und Budget-Modellen sowie elf Sprach-Frameworks generiert wurden, lautet: mehr als Sie denken, und zwar auf eine Weise, die Sie überraschen wird.

Dies sind die fünf wichtigsten Erkenntnisse aus unserem Forschungsbericht, die Sie bei der Anpassung Ihres Sicherheitsprogramms an das KI-Zeitalter berücksichtigen sollten:

1. Kosten sind kein Indikator für Sicherheit.

Es ist verlockend anzunehmen, dass man für mehr Geld auch sichereren generierten Code erhält. Unsere Daten zeigen jedoch, dass die Realität differenzierter ist. GPT 5.1 erzielte in unserer ursprünglichen Studie den höchsten normalisierten Sicherheitswert – 79,6 von 100 – bei durchschnittlichen Kosten von 5,60 $ pro Durchlauf. Claude Sonnet 4.5 erreichte mit 71,2 einen deutlich niedrigeren Wert bei Kosten von 43,99 $ pro Durchlauf. Das sind fast die achtfachen Kosten für ein schlechteres Sicherheitsergebnis.

Die Kostenlücke entsteht nicht allein durch die Preise pro Token. Die Anthropic-Modelle führten innerhalb der agentischen Coding-Schleife deutlich mehr Tool-Aufrufe durch und generierten beispielsweise 176 Millionen Output-Tokens bei den Durchläufen von Sonnet 4.5 im Vergleich zu 42 Millionen bei GPT 5.1. Mehr Aktivität, mehr Tokens und höhere Kosten führten nicht zu mehr Sicherheit. Budget ist nicht gleich Qualität – lassen Sie es also nicht als Ersatz für eine echte Messung gelten.

2. Jedes Modell hat einen Schwachstellen-Fingerabdruck.

Über mehr als 1700 Codebasen und 16 Modelle hinweg haben wir 83 eindeutige CWE-Kategorien mit validierten True-Positive-Ergebnissen identifiziert. Diese sind nicht zufällig; jedes Modell weist ein systematisches Muster auf, das unabhängig vom Framework oder der Sprache bestehen bleibt. In unserer ursprünglichen Studie mit 6 Modellen wurden 39 der 87 identifizierten CWE-Kategorien von jedem einzelnen getesteten Modell erzeugt, was zeigt, dass ein großer Kern von Schwachstellentypen modellunabhängig und nicht anbieterspezifisch ist. Die Claude-Modelle von Anthropic zeigten beispielsweise eine wiederkehrende Tendenz zu hartcodierten Anmeldedaten (CWE-798). Gemini 2.5 Flash hinterließ konsistent Debug-Code in Produktions-Builds (CWE-489).

Diese Fingerabdrücke deuten eher auf Verzerrungen durch Trainingsdaten oder Alignment hin als auf zufälliges Rauschen. Diese Vorhersehbarkeit ist tatsächlich nützlich: Sobald Sie die blinden Flecken Ihres Modells kennen, können Sie gezielte Scan-Regeln und Prüfungen nach der Generierung konfigurieren.

3. Manche Schwachstellen sind universell … und kein getestetes Modell vermeidet sie.

Ein Beispiel: Eines der am weitesten verbreiteten Ergebnisse in unserem aktuellen Index ist CWE-532 (Einfügen sensibler Informationen in Protokolldateien), das 6.765 Mal als True Positive auftrat.

Jedes Modell arbeitete mit derselben gewöhnlichen Anwendungsspezifikation – der Art von Briefing in einfacher Sprache, die ein Produktteam täglich schreibt, nicht mit einer Sicherheits-Checkliste oder einem reduzierten Prompt, der Fehler provozieren soll. Die meisten der übrigen Schwachstellen deuten nicht auf exotische Grenzfälle hin, sondern auf Versäumnisse: Anmeldedaten im Quellcode, zu freizügige Standardeinstellungen, fehlende Autorisierungsprüfungen. Das sind Lücken, die sich sofort schließen, wenn man explizit danach fragt, da das Modell sie nicht von selbst aus einer gewöhnlichen Spezifikation ableitet. Die Ausnahme ist das größte Einzelergebnis selbst: Das Protokollieren sensibler Daten ist nichts, was die Modelle „vergessen“ haben, sondern etwas, das sie aktiv und ungefragt geschrieben haben – genau wie ein unerfahrener menschlicher Entwickler. Dies geschieht völlig freiwillig durch das Modell, ohne dass ein Mensch explizit dazu aufgefordert hat. Das Modell setzt das, was im Prompt beschrieben ist, getreu um, einschließlich allem, was aus Sicht der Sicherheitshärtung nicht erwähnt wurde.

4. Der Framework-Kontext prägt die Modellleistung.

Diese Erkenntnis sollte die Sichtweise von Unternehmen auf KI-gestützte Entwicklung verändern. Die Studie macht deutlich, dass die Stärken der Modelle je nach Technologie-Stack variieren. Ein Modell, das in einem Framework gut abschneidet, kann in einem anderen versagen. Teams sollten Modelle daher dort bewerten, wo sie tatsächlich eingesetzt werden sollen.

In unserem aktuellen SCW AI Trust Index ist die Lücke zwischen den Frameworks weitaus größer als die zwischen den Modellen. JavaScript Basic – aggregiert über alle 13 von uns getesteten Modelle – weist einen Gesamtrisikowert von 6.770 auf. C#/.NET Basic, das sicherste Framework in der Studie, liegt bei nur 111. Das ist ein 61-facher Unterschied im Sicherheitsrisiko, der allein durch die Wahl des Frameworks bedingt ist.

Unsere ursprüngliche Studie fand den wahrscheinlichen Grund dafür: Frameworks mit festen Sicherheitsstandards – z. B. C# mit den integrierten Anti-Forgery-Tokens von ASP.NET oder das deklarative Sicherheitsmodell von Java Spring – erzeugten deutlich sichereren Code, unabhängig davon, welches Modell ihn generierte. Rohe Umgebungen wie JavaScript Basic verstärken Modellunterschiede katastrophal. Wählen Sie Ihr Framework in Ihrem Unternehmen nach Möglichkeit zuerst unter Sicherheitsaspekten aus.

5. Kein Modell ist überall führend; die Modellauswahl muss daher framework-spezifisch erfolgen.

In unserer ursprünglichen Studie lag GPT 5.1 insgesamt vorn, belegte jedoch bei Swift iOS den letzten Platz. Sonnet 4.5 lieferte den sichersten Java-Spring-Code der gesamten Studie, landete aber bei der Java EE API auf dem letzten Platz. Gemini 2.5 Pro dominierte bei Python und Swift, war jedoch bei Java nur mittelmäßig. Es gibt kein universell sicheres Modell.

Unternehmen mit polyglotten Codebasen müssen entweder modellbedingte Schwachstellen in ihrem Stack akzeptieren oder eine Routing-Strategie verfolgen, die jedes Framework mit dem Modell kombiniert, das in diesem Kontext das stärkste Sicherheitsprofil aufweist. Unabhängig von der Modellwahl ist ein Sicherheitsscan unverzichtbar. Selbst das leistungsfähigste Modell erzeugte in jedem von uns getesteten Framework validierte Schwachstellen.

Der Kostendruck bleibt bestehen. Mit der Skalierung agentischer Workflows steigen auch die Ausgaben: mehr Tool-Aufrufe, mehr Regenerationszyklen, mehr Token pro Aufgabe. Es ist davon auszugehen, dass steigende Kosten pro Aufgabe und Token einige Unternehmen dazu bewegen werden, auf ältere oder günstigere Modelle umzusteigen, um die Ausgaben zu begrenzen. Unsere Daten zeigen jedoch, dass diese Entscheidung auf Fakten statt auf Vermutungen basieren muss: GPT 5 Mini war in unserer Studie sowohl das günstigste als auch das am wenigsten sichere Modell. Der Kostendruck ist real, daher sollten Sie messen, statt zu raten.

Die Frage ist nicht, ob gescannt werden soll, sondern wie Sicherheitsverantwortliche die richtigen Daten, Risikosignale und AI-Observability priorisieren, um zu wissen, wonach überhaupt gesucht werden muss. Hier spielt AI-Governance eine entscheidende Rolle, und wir bieten eine umfassende Lösung, um diese wichtigen Informationen bereitzustellen.‍

‍

>>> MEHR ERFAHREN: SCW Trust Agent: AI
>>> DOWNLOAD: eBook
>>> ENTDECKEN: Unsere Benchmarking-Microsite (vollständiges Whitepaper wird hier verlinkt)