Triage to remediation

The report is not the end of the workflow. It is the starting point for deciding what is real, what matters, who owns the fix, and what evidence should be preserved.

Triage usually happens at the finding-detail level, where the evidence, confidence, exports, chat, and remediation helpers are all visible together.

Use this playbook after any completed scan with findings.

Triage goals

Triage should produce four decisions for each important finding:

1. Is the finding real enough to act on?
2. How severe is the impact in this product?
3. Who should fix or accept the risk?
4. What evidence belongs in the ticket, export, or disclosure?

ZeroQuarry provides severity, confidence, exploit proofs, independent review, chat, exports, finding lifecycle states, patch generation, auto-fix proposals, and issue tracker handoff to support those decisions.

Step 1: Start from severity, then check confidence

Open the report and sort by severity. For each critical or high finding, look at confidence before assigning work.

High severity and high confidence usually means "fix now." High severity and low confidence means "validate now." Low severity and high confidence may still matter if the affected component is regulated, externally exposed, or commonly chained with other issues.

Read next: Findings and Confidence and review.

Step 2: Read evidence before the conclusion

For each candidate finding, inspect:

• affected source path, URL, artifact path, or endpoint
• reproduction steps or exploit proof
• assumptions about authentication and roles
• CVSS vector and severity rationale
• any related coverage notes
• vendor verdict and rebuttal, if present

When evidence is thin, ask finding chat targeted questions:

What exact authorization check is missing, and what role boundary does it cross?

Give me the shortest reproduction path an engineer could use in staging.

What would make this a false positive?

Step 3: Challenge important findings

Use independent adversarial review for findings that will be expensive, controversial, or shared outside the security team. The independent reviewer tries to reject weak claims; the researcher rebuttal either restores confidence with evidence or lets the finding stand as challenged.

Do not treat a rejected vendor verdict as automatic deletion. Treat it as a signal to read the evidence and decide whether the product context changes the answer.

Record the outcome on the finding:

• Validated when the claim applies to your product
• Needs Validation when an important assumption is unresolved
• Disputed with a reason when the claim is not actionable in context

Read Finding lifecycle and audit trail.

Step 4: Create remediation work

When the finding comes from source code and the scan still has source available, use patch generation if your tier includes it. A patch is a starting point, not a merge-ready guarantee.

Review generated patches for:

• whether they preserve expected behavior
• whether the fix covers every affected path
• whether new validation is too narrow or too broad
• whether tests should be added around the vulnerable flow

If the first patch is close but not quite right, use feedback to generate a new revision.

For an enrolled GitHub repository, an auto-fix proposal can take the reviewed diff into a bot-created pull request. Manual approval is the starting posture; auto-push is an explicit per-repository opt-in. ZeroQuarry never auto-merges.

If code generation is not appropriate, file the finding into Jira, ServiceNow, or GitHub Issues from the finding actions. The engineering ticket should name the expected mitigation and how the security retest will determine success.

Read Auto-fix pull requests and Jira, ServiceNow, and GitHub Issues.

Step 5: Hand off the right artifact

Different audiences need different outputs:

Audience	Best artifact
Engineer	Finding export with source, impact, exploit proof, and patch link
Security lead	Report export filtered by confidence and severity
Product owner	Summary, affected feature, customer impact, timeline
External vendor	Disclosure draft plus manually reviewed exploit proof
Auditor	Report export including targets and coverage notes
Customer or partner	Expiring secure share containing only selected findings

Read next: Exports and disclosures.

Step 6: Re-run and compare

After remediation, re-run the scan in the same project and lineage. For a source scan, use a focused note:

Validate the fix for the organization role escalation finding. Re-check related
invite acceptance, session creation, and project membership paths.

Use finding fingerprints and report history to confirm whether the issue disappeared, changed shape, or moved to a related path.

Move the original finding to Mitigated when a fix is expected to address the risk. Move it to Retested only after the later assessment provides evidence. Use Regression if the issue returns. These state changes become part of the report audit trail.