Triaging findings

A finding is something a scan saw that's worth knowing: an open port, a weak TLS setting, a missing email record, a lookalike domain. Each scan updates them: new ones appear, changed ones are marked, and fixed ones are resolved.

#Severities

The Findings page shows everything to act on (all but info), worst first, with tabs by severity. A finding about software with known vulnerabilities lists its CVEs, and its severity rises to match the worst of them.

#How to fix

Open a finding to see:

• How to fix: the steps, with configuration examples (nginx, Apache, DNS records) where they help, and how to check the fix worked.
• OWASP and NIST: the OWASP Top 10 category and NIST controls it relates to, useful for audits and reports.
• What the scan saw: the raw scan output, for the details.

#Verify fix

Fixed something? Owners, admins and analysts can press Verify fix in an open finding's details to rerun only the check behind it, instead of waiting for the next scan or using a Scan now run:

• Email records (SPF, DMARC, MTA-STS, TLS-RPT, DNSSEC): the one record is looked up again.
• Web software (WhatWeb): the page where it was seen is requested again.
• Nuclei: the template that matched is run again.
• Open ports (Nmap): the one port is probed again.
• TLS (testssl.sh): the one TLS check is run again.
• ZAP and Nikto: these can't rerun one check, so the whole scan of the target runs again, which can take up to an hour. Pressing Verify fix says so first, and the scan only starts once you press Run the full scan.

A single check takes seconds to a few minutes, a whole ZAP or Nikto scan up to an hour, and the result shows in the finding's details with when it ran:

• Verified fixed: the finding is resolved now. The result stays in its details until you press Done; then it leaves the open findings.
• Still detected: what was seen this time, so you can tell whether the fix took (a cached config, or another host serving the old one).
• Inconclusive: the check couldn't tell (a timeout, no answer), and why. The finding is left as it was.

A run that ends without a result (it failed or ran out of time) says so; an earlier run's result is never shown in its place. Close the details or reload the list while it runs and it's picked up again when you reopen the finding in the same tab.

Each finding can be verified 3 times a day, and each organization 50 times; these don't count as Scan now runs, and every run counts, whatever it found. The button is greyed out, with the reason, once the limit is reached, when the target isn't authorized or verified, or when verify fix doesn't cover the finding's scanner; a Scan now of the whole scanner checks those. For ZAP and Nikto, the first press only asks you to confirm the whole scan: nothing runs, and nothing counts toward the limits, until you press Run the full scan.

#Setting findings aside

Not every finding needs a fix. Owners, admins and analysts can set one aside:

• Accept risk: you know about it and accept it.
• False positive: it isn't really there.

Each needs a reason, and can have a review date. A finding set aside leaves the open list and stops alerting. It moves to the Set aside tab, where Reopen brings it back.

It reopens by itself when its review date passes, or when a later scan sees it change, for example a higher severity.

#Owners

On paid plans, owners, admins and analysts can give a finding an owner: the member who is to fix it. Pick one under Owner in the finding's details, or use Assign… above the list to give every open finding of a target, of a scanner, or of a scanner on a target to one member at once. Set-aside and informational findings are left as they are. A member who leaves the organization no longer owns anything, and their findings show as unassigned; if they are invited back, they start with none.

When someone verifies a fix and the finding is still detected, its owner is told in their notifications as well as the person who asked.

With SLAs on, a finding's owner hears by email and in their notifications when it's due soon: 3 days before its due date, or 7 for an SLA of 30 days or more. They hear again when it goes overdue, and every 7 days after that while it stays overdue, 5 more times at most. Owners and admins hear about the findings nobody owns. Each person gets one email a day listing theirs. A severity with no SLA days (informational, by default) sends none.

#Teams

On paid plans, owners and admins can give a finding a team label: free text such as Platform or Web team, one per finding, kept across scans like its owner. Set it under Team in the finding's details, or use Label… above the list to label every open finding of a target, of a scanner, or of a scanner on a target at once. The Team menu shows only one team's findings, and Assign… can give every open finding with a label to one member.

The Show menu narrows the list:

• Overdue: past its due date (with SLAs turned on in the organization's settings).
• Due this week: due in the next seven days.
• Mine: findings you own.
• Unassigned: findings no one owns.

On Business and Enterprise, an SLA digest emails the organization's alert recipients its overdue findings and those due this week, grouped by owner, with unassigned findings as their own group. It goes weekly on Mondays at 08:00 unless you choose otherwise: daily at 08:00, or off, in the time zone you pick, under Alerts. Nothing is sent when there's nothing to report.

#Expected ports

Each target can list the ports that should be open (for example 80 and 443). An open port on the list is noted as expected; one that isn't is raised to medium, so a service exposed by mistake stands out.

#Evidence

On Pay-as-you-go and Enterprise, a finding shows its scan's evidence to download: the scanner's own report (JSON, XML or HTML) and any files it kept. A lookalike domain's finding lists only its own screenshots. On Free, lookalike screenshots still show on the finding and on the Lookalike domains page; the other files come with Pay-as-you-go.

#History

A target's history lists every scan: when it ran, what it found by severity, and what changed since the scan before (found, changed, resolved). A failed scan says why, and leaves the findings as they were.

#Alerts

Under Alerts, owners and admins choose:

• Who: owners and admins by default, or a list of addresses.
• When: after each scan, or a daily or weekly digest.
• Where else: Slack, which gets the same alerts as the email: after each scan, or the digest.
• What: a minimum severity (for example Medium and up), and which changes alert: new, changed or fixed findings, and failed scans.

A digest also gives each target's Domain and Email security scores, and how far they moved since the last one.

#A target's own alerts

A target can differ from these in its Settings → Alerts: say, production alerting after each scan on Medium and up, and staging in a weekly digest on High and up. It shows Using organization defaults until something is changed, and Reset to defaults goes back (a mute stays until it ends or is lifted). Owners and admins set:

• Recipients: the organization's, only addresses of its own (the team that owns it), or both.
• When, Minimum severity and What alerts, as above.
• Slack: every Slack channel of the organization's, or only some of them.
• Mute: no alerts until an end date, at most 90 days away, with a reason if you like (a migration, a pentest window). Findings are still recorded, and the organization's digest says which targets are muted; with no digest to send, the organization's recipients get a note naming them on Mondays.

Each change is listed on the card with who made it. A target's own addresses can unsubscribe from the link in its alerts (when the last of a target's only addresses does, its alerts go back to the organization's recipients), and the Alerts page shows when one bounces, like the organization's. The Alerts page lists the targets with their own settings, and those muted now.

Some alerts go out whatever a target's settings or mute: an expired TLS certificate or domain registration, and a scanner failing 3 runs in a row.

These settings cover email, the bell and Slack. Webhooks and tickets keep their own filters.

Beyond alerts:

• Tickets: findings can become tickets in GitHub or Linear, on the Tickets page. See Tickets in GitHub and Linear.
• Webhooks: signed webhooks, with one event per finding if you like. See Webhooks and ticket automation.

An alert is about what changed: new findings, findings that changed, and findings that were fixed.