Der eigene Code als Schwachstelle: KI-Code-Scan in der Pipeline
Eine SBOM zeigt, welche fremden Bausteine in Ihrer Software stecken und welche davon bekannte Lücken haben. Über den Code, den Ihr Team selbst schreibt, sagt sie nichts. Genau dort entstehen aber viele Schwachstellen: eine vergessene Rechteprüfung, eine SQL-Abfrage aus Benutzereingaben, ein Token im Log. Der KI-Code-Scan von Secupipe prüft diesen Code automatisch in Ihrer Pipeline.
Was der Code-Scan findet
Ein KI-Agent liest Ihr Repository so, wie es ein erfahrener Prüfer tun würde. Er beginnt dort, wo das Risiko am größten ist: Eingänge aus dem Netz, Anmeldung, Datenbankzugriffe, Dateien, Kryptografie. Typische Befunde:
- Injection: Abfragen oder Befehle, die aus Benutzereingaben zusammengesetzt werden.
- Fehlende Rechteprüfung: ein Endpunkt, der Daten herausgibt, ohne zu prüfen, wer fragt.
- Zugriff auf fremde Daten: in Mehrmandanten-Systemen eine Abfrage ohne Filter auf die eigene Firma.
- Geheimnisse am falschen Ort: fest eingetragene Schlüssel oder Tokens, die im Protokoll landen.
Zwei Durchgänge gegen Fehlalarme
Scanner, die Hunderte Treffer melden, werden nach zwei Wochen ignoriert. Deshalb arbeitet der Code-Scan in zwei Durchgängen:
- Suche: Der Agent prüft den Code und sammelt Verdachtsfälle. Bereits bekannte Befunde prüft er erneut: noch vorhanden oder behoben?
- Nachprüfung: Ein zweiter Durchgang versucht, jeden neuen Befund zu widerlegen. Was sich nicht belegen lässt, fliegt raus.
An Secupipe gehen nur Befunde ab 60 % Konfidenz. Dieselbe Stelle wird nicht doppelt gemeldet, auch wenn sich die Zeile verschiebt. Und einen Befund, den Sie als Fehlalarm bewertet haben, meldet der Agent nicht erneut.
Wo die Befunde landen
Code-Befunde erscheinen in Secupipe in derselben Liste wie die Befunde aus der SBOM: mit Schweregrad, Datei, Zeile, Funktion, Beschreibung und einer Empfehlung zur Behebung. Sie bekommen dieselbe Frist, dieselbe VEX-Bewertung, denselben Alarm in Slack oder Teams und auf Wunsch ein Jira-Ticket. In GitHub erscheinen neue Befunde zusätzlich als Hinweis direkt an der Zeile im Pull Request.
Hält der Agent einen alten Befund für behoben, ist das zunächst nur ein Vorschlag. Gültig wird er erst, wenn ein Mensch ihn freigibt.
Ihr Code bleibt bei Ihnen
- Der Scan läuft als Container auf Ihrem CI-Runner, nicht bei uns.
- Secupipe sieht keinen Quellcode. Gemeldet werden je Befund nur CWE, Datei, Zeile, Funktion, Beschreibung und Empfehlung.
- Der Agent darf nur lesen: Er ändert keine Dateien und führt keinen Code Ihres Repositorys aus.
- Der Quellcode geht an den KI-Anbieter, dessen Schlüssel Sie selbst hinterlegen: Anthropic direkt, oder über Amazon Bedrock beziehungsweise Google Vertex in einer EU-Region.
Wir haben es zuerst an uns selbst ausprobiert
Der Code-Scan läuft seit dem 10. November auf dem Code von Secupipe selbst: bei jeder Änderung auf den geänderten Dateien, montags auf dem ganzen Repository. Gleich in den ersten Läufen hat er echte Schwächen gefunden, die wir behoben haben:
- Eine Ratenbegrenzung ließ sich umgehen, weil die Adresse des Aufrufers aus einem Header gelesen wurde, den der Aufrufer selbst setzen konnte.
- Einladungs-Tokens standen als Teil der Adresse im Zugriffsprotokoll (CWE-532).
Beides sind keine Lücken, die ein Abgleich mit Schwachstellendatenbanken je gefunden hätte. Sie standen in unserem eigenen Code.
So richten Sie den Scan ein
Der Code-Scan gehört zum Modul KI (ab Plan Team). In GitHub Actions genügt ein Job:
jobs:
codescan:
runs-on: ubuntu-latest
container: ghcr.io/costa-chown/secupipe-autofix:1
steps:
- uses: actions/checkout@v5
with: { fetch-depth: 0 }
- run: secupipe-codescan
env:
SECUPIPE_TOKEN: ${{ secrets.SECUPIPE_TOKEN }}
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
REPO: ${{ github.repository }}
FAIL_ON: hoch
In Pull Requests prüft der Scan nur die geänderten Dateien, sonst das ganze Repository. Mit FAIL_ON: hoch schlägt der Lauf fehl, solange offene Befunde ab diesem Schweregrad vorliegen. Für GitLab CI und andere Systeme gibt es denselben Container; die Anleitung steht in der App unter Pipelines.
Und was passiert nach dem Fund? Den nächsten Schritt beschreibt unser Beitrag Sicherheitslücke gefunden, Pull Request geöffnet.
Kostenlos starten SBOM kostenlos prüfen