Skip to main content

Findings

Findings are the main output of a scan, but they are not meant to be accepted blindly. Treat each finding as a security claim with evidence attached.

The report sorts findings by severity score so the highest-impact claims are visible first. Your triage process should then consider confidence, evidence, business context, and remediation cost.

ZeroQuarry finding detail view with evidence, exploit proof, and follow-up actions.

Finding detail is where severity, confidence, evidence, exploit proofs, exports, and downstream actions come together for one security claim.

Finding fields​

FieldMeaning
TitleShort issue name.
SeverityCritical, high, medium, low, or info.
Severity scoreNumeric score used for sorting.
CVSS vectorCVSS v3.1 base vector when the agent produced one.
ConfidenceProbability-like score from ZeroQuarry review signals.
Vulnerability typeThe issue class, such as SSRF or authorization bypass.
SourceFile, line, URL, binary artifact, or other evidence location.
DescriptionTechnical explanation and impact.
CVE referencesRelated known-vulnerability references when applicable.
Lifecycle stateThe team's current decision, backed by append-only history.

Record the decision​

New results begin as candidates. After review, use the finding controls to move the issue through validation, mitigation, retest, accepted risk, dispute, or archive. Decisions that close or contest a finding should include enough reason for a future reviewer to understand the product context.

Lifecycle state is different from severity and confidence: it records what the team decided to do. Read Finding lifecycle and audit trail.

Exploit proofs​

When artifact generation is enabled, each finding can include an exploit proof (proof of concept). Proofs vary by mode:

  • source scans usually reference code paths and reproduction steps
  • binary scans may include artifact evidence and reproduction guidance
  • remote scans may include HTTP requests or payload sequences

Treat exploit proofs as starting points for validation. Review them before running them against sensitive systems.

How to review a finding​

For each important finding:

  1. Read the source, URL, artifact path, or other evidence location.
  2. Confirm the affected asset and environment.
  3. Check the severity rationale and CVSS vector.
  4. Review confidence and independent-review signals.
  5. Validate the exploit proof or ask for a safer reproduction path.
  6. Decide whether to fix, challenge, accept, disclose, or monitor.

Use Triage to remediation for the full workflow.

Finding chat​

Each finding has its own chat thread. Use it to:

  • ask why the issue is exploitable
  • request a more concise remediation summary
  • ask for a exploit proof in a different language or format
  • challenge the finding as a false positive
  • ask the model to revise the title, severity, or description

Finding discussions can continue for multiple review rounds. If the model revises the finding, confirm the updated title, severity, description, exploit proof, and lifecycle decision before exporting it.

Good finding-chat prompts are specific:

Explain this as a Jira ticket for the team that owns project membership.
What evidence would disprove this finding?
Rewrite the reproduction steps for a staging environment with two test users.

Coverage notes​

Reports may include coverage notes. These are areas the researcher examined without recording a vulnerability. They help explain where the assessment spent time, but they are review evidence rather than a guarantee that an area is free of vulnerabilities.

Next action​