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 severity, confidence, decision history, and description.

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.
CVSS vectorCVSS v3.1 base vector. Where one is present it decides the severity.
SeverityCritical, high, medium, low, or info. Derived from the vector.
Severity scoreNumeric score used for sorting, also derived from the vector.
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.

Where a parseable CVSS vector exists, it is the severity authority. Reviewers are asked to correct the vector rather than the label, because correcting the vector corrects the score and the label with it. Workers routinely overstate the attack vector or set Scope to Changed when it should be Unchanged, and those mistakes move the label on their own once fixed.

A label override is only applied in two cases: a finding with no usable vector, or a rubric exception where the base-score band is wrong for something the vector cannot express, such as an exploit chain. An exception keeps the vector and records the reason beside it, so cross-scan calibration stays queryable. A label override on a vectorized finding without an exception is ignored.

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

The proof's code is downloadable directly from the finding page, and when a finding supports a full deployment reproduction, ZeroQuarry can generate a deployment package — a .zip with a containerized stack and seed scripts that reproduces the issue end to end. Account owners can also state a preferred PoC language under Account, which the artifact agent uses as a default when the vulnerability does not dictate one.

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, rendered like a conversation. 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

The assistant can revise findings and reports mid-conversation: when a chat answer changes the finding, the update appears in place, and the tool activity for each step stays visible so you can see what the agent did. Pick a different model for the conversation from the chat model picker when you need one.

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​

Coverage notes record what the scan probed, not only what it found. Before a scan exits, a close-out pass takes the routes the scan's own asset library and probe ledger already know about, and either probes each one or records an explicit reason for skipping it. A known in-scope route that ends the scan unprobed and unjustified is logged as coverage debt and surfaced on the report rather than passing silently.

Two gap classes drive that close-out:

  • Never probed — a known in-scope route no scan of the project has ever probed.
  • Auth differential — a route the scan answered while carrying its session but never probed without one. An authenticated vantage cannot see a no-authentication-required vulnerability, so these are re-probed cookieless. Scans with no configured credentials have no such class.

Routes are worked in order of prior-scan evidence: routes that other scans of the same project cited in a finding come first, then auth-differential overlaps, then the rest. That ordering matters more than it sounds, because the close-out pass is budgeted and an unordered list spends that budget on whichever route happens to sort first.

Coverage distinguishes how a route answered, so a route that exists but refused is not counted as untested. A 401 or 403 means the route is real and needs credentials; a 404 or 410 means it was probed and is not there; a 2xx or 3xx means it was tested.

Read this as review evidence about the scan's reach, not as a guarantee that an unprobed area is free of vulnerabilities.

Next action​