prpl
Sign in
← All documentation
Review and respond

Acknowledge true positives or reject false positives

Document that acknowledgement confirms a true positive and immediately starts Defend patch generation; rejection marks a false positive.

userorg admin capture: review-findings

Outcome

You have recorded a decision on a finding that was waiting for review: either acknowledged it as a true positive — which immediately starts Defend patch generation — or rejected it as a false positive.

Who can do it

  • Acknowledge true positive & generate patch (the primary button on the repository page) requires the patch.generate capability on that repository, because it spends a patch-generation run in the same click. Customers hold it on their own repositories; organization members need it granted by an owner (directly, or via the Repo owner role); site admins always hold it.
  • Reject as false positive and the occurrence-level acknowledge buttons live in the human review panel on the scan run page. Posting a decision requires the finding.review capability; the panel is shown to the run's owner or a site admin. The Findings reviewer role grants finding.review on one repository.

See Roles and permissions for the capability matrix.

Before you begin

Acknowledging starts patch generation immediately. Clicking Acknowledge true positive & generate patch does two things at once: it records your approval on every pending occurrence of the deduped finding, and it launches a Defend patch-generation run — a cost-incurring agent run that may end in a pull request against your repository. Review the evidence before you click, and use the occurrence-level Acknowledge true positive (hold patch) button if you want to confirm a vulnerability without generating a patch.
  • The finding shows the needs review status — see Understand findings for how to read the evidence, severity, and confidence signals.
  • The scan that produced the finding has finished; decisions on a still-running scan are refused and can be retried after it completes.

Steps

  1. Open Attack Surface (/byos), select the repository, and stay on the Findings tab.
  2. Click the needs review filter chip to isolate the rows waiting for a decision. The Needs your decision action center on the landing page lists the same items across all your repositories.
  3. A deduped finding row in the needs review state; call out the status badge and the primary action button on the row.
  4. Open the finding (click its status badge or finding id) and weigh the evidence: the verdict panel's validation state and rubric score, the proof-of-concept files, and the evidence: strong/moderate/weak summary in the human review panel.
  5. If it is a real vulnerability: back on the repository page, click Acknowledge true positive & generate patch on the row. A confirmation dialog restates both effects — approval is recorded on every pending occurrence and Defend patch generation starts immediately. Confirm to proceed.
  6. The page reloads with the banner "True positive acknowledged — Defend patch generation launched." and a link to the patch-generation run.
  7. The review decision controls; call out the Acknowledge true positive & generate patch button and its confirmation dialog naming both effects.
  8. If it is a false positive: in the human review panel on the finding's scan run page, optionally set the reviewer name and a review note, then click Reject as false positive. The finding is excluded from patch generation and its group shows the false positive status.
  9. If it is real but you do not want a patch yet: use Acknowledge true positive (marks it defend-ready without launching anything) or Acknowledge true positive (hold patch) (confirms it and withholds it from patch generation — the finding shows a defend held chip). Every decision is bound to the exact report you reviewed — the panel notes "decision is bound to this report hash".

Verify

  • After acknowledging: the banner "True positive acknowledged — Defend patch generation launched." appears, and the row's status moves to defend running, then defended when the patch run finishes — see Generate and review patches with Defend.
  • After rejecting: the row's status shows false positive and the human review panel records the decision, the reviewer, and the timestamp.
  • The item disappears from the Needs your decision action center on the next page load.

Troubleshooting

  • The acknowledge button is not on the row — you can view but not spend: you lack patch.generate on this repository (waitlist accounts, and members without a cost grant). Ask the repository's owner for access.
  • "you do not have defend access to this repository" (403) — the per-repository capability check refused the action before recording any approval; nothing was changed.
  • Decision refused while the scan is running — the run page shows a review busy notice; wait for the scan to complete and submit the decision again.
  • Rejected the wrong finding? A decision is recorded against the reviewed report and is not reversible from the UI; a new scan re-validates the code path and produces a fresh finding to review. You can also record the pattern for future scans in repository knowledge.
  • Rejected rows clutter the table — use the row's archive control to hide them from the default view; see Archive scans, findings, and history.

Next steps

Follow the launched patch run in Generate and review patches with Defend, then turn the patch into a pull request in Review and approve a Defend pull request.

Last verified against commit c0bf54d on 2026-07-10 · capture scenario: review-findings