Evidence Field Guide

Validation Signals & Evidence Fields

Plain-language explanations for every validation signal field in the Evidence tab: what it means, where evidence comes from, how to validate it, and when it should become remediation work.

Candidate vs confirmed evidence Field-by-field validation steps Why it matters Safe investigation workflow

What is a validation signal?

A validation signal is scanner evidence that needs human interpretation before it is treated as a confirmed vulnerability, accepted risk, or closed issue.

evidence_workspace
VALIDATION_SIGNAL Guide Evidence Tab

Candidate evidence is not the same as confirmed risk

What it means

Validation signals often come from candidate asset discovery, historical archives, third-party intelligence, public service indexes, or scanner coverage metadata. They point to something worth checking, but they may require ownership, live-exposure, version, or applicability validation before remediation is assigned.

Why it matters

These fields prevent two mistakes: treating every public clue as a confirmed incident, and treating missing scanner data as proof that everything is safe. Confirmed evidence can drive immediate remediation; candidate evidence should be checked first.

How to read the Evidence tab columns

Use these four columns to decide whether a row is proof, context, or a lead for review.

dashboard_columns
  • Signal names the question being answered, such as Shodan Candidate CVEs, Ownership Status, or Historical Sensitive Paths.
  • Observed value is the scanner-observed result. If it says candidate, review, not verified, historical, unavailable, or requires validation, treat it as a lead instead of proof.
  • Source identifies where the evidence came from, such as dns, ssl, headers, shodan/service, otx, or fingerprint.
  • Confidence shows interpretation status: Validated means clean or expected state, Confirmed means risky state directly observed, Review means human validation required, and Observed means contextual data was collected.

Field-by-field reference

Each row explains the field, how to validate it, and why the evidence matters.

field_reference
Field or value What it means How to validate it Why it matters
candidate / needs_validation A plausible issue exists, but ownership, applicability, or exploitability is not fully proven. Confirm ownership, reproduce the observation, and compare with current production configuration. Attackers can use the same public clue, but prioritize it below confirmed critical exposure until checked.
evidence The proof snippet or scanner observation that caused the row to appear. Review the exact URL, DNS record, HTTP header, banner, CVE, path, timestamp, or response value. Strong evidence gives attackers a shortcut to the same exposed component; weak evidence may be a false positive.
source The scanner or external source that produced the signal. Prefer direct live scanner evidence for fixes; treat passive DNS, archives, OTX, and Shodan as context until confirmed. Public intelligence sources are also attacker recon sources and can guide targeting.
scanner unavailable / coverage gap A scanner did not complete or could not collect reliable data. Retry the scan, check missing API keys or dependencies, and manually validate the affected area if it is important. The risk is unknown; attackers may still see exposure the failed scanner did not collect.
candidate_asset_count / candidate domains or IPs External sources suggest related domains, IPs, ASN ranges, or subdomains. Verify DNS, registration, cloud account, CDN account, certificate ownership, and internal asset inventory. If real and unmanaged, attackers may find shadow IT, forgotten apps, takeover candidates, or exposed services.
ownership_status / attribution_confidence How strongly the scanner can link an asset to your organization. Confirm through registrar records, cloud ownership, DNS zones, certificate SANs, SSO inventory, or engineering ownership. Wrong attribution wastes time; missed attribution leaves real external assets outside remediation.
reverse_whois_match_basis A related-domain candidate based on WHOIS or RDAP similarity. Check current registrar data and internal ownership; shared registrars and old records can create false matches. If valid, attackers can pivot from one known domain to related domains and widen their target list.
historical paths or archived URLs A path appeared in an archive or older public source, not necessarily on the current live site. Test the current URL safely and check for redirect, 404, 403, or sensitive content. If still live, attackers may discover backups, admin paths, API endpoints, old JavaScript, or config files.
Shodan or service CVE candidates An exposed service appears to match a known vulnerable product or version. Verify live banner, exact product, version, patch level, network reachability, and whether the vulnerable feature is enabled. If accurate, attackers can search public exploits, test the service remotely, or chain the CVE with weak controls.
OTX pulses, malware tags, or adversary tags Threat intelligence associated the domain or IP with a public indicator, campaign, or malware context. Confirm exact indicator, timestamp, current ownership, hosting context, and whether the signal is stale. If current and accurate, the asset may already be in threat actor datasets, blocklists, or scanning pipelines.
Package or supply-chain advisory candidates A public package, dependency, or advisory may relate to your organization or deployed software. Confirm package ownership, deployed version, reachable component, advisory applicability, and patch status. If exploitable, attackers can target vulnerable dependencies, poisoned packages, or leaked package ownership metadata.

Signal-by-signal details

Open a row from the Evidence tab to land here with the exact signal selected.

signal_reference

Safe validation workflow

Use this order before opening remediation work for candidate-only evidence.

validation_workflow
  • Fix confirmed critical and high findings first.
  • Check whether the asset is owned or managed before assigning remediation.
  • Verify current live exposure separately from historical archive evidence.
  • For DNS and email records, wait for propagation before deciding a fix failed.
  • For CVE rows, verify exact software, version, patch level, and reachable service.
  • For threat-intelligence rows, confirm indicator, timestamp, and hosting context.
  • Record the validation result so future users know why the signal was accepted, remediated, or dismissed.