Skip to main content

​
Overview

Closing a finding is a permanent audit record. A comment like “false positive” or “accept risk” only repeats the decision that was already recorded in the status, so anyone reading the finding months later — a teammate, a new owner, an auditor — learns nothing from it. Corgea reviews the comment you write when you change a finding’s status and asks again when it does not explain the decision. The bar is low: one specific sentence that a reader could go and check is enough.
The justification requirement applies to the comment on a status change. It does not change who is allowed to change a status, which remains controlled by the change_issue_status permission. See Permission Groups.

​
Where it applies

The review runs everywhere a status change is recorded:
  • The Change Decision modal on the finding details page
  • The details drawer in the Vulnerabilities Workbench
  • The bulk triage action bar, including SAST, SCA, and IaC findings
  • Dismissals requested from a pull request through the Corgea Agent
Reopening a finding is exempt. Reopening does not dismiss anything, so it carries no justification bar.

​
What makes a good justification

A justification is accepted when it names at least one concrete thing a reader could verify. Any one of these is enough:
  • The control that makes the code safe — input validation, output escaping, a parameterized query, an authorization check, or a framework guarantee
  • Why the input is trusted or the path is unreachable in this deployment
  • A compensating control or business reason for carrying the risk, ideally with an owner, a deadline, or a scope
  • Where the fix landed, or which finding this one duplicates — a commit, pull request, ticket, or finding ID
  • What the scanner misread about the code
Examples that are accepted:

​
What gets rejected

A comment is sent back when it adds nothing to the decision itself: When a comment is rejected, Corgea explains what is missing and keeps what you typed so you can add to it. The status is not changed until the comment is accepted.
The same phrase followed by an actual reason is fine. “False positive — the value is escaped by the template engine before it is rendered” is accepted; “false positive” on its own is not.

​
What Corgea never rejects for

The review looks for whether a reason is given at all, not for how well it is written.
A justification is never rejected because of its length, spelling, grammar, informal tone, or the language it is written in. Justifications written in any language are reviewed on equal terms. Corgea also does not judge whether your reasoning is technically correct — that judgment stays with your team — and accepts the comment when it is unsure.
If the review is unavailable, the comment is accepted and the status change goes through. Triage is never blocked by the review being down.

​
Closing a finding from a pull request

The Corgea Agent writes the same audit record when it acts on a pull request comment, so it asks for the same reason. A comment that asks to dismiss a finding without saying why — @Corgea false positive, accept risk, not an issue, wontfix — gets a reply asking for the reason instead of a status change. Include the reason in the comment and the agent records it:
A reason you already gave earlier in the same thread counts. This applies to dismissals — false positive and accepted risk — because those close a live finding. Marking a finding fixed or duplicate from a pull request is unchanged.

​
Requiring a second reviewer

A justification explains a decision, but on its own nothing checks it. Company admins can also require that a second person approves a dismissal before it takes effect. Turn this on under Settings → Company → Triage approvals (open). The page has two independent toggles, both off by default:
  • False positive — dismissing a finding as a false positive waits for approval.
  • Accepted risk — suppressing a finding as accepted risk, with or without an expiry, waits for approval.
With a decision switched on, making it from the finding details page, the workbench drawer, or the bulk triage bar creates a request instead of changing the status. The finding keeps the status it has and shows as Pending approval until someone reviews it. Your justification travels with the request — it is what the reviewer reads.

​
Reviewing requests

Reviewers work from the approvals queue at /approvals/, which has Pending, Approved, Rejected, and Withdrawn tabs. Filter by decision, project, and requester, narrow to Everyone, Waiting on me, or Mine, and search across CWE, CVE, path, project, justification, reviewer note, and requester. Filters live in the query string, so a filtered view can be shared as a link. A reviewer has to be someone other than the requester, in the same company, holding permission to approve triage requests and to change every finding type in the request. Approving or rejecting can carry an optional note, and requesters can withdraw their own requests.
People who can approve requests are exempt from their own gate: queueing their decision would only ask them to approve themselves, so it applies immediately. Company admins see every request in the queue; everyone else sees only the requests they submitted.
Every step — the request, the approval or rejection, any reviewer note, and a withdrawal — is recorded in the finding’s history timeline.