Logo StartupKit
DE
English Deutsch Français Español Polski

Codegestützte KI-Triage

Führen Sie Ihren eigenen KI-Sicherheitsagenten in Ihrer CI über jede VDP-Meldung und Ihren Code aus – mit Ihrem Modell und vollständig abgeschottet. Kit handelt nie automatisch.

Diese Übersetzung ist möglicherweise veraltet. Die englische Version wurde seit der letzten Übersetzung dieser Seite aktualisiert. Auf Englisch ansehen →

Warum das zählt

Das KI-Screening beantwortet schnell eine Frage: Ist diese Meldung die Zeit eines Menschen wert? Die codegestützte KI-Triage geht den nächsten Schritt: Sie reproduziert den Fehler, bewertet die Ausnutzbarkeit, findet betroffenen Code und schlägt CVSS-Einstufung und Behebung vor.

Für AppSec-Verantwortliche ist ein Unterschied entscheidend: Der Agent gehört Ihnen, nicht Kit. Er läuft in Ihrer GitLab CI, gegen Ihren Code und mit Ihrem Modell – standardmäßig DeepSeek, alternativ jedes Anthropic-kompatible Modell wie lokales vLLM, Ollama, OpenRouter oder Anthropic selbst. Kit sieht Ihren Quellcode nicht und führt das Modell nicht aus. Wir liefern den Ablauf für Eingang, Duplikaterkennung, Auszahlungen, SLA, Nachweiskette und Kommunikation mit Forschern sowie einen stabilen Vertrag für Ihren Agenten.

Eine in einer Angreifer-Meldung versteckte Prompt-Injection kann weder Ihren Code ausschleusen noch das Internet aufrufen. Der Agent läuft abgeschottet; die Netzwerkgrenze wird außerhalb des Agenten erzwungen. Das Sicherheitsmodell erklärt So funktioniert die Abschottung.

Important

Die Triage ist nur beratend. Kit stellt die zurückgegebene Bewertung als nicht vertrauenswürdige Eingabe dar und ändert Status, Schweregrad oder Prämie nie selbst. Ein Mensch prüft jeden Vorschlag und wendet ihn ausdrücklich an.

So läuft der Prozess ab

Wenn ein Forscher eine Meldung einreicht, löst Kit eine Pipeline in Ihrem Fork des Beispiel-Repositories aus. Ihr CI-Runner erledigt den Rest und sendet das Ergebnis an die Meldung zurück.

Schritt Ort Was passiert
1. Meldung eingereicht Kit Ein Forscher reicht eine VDP-Meldung ein. Kit erstellt einen Triage-Lauf mit Status pending.
2. Pipeline ausgelöst Kit → GitLab Kit ruft die GitLab-API für Pipeline-Trigger in Ihrem Fork auf und übergibt Meldungs-ID, begrenzte MCP-URL und ein kurzlebiges Token als CI-Variablen.
3. Agent läuft Ihre GitLab CI Ein Runner checkt Ihren Code aus, liest die Meldung mit dem begrenzten MCP-Token, untersucht den Code und erzeugt die Triage-Daten – abgeschottet, ohne ausgehende Verbindung außer zu Ihrem Modell-Endpunkt und dem MCP-Host von Kit.
4. Ergebnis zurückgesendet Ihr Agent → Kit Der Agent prüft seine Ausgabe gegen das Schema und sendet sie mit demselben begrenzten Token zurück. Der Triage-Bereich der Meldung aktualisiert sich live.

Der gesamte Durchlauf dauert meist 2–5 Minuten. Diese Verzögerung entsteht durch die Abschottung und ist kein Fehler. Solange Ihre CI arbeitet, zeigt die Meldungsseite einen aktuellen Status.

Was der Agent liefert

Die Triage-Daten sind eine strukturierte Vorbewertung für Ihr Engineering-Team. Kit zeigt sie im Tab „Details“ direkt unter dem KI-Screening in einem eigenen Bereich Codegestützte Triage:

  • Reproduziert – ja, nein oder teilweise, jeweils mit Begründung des Agenten.
  • Ausnutzbarkeit – eine verständliche Einschätzung, wie gut sich der Fund ausnutzen lässt.
  • Vorgeschlagener Schweregrad und CVSS-Vektor – neben der Selbsteinschätzung des Forschers, sodass der Unterschied sofort sichtbar ist: „Forscher: Kritisch · Ihr Agent: Hoch“.
  • Betroffene Stellen – path:line → function() mit direktem Link zum passenden Blob in Ihrem GitLab-Repository.
  • Duplikaterkennung – mit der embeddings-basierten Duplikatprüfung von Kit abgeglichen; stimmen beide überein, erscheint ein zusammengeführter Hinweis.
  • Empfohlene Behebung – ein konkreter Vorschlag für Ihren Stack.
  • Signale und Begründung – welche Nachweise der Agent gefunden hat und wie er zur Bewertung kam.

Alle Inhalte werden escaped und als nicht vertrauenswürdig dargestellt. Keine Ausgabe des Agenten wird als HTML ausgeführt.

Das Beispiel-Repository

Der Agent liegt in einem quelloffenen Beispiel-Repository, das Sie forken und selbst besitzen:

[email protected]:startupkit/vdp-ai-triage-example.git

Es ist eine Referenzimplementierung für einen stabilen Vertrag, kein verwaltetes Produkt. Nach dem Fork kontrollieren Sie Prompt (agent/prompts/triage.md), Modell, Netzwerkrichtlinie und Ausgabeschema. Enthalten sind:

  • Eine .gitlab-ci.yml, die Trigger-Variablen empfängt, den Agenten abgeschottet ausführt und die Triage zurücksendet.
  • Ein Mock- beziehungsweise --dry-run-Modus, mit dem die Pipeline anhand einer Beispielmeldung erfolgreich läuft, bevor Sie einen echten Modellschlüssel oder Kit verbinden.
  • Eine Injection-Canary-Beispielmeldung, die einen externen Host per curl aufzurufen versucht. Damit weisen Sie nach, dass Ihre Egress-Grenze den Versuch blockiert.

Sichtbare Zustände

Status Bedeutung
Ausstehend / Läuft Ihre CI hat den Trigger übernommen und arbeitet. Der Bereich zeigt eine Platzhalteransicht mit aktuellem Status.
Abgeschlossen Die Triage-Daten sind eingetroffen und werden angezeigt.
Fehlgeschlagen Ihre Pipeline ist fehlgeschlagen oder der Agent konnte keine gültige Ausgabe erzeugen. Der Bereich zeigt einen konkreten Fehler sowie Links zur Pipeline und zum erneuten Auslösen.
Zeitüberschreitung Ihr Agent hat nicht innerhalb des Zeitlimits geantwortet, standardmäßig 15 Minuten. Die Fehleranzeige ist dieselbe.

Ein fehlgeschlagener oder abgelaufener Lauf blockiert die Meldung nie. Da die Triage beratend ist, bleibt die Meldung genau wie ohne Agent in Ihrer Warteschlange.

Kurz-Check

Wie geht es weiter

Suchbegriff eingeben...