AI Code Security · AI-SAST · Exploit-Validierung

Code-Sicherheit im KI-Zeitalter

Regelbasierte Scanner finden weiterhin zuverlässig, wofür sie gebaut wurden: Syntaxfehler. Was heute wehtut — gebrochene Autorisierung, Geschäftslogik, falsch angenommene Berechtigungen — hat keine Signatur. Wir bringen Regeln, KI-Reasoning und Exploit-Validierung in eine Ordnung, die Ihr Team tatsächlich betreiben kann.

Erstgespräch vereinbaren Leistungen ansehen

Bestandsaufnahme in zwei Wochen, belastbares Ergebnis in 90 Tagen
Werkzeugneutral: wir bewerten Ihren Stack, wir verkaufen keinen
Evidenz, die CRA-, NIS2- und Kundenaudits standhält

Vier Zahlen, die die Lage beschreiben

Alle aus öffentlich zugänglichen Primär- und Betreiberquellen. Zusammen erklären sie, warum Menge und Tempo gleichzeitig zum Problem geworden sind.

45 %

des KI-generierten Codes fällt im Sicherheitstest durch

Geprüft über mehr als 100 Modelle und 80 Coding-Aufgaben. Bei Java liegt die Durchfallquote bei 72 Prozent.

Veracode GenAI Code Security Report

A01

Broken Access Control bleibt Platz 1 der OWASP Top 10

In der Ausgabe 2025 ausdrücklich inklusive BOLA und BFLA — genau die Fehler, für die es kein Muster gibt.

OWASP Top 10:2025

23 %

der bekannt ausgenutzten Lücken werden am Publikationstag angegriffen

Anteil der KEV-Einträge mit Ausnutzung am oder vor dem Tag der CVE-Veröffentlichung, erstes Halbjahr 2026.

CISA KEV-Katalog

15–20 %

der eingehenden CVEs werden noch vollständig angereichert

Die NVD arbeitet seit April 2026 im Triage-Modus. Wer auf vollständige Datenbanken wartet, wartet vergeblich.

NIST zur NVD-Umstellung

Ein Scanner liest Syntax. Ein Angreifer liest Absicht.

Der Unterschied ist kein Werkzeugproblem, sondern ein Klassenproblem. Beide Beispiele stammen aus derselben Anwendung.

pythonERKANNT

1# Findet jede Regel-Engine seit 20052query = "SELECT * FROM users WHERE id=" + req.id3db.execute(query)4# → CWE-89 · SQL Injection · deterministisch erkennbar

Eine zusammengesetzte SQL-Abfrage hat eine stabile Form. Genau dafür sind Regeln gebaut: schnell, reproduzierbar und günstig genug für jeden Commit. Diese Schicht ersetzt niemand.

Deshalb ersetzen wir nichts. Wir legen eine zweite Ebene darüber, die über Absicht schließen kann.

Drei Schichten statt eines Werkzeugs

Jede Schicht hat eine eigene Fehlerklasse, eine eigene Kadenz und einen eigenen Preis. Wählen Sie eine Schicht, um die Einsatzregel zu sehen.

Layer 2

AI-SAST mit semantischem Reasoning

Was sie findet: Absichtsabhängige Fehler: gebrochene Autorisierung, IDOR und BOLA, Geschäftslogik, fehlende Mandantentrennung.
Wo sie läuft: Gezielt auf hochwertigen Repositories: internetseitige Dienste, Authentifizierung, alles mit personenbezogenen oder zahlungsrelevanten Daten.
Was sie kostet: Mittlere Kosten. Der Aufwand rechtfertigt sich über die Fehlerklasse, nicht über die Menge.

Schneller, günstiger, syntaktischLangsamer, teurer, tiefer

Die Frage lautet nie „welche Schicht“, sondern „welche Schicht auf welchem Repository in welcher Kadenz“. Genau diese Zuordnung erarbeiten wir mit Ihnen — hergeleitet aus Exposition und Datenklasse, nicht aus dem Bauch.

Erreichbarkeit ist eine These. Ausnutzbarkeit ist ein Beweis.

Zwischen einem markierten Codeabschnitt und einem echten Risiko liegen vier Schritte. Wer sie überspringt, priorisiert nach Gefühl.

01
Finding
Eine Regel oder ein Modell markiert eine Stelle im Code. Mehr ist es an dieser Stelle nicht.
02
Erreichbarkeit
Die markierte Stelle liegt auf einem Pfad, der von außen aufgerufen werden kann.
03
Exposition
Der Dienst ist tatsächlich erreichbar: Netzwerkweg, Identität, Konfiguration.
04
Ausnutzbarkeit
Der Angriff wurde gegen die laufende Umgebung geführt und hat gewirkt. Ab hier ist es kein Verdacht mehr.
05
Auswirkung
Was hinter dem Pfad liegt, entscheidet über die Reihenfolge der Behebung.

Was wir für Sie übernehmen

Wir bauen keine Parallelorganisation auf. Wir bringen Ihre bestehende Werkzeugkette in eine Ordnung, die trägt — und übernehmen die Teile, die Spezialwissen brauchen.

Scanning-Architektur & Werkzeugbewertung

Bevor ein weiteres Werkzeug dazukommt, klären wir, welche Schicht auf welchem Repository überhaupt Sinn ergibt.

Repositories nach Exposition und Datenklasse klassifizieren
Werkzeugneutraler Vergleich Ihres bestehenden Stacks
Kadenz- und Kostenmodell je Schicht

AI-SAST einführen und kalibrieren

Semantische Codeanalyse ist nur so gut wie ihre Abnahmekriterien. Wir definieren sie, bevor der erste Lauf startet.

Pilot auf definierten Repositories
Kalibrierung gegen bekannte, bereits behobene Befunde
Abnahmekriterien statt Herstellerkennzahlen

Exploit-Validierung & Gegenprobe

Wir prüfen am laufenden System, ob ein Befund tatsächlich zu einem Angriffspfad führt.

Nachweis am System, nicht am Diagramm
Beweiskette je bestätigtem Pfad
Übergabe mit Reproduktionsschritten an die Entwicklung

Secure Code Review für KI-generierten Code

Assistenzcode fällt in vorhersagbaren Klassen durch. Genau dort setzt das Review an.

Autorisierung, Mandantentrennung, Fehlerbehandlung
Review-Leitfaden für Ihre Code-Owner
Agenten- und Prompt-Risiken im Repository selbst

Remediation & Ownership

Der reifste Befund läuft ins Leere, wenn niemand benannt ist. Wir schließen die Lücke zwischen Fund und Fix.

Code-Owner-Mapping bis zur einzelnen Person
Korrekturvorschläge als Pull Request
SLAs nach Ausnutzbarkeit statt nach CVSS allein

Nachweisführung für CRA, NIS2 und Kundenaudits

Dieselben Artefakte tragen Audit, Kundenfragebogen und Vorfallnachweis — wenn sie von Anfang an so entstehen.

Prüf- und Testberichte für die technische Dokumentation
Sicherheitsschuld mit Fälligkeit statt Ausnahmeliste
Kennzahlen, die Wirkung zeigen statt Aktivität

Vier Phasen bis zum belastbaren Ergebnis

Kein Plattformwechsel, kein Big Bang. Der Weg funktioniert mit dem, was in den meisten Organisationen bereits vorhanden ist.

Phase 1 · 2 Wochen
Bestandsaufnahme
Wir sichten Repositories, vorhandene Scanner, Befundhistorie und Zuständigkeiten. Ergebnis ist eine Klassifizierung nach Exposition und Datenklasse — und eine ehrliche Basislinie.
Phase 2 · 4 Wochen
Pilot
AI-SAST auf den kritischsten Repositories, kalibriert gegen bekannte Befunde. Parallel die ersten Validierungen: Welche Pfade sind wirklich erreichbar?
Phase 3 · 6 Wochen
Verankerung
Gates im Build, Korrekturvorschläge an die Code-Owner, SLAs nach Ausnutzbarkeit. Ausnahmen werden dokumentiert und bekommen ein Ablaufdatum.
Phase 4 · laufend
Betrieb
Periodische Frontier-Analyse für die kritischsten Anwendungen, Kennzahlenbericht, Nachsteuerung. Auf Wunsch als Managed Service.

Was am Ende auf dem Tisch liegt

Artefakte, die weiterverwendbar sind — im Sprint, im Audit und im Kundenfragebogen.

Repository-Risikoregister

Alle Repositories nach Exposition, Datenklasse und Zuständigkeit — die Grundlage jeder Kadenzentscheidung.

Scanning-Zielbild

Welche Schicht auf welchem Repository in welcher Frequenz, inklusive Kosten- und Laufzeitabschätzung.

Validierte Befundliste

Bestätigte Angriffspfade mit Beweiskette und Reproduktionsschritten — sauber getrennt von unbestätigten Hinweisen.

Fix-Pakete

Ursachenbezogene Korrekturvorschläge, wo möglich als Pull Request an die zuständigen Code-Owner.

Prüf- und Testberichte

In einer Form, die in die technische Dokumentation nach CRA Anhang I passt.

Kennzahlenbericht

Anteil validierter Befunde, Zeit von Fund bis Fix, Zuordnungsquote und Sicherheitsschuld nach Alter.

Der Anschluss an Normen und Regulatorik

Wir arbeiten entlang etablierter Referenzen — damit Ergebnisse nicht nur intern überzeugen, sondern auch extern belegbar sind.

EU Cyber Resilience Act

Anhang I Teil II verlangt wirksame Schwachstellenbehandlung über den Unterstützungszeitraum; Test- und Prüfberichte gehören in die technische Dokumentation.

Verordnung (EU) 2024/2847