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, proof-of-concept, and follow-up actions.

Finding detail is where severity, confidence, evidence, PoCs, 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.

Proofs of concept​

When artifact generation is enabled, each finding can include proof of concept material. PoCs 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 PoCs 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 vendor-review signals.
  5. Validate the PoC 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 PoC 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, PoC, 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.

Non-issues​

Reports may include notable non-issues. These are areas the agents reviewed and marked clean. Non-issues are useful for audit coverage because they show where the scan spent time even when no finding was recorded.

Next action​