RedStrikeby Encyfr

Findings & Reports

Findings & Verification

How RedStrike verifies findings to cut false positives, and how to triage, accept, dismiss, and track them over time.

2 min read

The value of a scanner isn't how many issues it reports — it's how many real ones it proves. RedStrike verifies findings so your team spends time on confirmed risk, not false positives.

TL;DR

Every candidate finding is put through a verification step that safely confirms exploitability. Verified findings are marked as such and prioritized. You triage by accepting, dismissing, or assigning them, and RedStrike tracks status and history across scans.

What verification means

After a tool flags a candidate, RedStrike attempts a safe, non-destructive confirmation — for example, proving an endpoint reflects injected input, that a bucket truly returns objects anonymously, or that a service version matches a known-vulnerable CVE. The outcome sets the finding's confidence:

StatusMeaning
VerifiedExploitability confirmed with evidence
UnconfirmedReported by a tool, not independently proven
InformationalContext/hardening, not directly exploitable

Verification is designed to be non-destructive. RedStrike confirms presence, not impact — it will demonstrate that an issue exists without exfiltrating data or damaging systems.

Severity and prioritization

Findings carry a severity from Critical to Info. Prioritization combines severity with verification status and asset exposure, so a verified high on an internet-facing asset outranks an unconfirmed critical on an internal one.

Triage workflow

Work findings from the Findings tab:

  1. Filter to Verified + Critical/High to start where it matters.
  2. Open a finding to see evidence, reproduction steps, and remediation.
  3. Act:
    • Accept — acknowledge and track to remediation.
    • Assign — hand it to a teammate or push to Jira.
    • Dismiss — mark as false positive or accepted risk, with a reason.
  4. Re-scan to confirm fixes; the finding flips to Fixed when it's gone.

Deduplication and history

The same issue seen across multiple scans is a single finding with a timeline: first seen, verified, assigned, fixed. This prevents alert fatigue and gives you an accurate mean-time-to-remediate.

finding fnd_88a2
├── first_seen   2026-06-01  (Standard scan)
├── verified     2026-06-01
├── assigned     2026-06-02  (Jira SEC-412)
└── fixed        2026-06-09  (confirmed by re-scan)

Suppression rules

To reduce recurring noise, create suppression rules — for example, ignore a specific informational template on a known accepted-risk asset. Suppressions are logged and reversible, so nothing disappears silently.

Next