> ## Documentation Index > Fetch the complete documentation index at: https://docs.corgea.app/llms.txt > Use this file to discover all available pages before exploring further. # Triage-Begründungen > Beim Schließen eines Befunds eine Begründung verlangen ## Überblick Das Schließen eines Befunds ist ein dauerhafter Audit-Eintrag. Ein Kommentar wie "False Positive" oder "Risiko akzeptiert" wiederholt nur die Entscheidung, die bereits im Status festgehalten ist. Wer den Befund Monate später liest – ein Teammitglied, eine neue verantwortliche Person, eine Prüferin oder ein Prüfer – erfährt daraus nichts. Corgea prüft den Kommentar, den Sie bei einer Statusänderung schreiben, und fragt erneut nach, wenn er die Entscheidung nicht begründet. Die Hürde ist niedrig: Ein konkreter Satz, den jemand nachprüfen kann, genügt. Die Begründungspflicht betrifft den Kommentar zu einer Statusänderung. Sie ändert nichts daran, wer einen Status ändern darf; das steuert weiterhin die Berechtigung `change_issue_status`. Siehe [Berechtigungsgruppen](/de/permission_groups). ## Wo sie gilt Die Prüfung läuft überall dort, wo eine Statusänderung erfasst wird: * Im Dialog **Change Decision** auf der Detailseite des Befunds * In der Detailansicht der [Vulnerabilities Workbench](/de/vulnerabilities) * In der Aktionsleiste für Massen-Triage, einschließlich SAST-, SCA- und IaC-Befunden * Bei Verwerfungen, die über den [Corgea Agent](/de/agent) aus einem Pull Request angefordert werden Das Wiedereröffnen eines Befunds ist ausgenommen. Damit wird nichts verworfen, daher gilt dafür keine Begründungspflicht. ## Was eine gute Begründung ausmacht Eine Begründung wird akzeptiert, wenn sie mindestens eine konkrete, überprüfbare Angabe enthält. Eine davon genügt: * **Die Schutzmaßnahme, die den Code sicher macht** – Eingabevalidierung, Ausgabe-Escaping, eine parametrisierte Abfrage, eine Autorisierungsprüfung oder eine Zusicherung des Frameworks * **Warum die Eingabe vertrauenswürdig oder der Pfad in diesem Deployment nicht erreichbar ist** * **Eine kompensierende Maßnahme oder ein geschäftlicher Grund** dafür, das Risiko zu tragen, idealerweise mit verantwortlicher Person, Frist oder Geltungsbereich * **Wo der Fix gelandet ist** oder welchen Befund dieser dupliziert – ein Commit, ein Pull Request, ein Ticket oder eine Befund-ID * **Was der Scanner am Code falsch gelesen hat** Beispiele, die akzeptiert werden: ```plaintext theme={null} Die Abfrage in Zeile 44 ist parametrisiert; der Benutzerwert wird gebunden, nicht verkettet. Diese Eingabe ist der signierte JWT-Claim, der in der Auth-Middleware validiert wird, bevor er diesen Handler erreicht. Interner Endpunkt hinter dem VPN. Akzeptiert bis zum 2.0-Upgrade im nächsten Quartal, verantwortlich ist das Plattform-Team. Behoben in PR #1421, der nach diesem Scan gemerged wurde. Duplikat von Befund 8c31; gleiche Senke, gleicher Commit. ``` ## Was zurückgewiesen wird Ein Kommentar wird zurückgeschickt, wenn er der Entscheidung selbst nichts hinzufügt: | Muster | Beispiele | | ------------------------------------------------------------------- | --------------------------------------------------------------------- | | Wiederholt oder benennt nur die Entscheidung | `false positive`, `accept risk`, `won't fix`, `fixed`, `duplicate` | | Behauptet ein Ergebnis ohne Grund | `not exploitable`, `this is safe`, `not a real issue`, `low priority` | | Fülltext, Platzhalter oder unverständlich | `n/a`, `test`, `asdf`, `...`, `per policy`, `as discussed` | | Nennt eine freigebende Person oder einen Prozess, aber keinen Grund | `approved by security`, `reviewed`, `ticket created` | Wird ein Kommentar zurückgewiesen, erklärt Corgea, was fehlt, und behält Ihren Text, damit Sie ihn ergänzen können. Der Status ändert sich erst, wenn der Kommentar akzeptiert wurde. Dieselbe Formulierung mit einer echten Begründung ist in Ordnung. "False Positive – der Wert wird von der Template-Engine escaped, bevor er gerendert wird" wird akzeptiert; "false positive" allein nicht. ## Wofür Corgea nie zurückweist Die Prüfung achtet nur darauf, ob überhaupt ein Grund genannt wird, nicht darauf, wie gut er formuliert ist. Eine Begründung wird nie wegen ihrer Länge, Rechtschreibung, Grammatik, eines informellen Tons oder der verwendeten Sprache zurückgewiesen. Begründungen in jeder Sprache werden gleich behandelt. Corgea bewertet auch nicht, ob Ihre Begründung fachlich richtig ist – diese Einschätzung bleibt bei Ihrem Team – und akzeptiert den Kommentar im Zweifel. Ist die Prüfung nicht verfügbar, wird der Kommentar akzeptiert und die Statusänderung durchgeführt. Eine ausgefallene Prüfung blockiert die Triage nie. ## Einen Befund aus einem Pull Request schließen Der [Corgea Agent](/de/agent) schreibt denselben Audit-Eintrag, wenn er auf einen Pull-Request-Kommentar reagiert, und verlangt deshalb dieselbe Begründung. Ein Kommentar, der einen Befund ohne Begründung verwerfen will – `@Corgea false positive`, `accept risk`, `not an issue`, `wontfix` –, erhält statt einer Statusänderung eine Rückfrage nach dem Grund. Nennen Sie den Grund im Kommentar, dann erfasst der Agent ihn: ```plaintext theme={null} @Corgea false positive, the query is parameterized on line 44 @Corgea accept risk until the 2.0 upgrade next quarter, this endpoint is internal-only ``` Ein Grund, den Sie bereits früher im selben Thread genannt haben, zählt. Das gilt für Verwerfungen – False Positive und akzeptiertes Risiko –, weil damit ein echter Befund geschlossen wird. Einen Befund aus einem Pull Request als behoben oder als Duplikat zu markieren, bleibt unverändert. ## Eine zweite Prüfung verlangen Eine Begründung erklärt eine Entscheidung, aber für sich genommen prüft sie niemand. Company-Admins können zusätzlich verlangen, dass eine zweite Person eine Verwerfung genehmigt, bevor sie wirksam wird. Aktivieren lässt sich das unter **Settings → Company → Triage approvals** ([öffnen](https://www.corgea.app/settings/company/triage-approvals/)). Die Seite hat zwei unabhängige Schalter, beide standardmäßig aus: * **False positive** – Das Verwerfen eines Befunds als False Positive wartet auf eine Genehmigung. * **Accepted risk** – Das Unterdrücken eines Befunds als akzeptiertes Risiko wartet auf eine Genehmigung, mit oder ohne Ablaufdatum. Ist eine Entscheidung aktiviert, erzeugt sie auf der Detailseite des Befunds, in der Detailansicht der Workbench oder in der Massen-Triage-Leiste eine Anfrage, statt den Status zu ändern. Der Befund behält seinen bisherigen Status und wird als **Pending approval** angezeigt, bis jemand die Anfrage prüft. Ihre Begründung geht mit der Anfrage mit – sie ist das, was die prüfende Person liest. ### Anfragen prüfen Geprüft wird in der Genehmigungs-Warteschlange unter [/approvals/](https://www.corgea.app/approvals/) mit den Tabs **Pending**, **Approved**, **Rejected** und **Withdrawn**. Sie können nach Entscheidung, Projekt und anfragender Person filtern, auf **Everyone**, **Waiting on me** oder **Mine** einschränken und über CWE, CVE, Pfad, Projekt, Begründung, Prüfnotiz und anfragende Person suchen. Die Filter stehen in der Query-Zeichenkette, sodass sich eine gefilterte Ansicht als Link teilen lässt. Die prüfende Person muss eine andere sein als die anfragende, zur selben Company gehören und sowohl die Berechtigung zum Genehmigen von Triage-Anfragen als auch Änderungsrechte für jeden Befundtyp in der Anfrage besitzen. Genehmigung und Ablehnung können eine optionale Notiz enthalten, und anfragende Personen können ihre eigenen Anfragen zurückziehen. Wer Anfragen genehmigen darf, ist von der eigenen Prüfpflicht ausgenommen: Die eigene Entscheidung in die Warteschlange zu stellen, hieße nur, sich selbst zu genehmigen – sie wird daher sofort angewendet. Company-Admins sehen alle Anfragen in der Warteschlange, alle anderen nur ihre eigenen. Jeder Schritt – die Anfrage, die Genehmigung oder Ablehnung, eine etwaige Prüfnotiz und ein Zurückziehen – wird im Verlauf des Befunds festgehalten.