Skip to content
Documentation

Triage

Read a scan report

Every finding carries five attributes that combine into a single priority score. Knowing what each means is the difference between fixing the right thing first and chasing noise.

Severity

How bad the issue is if exploited:

  • Critical - full system compromise possible. Examples: RCE, SQL injection that leaks any data, exposed AWS root credentials, alg=none JWT.
  • High - significant data exposure or privilege escalation. Mass assignment of is_admin, BFLA on /admin, dangling subdomain pointing at an unclaimed provider.
  • Medium - hardening gap that compounds with another bug. Missing HSTS, CSP unsafe-inline, HttpOnly missing on session cookie.
  • Low - best-practice deviation, rarely exploitable on its own. TLS 1.0/1.1 still enabled, information disclosure in robots.txt.
  • Info - observation worth recording. Detected framework, observed SDK in mobile binary.

Confidence

How sure we are this finding is real. New in NANOTESTING vs many other scanners - it lets you skip the "possible" column and focus only on confirmed during a fast triage.

  • Confirmed - the worker observed the vulnerable behavior directly. Echo-detection saw the mass-assignment field reflect; the canary URL was hit by an alt-token; the open-redirect target matched.
  • Likely- strong indirect signal. Curated admin path returned 2xx, but we cannot confirm without the customer's domain logic.
  • Possible - heuristic signal. Surface enumeration (a parameter named url= looks SSRF-suspicious; we have not actually probed it).
  • Informational - no exploitation claim; recorded for context (SDK fingerprint, framework guess).

Triage trick: filter to severity in (critical, high) AND confidence in (confirmed, likely)for the first-pass list. That's usually 10-20% of total findings and covers 90% of the real risk.

Priority score (0-100)

Findings sort by priority by default, not raw severity. The composite is:

priority = severity_weight
         + (kev ? 25 : 0)
         + epss_bump(0-25)
         + confidence_adjustment
         + recency_factor

That's why a Critical / Possible finding can rank below a High / Confirmed + KEV finding - the KEV bump alone is worth 25 points which dominates the severity gap.

KEV + EPSS chips

KEV(red chip): the CVE is on CISA's Known Exploited Vulnerabilities catalog - i.e. active in-the-wild attacks are happening right now. KEV findings always come first.

EPSS (amber chip): the FIRST.org Exploit Prediction Scoring System percentile. We show the chip when EPSS is 0.90 or above (top 10% most-likely-to-be-exploited CVEs). The chip text is the actual percentile, e.g. EPSS 97.

KEV + EPSS are refreshed nightly at 03:17 UTC by a cron that pulls both feeds and recomputes priority on every open finding. A finding that was unimportant yesterday can jump up the list the morning a CVE lands on KEV.

Categories + tags

Every finding carries a category (Injection, Authorization concern, Transport security, Vulnerable dependency, Secrets exposure, etc.). CVE findings also carry CWE id, OWASP Top 10 category, and OWASP API Top 10 tag where applicable. The Compliance PDF rolls these up into an ISO 27001 Annex A and SOC 2 TSC evidence matrix.

Status workflow

  • open - default for new findings
  • in_review - someone on your team picked it up
  • fixed- you say you've patched it. Click Run retest to launch a fresh scan; status flips to verified_fixed if the signature no longer appears.
  • accepted_risk - you have decided not to fix (with a reason).
  • false_positive - the rule misfired. The report writes to finding_fp_reports; the admin dashboard surfaces per-detector FP rates so we can tighten noisy rules.

Discussion threads

Every finding has a permalink at /findings/{id} with an org-only comment thread. Use it to: link to your ticket tracker, record "owner: dev-team-A", note why you accepted the risk, paste the fix PR URL. Author or admin can soft-delete; deleted comments leave a tombstone for thread continuity.