Remediation: vom verifizierten Befund zur geprüften Änderung

„Erkennen ist nicht Beheben“: was eine prüfbare Änderung ausmacht und warum dein Team die Kontrolle über den Merge behält

Ein Befund sagt dir, dass etwas nicht stimmt. Er ändert keine einzige Zeile deines Codes. Dazwischen liegt Arbeit, die Scanner nicht erledigen. Jemand muss den Fix schreiben und prüfen, ob er die eigentliche Ursache beseitigt, ohne etwas kaputt zu machen. Danach muss die Änderung durch das Review deines Teams.

Remediation ist der Schritt Beheben in Proof-Driven AppSec. AI Swarm Pentest validiert, was ausnutzbar ist (Modul 6), und Deep Code Analysis erklärt, wie sich eine Schwachstelle auf deine Anwendung auswirkt (Modul 5). Remediation macht aus diesem Wissen eine Änderung, die dein Team prüfen kann. Fang mit Befunden an, die du triagiert hast (Modul 4), idealerweise mit solchen, die durch Evidenz gestützt sind, etwa durch einen bestätigten Pentest-Befund oder einen erreichbaren Codepfad. So fließt die Review-Zeit in Risiken, die real sind.

Was eine prüfbare Änderung enthält

In Plexicus ist eine Code-Behebung eine vorgeschlagene Änderung für einen oder mehrere Befunde. Sie ist kein Commit auf deinen Main-Branch und auch kein bloßes „Bitte fixen“-Ticket. Sie besteht aus vier Teilen:

• Ein Diff. Die genauen hinzugefügten und entfernten Zeilen, Datei für Datei.
• Eine Erklärung und ein Titel. Die KI schreibt beides für den Reviewer und beschreibt, was sich geändert hat und warum. Daraus werden Beschreibung und Titel des Pull Requests.
• Ein Verifizierungs-Badge. Es zeigt dir, ob der Fix getestet wurde und mit welchem Ergebnis.
• Ein Ziel. Die Änderung landet in einem neuen Branch deines Repositorys, mit einem Pull Request gegen deinen Base-Branch. Auf GitLab ist das ein Merge Request.

Nimm eine SQL-Injection in einem Login-Handler, der die übermittelte E-Mail-Adresse per Verkettung in einen Query-String einbaut. Eine prüfbare Änderung ersetzt die Verkettung in diesem Handler durch eine parametrisierte Query und erklärt, warum. Sie kommt als Pull Request an, den deine Reviewer neben der Evidenz des Befunds lesen können. Sie schreibt nicht deine Datenzugriffsschicht um, und nichts erreicht deinen Main-Branch, bis jemand aus deinem Team sie mergt.

Warum dein Team die Kontrolle über den Merge behält

Plexicus mergt nie einen Pull Request zur Behebung. Gemergt wird in deiner Quellcodeverwaltung, unter deinen Branch-Schutzregeln, deinen Pflicht-Reviews und deiner CI, und zwar von Menschen aus deinem Team. Dafür gibt es drei Gründe.

• KI-geschriebener Code kann falsch oder unvollständig sein. Der Review-Bildschirm enthält einen Hinweis, der dich bittet, den Vorschlag gegen den Kontext und die Anforderungen deines Projekts zu validieren.
• Dein Team kennt den Kontext. Nimm eine IDOR in einer Rechnungs-API, bei der jeder angemeldete Kunde die Rechnung eines anderen Kunden lesen kann, indem er die ID ändert. Ein Fix könnte eine Eigentümerprüfung ergänzen. Nur dein Team weiß, ob der Support weiterhin jede Rechnung öffnen können soll.
• Verantwortlichkeit. Die Beschreibung des Pull Requests nennt die Person, die ihn geöffnet hat, und deine Quellcodeverwaltung hält fest, wer ihn freigegeben und gemergt hat. Plexicus schreibt Behebungsanfragen in das Audit-Log der Organisation, und der Abschnitt Activity jedes Befunds zeigt, wann eine Behebung generiert und wann ihr Pull Request erstellt wurde.

Welche Befunde sich im Code beheben lassen

Plexicus kann nur patchen, was in einem Repository liegt. Was die Detailansicht eines Befunds anbietet, hängt davon ab, woher der Befund stammt.

Befund	Was die Detailansicht anbietet
Ein Befund, der auf eine Datei in einem verbundenen Repository zeigt	Create AI Remediation
Ein Befund aus einer Container-Registry, dessen Image mit einem Quell-Repository verknüpft ist	Remediate in repo
Ein Befund mit dem Behebungstyp Issue, etwa wenn es keine Quellzeile zu ändern gibt	Create Issue
Ein AI Pentest-Befund	Kein Code-Fix, außer der Pentest hat ein verknüpftes Quell-Repository; kläre mit Plexicus, ob Pentest-Fixes in deinem Release verfügbar sind
Eine Cloud-Fehlkonfiguration, ein SCM-Posture-Befund oder ein Registry-Image ohne verknüpftes Repository	Keine Behebungsaktion

Hat ein AI Pentest kein verknüpftes Repository, weist Plexicus dich darauf hin, dass die Behebung ein verknüpftes Quell-Repository voraussetzt und dass du eines in den Pentest-Einstellungen konfigurieren kannst.

Eine KI-Behebung erstellen: Prüfungen, Fix-Strategien und Live-Fortschritt

Die Prüfungen, die Plexicus zuerst ausführt

Plexicus stellt vorab sicher, dass die Arbeit gelingen kann.

1. KI-Verbindung. Plexicus testet die KI-Verbindung deiner Organisation, egal ob es der Plexicus-Standard ist oder deine eigene (Lektion 5).
2. SCM-Verbindung. Plexicus validiert dein Token für die Quellcodeverwaltung. Ist das Token nicht mehr gültig, bittet Plexicus dich, deine Quellcodeverwaltung neu zu verbinden.
3. Repository-Zugriff. Plexicus bestätigt, dass das Repository erreichbar ist.
4. False-Positive-Einstufung. Ein Befund, der noch auf die False-Positive-Prüfung wartet, oder einer, den der KI-Durchlauf als False Positive markiert hat, lässt sich nicht beheben. Der Tooltip weist darauf hin, und auch der Server setzt die Sperre durch. Wenn du die False-Positive-Markierung der KI zurücknimmst (Modul 4), ist die Sperre aufgehoben.
5. Immer nur eine Person. Behebt ein Kollege den Befund bereits, ist der Button deaktiviert und zeigt „Another user is working on this finding“.

Sandbox-Demo-Repositories überspringen die SCM-Prüfungen und können Fixes generieren, aber keine Pull Requests oder Issues öffnen. Ist dein monatliches KI-Nutzungskontingent aufgebraucht, ist der Button deaktiviert (Lektion 5).

Wie Plexicus eine Fix-Strategie wählt

Die Strategie wählst nicht du. Plexicus leitet sie aus dem Befund ab.

Situation	Strategie	Wie die Änderung entsteht
Eine Person hat den Befund als False Positive markiert	Suppression-Kommentar	Ein Inline-Kommentar, der diese Regel an dieser Stelle stummschaltet
Ein Abhängigkeitsbefund mit bekannter gepatchter Version in derselben Major-Version	Versionsanhebung der Abhängigkeit	Eine deterministische Änderung am Manifest, ohne dass eine KI Code schreibt
Alles andere, einschließlich Abhängigkeits-Upgrades über eine Major-Version hinweg	KI-Fix-Agent	Eine Codeänderung, die der Agent schreibt

Der Suppression-Kommentar folgt auf eine menschliche Entscheidung. Wenn jemand einen Befund als False Positive markiert (Modul 4), fordert Plexicus eine Änderung an, die diesen Kommentar hinzufügt. Je nach Anbieter deiner Quellcodeverwaltung kommt sie als Pull Request zum Review durch dein Team an und belastet dein KI-Nutzungskontingent nicht.

Die Versionsanhebung der Abhängigkeit deckt gängige Manifeste ab, darunter npm, Composer, requirements.txt, Gemfile, TOML-Dateien, go.mod, Gradle und .csproj. Die vorgeschlagene Version wird gegen die Paket-Registry geprüft; lässt sie sich nicht verifizieren, trägt die Behebung die Warnung „review before merging“. Ein Sprung über eine Major-Version kann die API der Bibliothek ändern, deshalb geht er an den KI-Fix-Agenten. Zwar schreibt keine KI die Anhebung, sie wird aber trotzdem auf dein KI-Nutzungskontingent angerechnet.

Was der KI-Fix-Agent tut und was nicht

Der Agent arbeitet auf einem frischen Klon des konfigurierten Branches im Repository. Sein Scope ist bewusst eng:

• Er behebt nur das gemeldete Problem in der gemeldeten Datei und Zeile.
• Eine andere Datei fasst er nur an, wenn der Fix es erfordert, etwa bei einem gemeinsam genutzten Helper.
• Er ist angewiesen, nicht zu refaktorieren, keine anderen Probleme zu beheben, die ihm auffallen, keine Testdateien zu bearbeiten und nicht zu committen. Plexicus erfasst das Ergebnis als Git-Diff.

Anweisungen sind keine Garantien. Prüf den Diff deshalb auf alles, was über den Befund hinausgeht.

Für gängige Schwachstellenklassen bekommt der Agent das Secure-Coding-Muster für die Sprache der Datei: SQL-Injection (CWE-89), Cross-Site Scripting (CWE-79), OS Command Injection (CWE-78), Path Traversal (CWE-22) und unsichere temporäre Dateien (CWE-377). Das lenkt ihn zu einer parametrisierten Query statt zu einem Blocklist-Filter. Bei einem offengelegten Secret verschiebt der Agent den Wert in eine Umgebungsvariable, und das Review ergänzt den Hinweis, eine Secret-Management-Lösung zu konfigurieren.

Deckt eine Behebung mehrere Befunde ab, werden sie nach Datei gruppiert, einige wenige pro KI-Sitzung, und die Gruppen laufen nacheinander. Fertige Gruppen werden auch dann geliefert, wenn eine spätere Gruppe in ein Timeout läuft.

Den Fortschritt verfolgen

Das Live-Terminal streamt jeden Schritt: vom Klonen des Repositorys über „Generating fix…“ und eine Zeile pro Dateigruppe bis zu „Fix captured“ und einem Endergebnis. Sobald der Fix fertig ist, öffnet sich der Review-Dialog automatisch. Mit View AI Remediation öffnest du ihn später erneut.

Läuft ein Fix nach 15 Minuten noch, meldet Plexicus „This remediation is taking longer than expected.“ und bietet Create Remediation Again an. Schlägt die Generierung fehl, siehst du „Failed to create remediation“ und einen Button Try Again. Ein fehlgeschlagener Versuch blockiert nie einen neuen.

Den Fix prüfen und den Pull Request öffnen

Im Review-Dialog ist dein Urteil gefragt. Lies ihn wie den Pull Request eines Kollegen, mit der Evidenz des Befunds daneben.

Was der Review-Dialog zeigt

• Den Titel des Befunds und ein Verifizierungs-Badge.
• Eine Zusammenfassung der Änderung: hinzugefügte Zeilen, entfernte Zeilen und die Anzahl der Dateien.
• Einen Unified Diff für jede Datei. Jede generierte Zeile, die beschädigt aussieht, ist durchgestrichen und mit „Possibly corrupt generated line — review before applying.“ markiert.
• Einen einklappbaren Abschnitt Why this fix — reasoning & verification mit der von der KI geschriebenen Erklärung.
• Den KI-Hinweis sowie Quell- und Ziel-Branch, die der Pull Request verwendet.

Die Erklärung ist in der Scan & Report Language deiner Organisation geschrieben, die ein Admin unter Settings Platform festlegt.

Das Verifizierungs-Badge lesen

Die Fix-Verifizierung ist optional. Deine Organisation aktiviert sie mit dem Schalter Fix verification unter Settings Platform , und ob sie verfügbar ist, hängt von deinem Plan ab. Ist sie aktiv, läuft eine zweite KI-Sitzung in einer isolierten Wegwerfkopie des Repositorys. Sie schreibt einen gezielten Sicherheitstest für den Befund und führt ihn gegen den gefixten Code aus.

Badge	Was es bedeutet
Fix verified	Der isolierte Test lief und war gegen den gefixten Code erfolgreich
Fix not tested	Für diesen Fix wurde kein Verifizierungstest ausgeführt
Fix unverified	Der Fix wurde angewendet, aber der Test lief in ein Timeout, daher ist der Fix nicht nachgewiesen
Verification failed	Der Test hat gezeigt, dass die Schwachstelle weiterhin ausnutzbar ist
Verification error	Der Test konnte nicht ausgeführt werden

Die Verifizierung kennzeichnet den Fix nur. Den Diff, den du prüfst, ändert sie nie.

Was du prüfen solltest, bevor du den Pull Request öffnest

• Ursache, nicht Symptom. Beim Login-Handler ist eine parametrisierte Query der Fix. Anführungszeichen im E-Mail-Feld zu escapen ist es nicht.
• Verhalten. Bestätige bei der Rechnungs-IDOR, dass die neue Eigentümerprüfung zu deinen tatsächlichen Autorisierungsregeln passt.
• Abhängigkeiten. Lies das Changelog der neuen Version und prüf, ob dein Lockfile neu erzeugt werden muss.
• Secrets. Ein Secret in eine Umgebungsvariable zu verschieben stoppt das Leck im Code, aber der alte Wert bleibt kompromittiert. Rotiere ihn.

Bearbeiten, dann den Pull Request öffnen

Mit den Standardrollen können Admins und Cyberoper den generierten Code bearbeiten, solange noch kein Pull Request existiert. Nutze Edit Pull Request oder bei einem Fix über mehrere Dateien für jede Datei Edit und dann Save. Sobald ein Pull Request oder Issue existiert, wird die Bearbeitung mit „A pull request has already been created — editing is locked.“ gesperrt. Ab dann änderst du den Code auf dem Branch in deiner Quellcodeverwaltung.

Ist die Änderung fertig, klickt ein Admin oder Developer unten im Dialog auf Pull Request (auf GitLab Merge Request). Plexicus klont den konfigurierten Branch und legt einen neuen Branch an, dessen Name mit Plexicus-AI-Remediation- beginnt. Es wendet den Diff an, pusht und öffnet einen Pull Request gegen den Base-Branch. Titel und Beschreibung stammen aus der Behebung, und die Beschreibung endet mit „Created by:“ und der E-Mail-Adresse der Person, die ihn geöffnet hat. Ein Banner bestätigt „Pull request created“ mit einem Link See PR, und der Button am Befund wird zu See Pull Request.

Pull Requests zur Behebung funktionieren auf GitHub, GitLab, Bitbucket Cloud, Azure DevOps, Gitea und Forgejo. Azure TFVC kennt keine Pull Requests. Schlägt der Push fehl, nennt Plexicus den Grund: Das Repository ist ein schreibgeschützter Mirror, das Token braucht Schreibzugriff, oder das Token ist ungültig.

Für Befunde, die über ein Issue behoben werden, bietet der Dialog Create Issue an, dazu Send Webhook, wenn ein Issue-Webhook konfiguriert ist. Ist eine Ticketing-Integration so eingerichtet, dass sie Pull Requests folgt, wird auch das Ticket aktualisiert (Modul 9).

Status	Was er hier bedeutet
Ready to Fix	Eine Behebung ist generiert und wartet auf das Review
Fix Submitted	Ein Pull Request oder Merge Request wurde geöffnet
Issued	Statt eines Pull Requests wurde ein Issue geöffnet
Fixed	Deine Quellcodeverwaltung hat den Pull Request als gemergt oder das verknüpfte Issue als geschlossen gemeldet

Bulk-Behebung für viele Befunde

Meldet ein Scan 40 verwundbare Pakete in einem Service, kommst du mit der Behebung einzelner Befunde nicht mehr hinterher. Die Bulk-Behebung wendet denselben Ablauf auf eine Auswahl an und verfolgt den gesamten Lauf an einer Stelle. Ob die Bulk-Behebung verfügbar ist, hängt von deinem Plan ab.

Einen Bulk-Lauf starten

Hake unter Findings mindestens zwei Befunde an, öffne die Bulk-Aktionen und wähl Remediate. Eine Anfrage nimmt bis zu 100 Befunde an. Welche Bulk-Aktionen du siehst, hängt von deiner Rolle ab (Modul 4); mit den integrierten Rollen können Developer Create Pull Request nur für Befunde nutzen, deren Behebung bereits generiert ist.

Plexicus gruppiert die Auswahl nach Repository und dann nach Fix-Strategie, genau wie bei einem einzelnen Befund (Lektion 2). In jedem Repository werden Suppression-Kommentare, Versionsanhebungen von Abhängigkeiten und KI-Fixes jeweils zu einer eigenen Behebung, und nur die KI-Fixes durchlaufen die Dateigruppen des KI-Fix-Agenten. Befunde, die über ein Issue behoben werden, bekommen jeweils ein eigenes, von der KI geschriebenes Issue. Der Dialog hat zwei Optionen:

• Automatically create pull requests. Standardmäßig aktiv. Ist die Option aus, bleiben Fixes bei Ready to Fix stehen, und nichts wird gepusht.
• Pull request mode gilt für die KI-Fixes. In beiden Fällen bekommt jedes Repository dafür einen Pull Request. Single PR hält jede Behebungsgruppe als eigenen Commit fest, sodass Reviewer die Änderung Datei für Datei durchgehen können, und lässt Gruppen weg, die fehlgeschlagen sind oder nichts geändert haben. One PR per remediation, die Standardeinstellung, liefert dieselben Fixes als einen einzigen Commit. Versionsanhebungen und Suppression-Kommentare bekommen immer einen eigenen Pull Request.

Klick auf Remediate, um zu starten. Befunde, die bereits eine Behebung haben, werden übersprungen. Befunde, die noch auf die False-Positive-Prüfung warten oder die der KI-Durchlauf als False Positive markiert hat, sind gesperrt, genau wie bei der Einzelbehebung.

Den Lauf verfolgen

Der Schalter in der Toolbar Findings Bulk remediation status öffnet den Bereich Bulk Remediation Progress. Jeder Lauf durchläuft vier Phasen: Queued, Generating fixes, Creating pull request und Completed. Ein Lauf zeigt Running, Completed oder Incomplete.

Jede Behebungsgruppe, also einige Befunde in derselben Datei, zeigt ihren eigenen Status. Diese siehst du am häufigsten:

Gruppenstatus	Bedeutung
Queued	Wartet auf die Behebungs-Engine
Processing (mit Prozentangabe)	Der KI-Fix-Agent arbeitet an dieser Gruppe
Succeeded	Die Gruppe hat eine Änderung erzeugt
Failed	Die KI-Sitzung ist auf einen Fehler gestoßen oder in ein Timeout gelaufen
Skipped (no changes)	Die Gruppe hat keine Änderung erzeugt, und ihre Befunde bleiben, wie sie waren

Jede Gruppe hat ihr eigenes Live-Terminal, und View Pull Request führt dich zum Ergebnis. Der Bereich übersteht ein Neuladen der Seite, und das ganze Team kann ihn sehen. Ein Kollege kann einen Lauf verfolgen, den du gestartet hast, ohne dich nach dem Stand zu fragen. Im Modus Single PR behalten Befunde in einer Gruppe, die fehlgeschlagen ist oder keine Änderung erzeugt hat, ihren Status.

Einen Batch zusammenstellen, den deine Reviewer bewältigen können

Ein Bulk-Lauf ist nur so nützlich wie die Pull Requests, die er erzeugt. Bündle Batches nach Repository, nach verantwortlichem Team und nach Problemklasse. Wähl zum Beispiel die 25 Befunde zu verwundbaren Abhängigkeiten im Payment-Service statt 25 zusammenhanglose Befunde aus sechs Repositories. Ein fokussierter Batch gibt einem Team einen Pull Request, den es wiedererkennt und in einem Durchgang prüfen kann. Ein gemischter Batch erzeugt Pull Requests, für die sich niemand verantwortlich fühlt.

KI-Konfiguration und Nutzung: Kontingent, Bring Your Own AI und was nie automatisch passiert

Dein KI-Nutzungskontingent

KI-Aktionen gehen zulasten eines gemeinsamen monatlichen Kontingents deiner Organisation. Dazu gehören KI-Fixes, Versionsanhebungen von Abhängigkeiten, von der KI geschriebene Issues und die KI-gestützte False-Positive-Analyse. Repository-Scans auszuführen verbraucht nichts davon, KI-gestützte Analysen können aber Kontingent verbrauchen. Wirf deshalb vor einem großen KI-Scan einen Blick auf die Anzeige. Das Kontingent wird am 1. jedes Kalendermonats (UTC) zurückgesetzt, nicht an deinem Abrechnungsdatum. AI Pentest-Sitzungen (Modul 6) und KI-Filterumwandlungen haben eigene Zähler. Wie groß dein Kontingent ist, hängt von deinem Plan ab.

Wenn Nutzungsdaten vorliegen, zeigt dein Profilmenü eine Nutzungsanzeige und einen Link Manage billing & usage. Je nach Plan zeigt Settings Billing , eine Seite mit dem Titel Billing & Usage, wie viel von deinem Limit in diesem Monat verbraucht wurde und an welchem Datum das Kontingent zurückgesetzt wird, oder Unlimited. Auf der Seite Billing wird der Balken bei 75 % orange und bei 90 % rot, und Plexicus warnt dich an beiden Punkten. Wenn dein Release sie enthält, schlüsselt eine Seite Usage unter Settings die Nutzung nach Aktion auf, mit vollständigem Verlauf.

Ist das Kontingent aufgebraucht, ist Create AI Remediation mit dem Hinweis deaktiviert, dass das monatliche Limit erreicht ist, Remediate ist für Bulk-Läufe deaktiviert, und die Seite Findings zeigt ein Banner mit Upgrade plan. KI-Aktionen laufen wieder, sobald das Kontingent zurückgesetzt wird.

Bring Your Own AI (BYO-AI)

Je nach Plan kannst du die KI von Plexicus auf deinen eigenen Modell-Endpunkten statt auf den Plexicus-Standardmodellen betreiben.

Slot	Wofür er genutzt wird	Was du eingibst
Fast model	Läuft bei jedem Befund für Validierung und Anreicherung und bewältigt daher hohes Volumen	API key, Base URL, Model
Smart model	Generiert Fixes und tiefgehende Analysen, mit geringerem Volumen und höherer Tragweite	API key, Base URL, Model
Embeddings endpoint	Baut vor jedem KI-Scan den durchsuchbaren Index deines Codes auf	API key und Base URL; das Embeddings-Modell ist fest vorgegeben und wird schreibgeschützt angezeigt

Jeder Slot akzeptiert einen standardmäßigen Chat-Completions- oder Embeddings-Endpunkt deines KI-Anbieters mit Authentifizierung per API-Key, auch ein selbst gehostetes Gateway. Eine Auswahl des Anbieters gibt es nicht. Save BYOAI configuration testet und speichert alle drei Blöcke gemeinsam, und der Embeddings-Endpunkt ist Pflicht, weil eine unvollständige Einrichtung jeden KI-Scan unbrauchbar machen würde. Gespeicherte Keys werden nie wieder angezeigt; lass ein Key-Feld leer, um den Key zu behalten. Base URLs werden vor einem Verbindungstest auf Server-Side Request Forgery geprüft. Reset to Plexicus default leert alle drei Blöcke. Mit BYO-AI zeigt die Nutzungsanzeige Unlimited, weil die Inferenz über deinen eigenen Key und dein eigenes Konto bei deinem KI-Anbieter läuft.

Wohin dein Code geht

KI-Funktionen senden den relevanten Code-Kontext an den konfigurierten Modell-Endpunkt: die Plexicus-Standardmodelle oder mit BYO-AI deinen eigenen Endpunkt. Jede Behebung läuft in einem kurzlebigen, isolierten Job. Der Agent kann nur in seinen geklonten Workspace schreiben und bekommt keine der übrigen Zugangsdaten der Plattform. Die Verifizierung läuft in einer Wegwerfkopie, die danach gelöscht wird. Kundencode wird nicht zum Training von KI-Modellen verwendet, und SaaS-Daten bleiben standardmäßig in der EU.

Was nie automatisch passiert

Das Wichtigste in Kürze

• Eine Behebung ist ein Vorschlag: ein Diff, eine Erklärung, ein Verifizierungs-Badge und ein Pull Request auf einem neuen Branch. Plexicus mergt ihn nie. Das macht dein Team, in deiner Quellcodeverwaltung.
• Bevor ein Fix startet, prüft Plexicus die KI-Verbindung, das SCM-Token, den Repository-Zugriff und die False-Positive-Einstufung. Danach wählt es einen Suppression-Kommentar, eine Versionsanhebung der Abhängigkeit oder den KI-Fix-Agenten.
• Prüf den Diff und die Erklärung „Why this fix“ wie jeden anderen Pull Request. Ein Badge Fix verified belegt, dass der gezielte Test bestanden wurde, nicht, dass nichts anderes kaputtgegangen ist.
• Bearbeite die Behebung, solange sie noch ein Vorschlag ist. Sobald der Pull Request existiert, wird die Bearbeitung gesperrt, und aus Fix Submitted wird erst Fixed, wenn deine Quellcodeverwaltung den Merge meldet.
• Die Bulk-Behebung gruppiert bis zu 100 Befunde nach Repository und Fix-Strategie. Entscheide bewusst über automatische Pull Requests und den Pull-Request-Modus, und verfolge den Lauf im Bereich Bulk Remediation Progress.
• KI-Aktionen gehen zulasten eines monatlichen KI-Nutzungskontingents, das unter Settings Billing und in deinem Profilmenü angezeigt wird. Mit BYO-AI richtest du die Slots Fast, Smart und Embeddings auf die Endpunkte deines eigenen KI-Anbieters aus.