WASViking Docs
⌘K
Concepts

Findings and Risk Score

What a finding is, how WASViking ranks it, and how the workflow keeps the team operating on the highest risk first.

A finding is a specific, reproducible security issue WASViking® detected. Findings are the unit of work for the security team. Everything in the workflow, the Risk Score, the SLA, the audit log, the AI recommendation, exists to make findings actionable.

Anatomy of a finding

Every finding carries:

Field Purpose
Stable fingerprint The same issue is the same row across scans. Drives status preservation.
Category sqli, xss, graphql_bola, cve, and so on. Drives compliance mapping.
Severity critical, high, medium, low. Raw engine output.
CWE Single canonical mapping. See CWE mapping.
Risk Score 0-100 Combines severity with context. The number dashboards rank on.
Evidence Payload, raw HTTP transcript, the analyzer that produced it.
Status open, accepted, mitigated, false_positive, fixed.
SLA window Days by severity, configurable per organization.
Audit log Every status change with operator and timestamp.
Compliance mapping Control IDs across PCI, LGPD, GDPR, BACEN, ISO 27001.
AI recommendation Executive summary, business risk narrative, prioritized action.

Risk Score 0-100

Severity alone is too blunt. WASViking computes a Risk Score that combines:

  • Severity weight. Critical 100, High 80, Medium 40, Low 10.
  • Asset criticality. Inferred from inventory signals (login form, payment form, admin area).
  • Environment. Production amplifies, staging dampens.
  • Industry. A SQLi against a payment endpoint in a fintech weighs more than the same SQLi against a marketing form.
  • SLA window. A finding inside its SLA window keeps its weight; a finding approaching breach gets amplified.

The Risk Score is what the Cyber Risk dashboard ranks on. The team works the top of that list, not the latest report.

Edge correlation and risk amplification

When the Edge Threat Radar observes adversary traffic that maps to an open finding, WASViking amplifies the finding's Risk Score. This ties internet adversary activity to your own posture, in real numbers.

Finding status workflow

open ──▶ accepted ──┐
  │                  │
  ├─▶ mitigated ────┤
  │                  ├──▶ fixed
  └─▶ false_positive ┘

Every transition is auditable and emits a webhook event. Status preservation across scans is the reason the stable fingerprint exists: a mitigated finding stays mitigated after a re-scan, not a fresh open.

SLA windows

Each open finding gets a remediation deadline based on its severity. The deadline is first seen plus the SLA window for that severity. Once the deadline passes and the finding is still open, it counts as breached.

Set the policy under Settings → System Settings → Findings SLA. The window is expressed in days per severity:

Severity Default window
Critical 7 days
High 30 days
Medium 60 days
Low 90 days
Informational Off

Leave a field empty or set it to Off to stop SLA tracking for that severity. Informational findings have no SLA by default.

Two save behaviors, deliberately separate:

  • Save policy applies the new windows to findings going forward. Existing findings keep the deadline they already have.
  • Recompute existing rewrites the due date and breach state of every open finding to match the current policy. Use it when you tighten or loosen a window and want it to apply retroactively.

The SLA breach digest runs on schedule and pushes near-breach findings to the configured destinations so the team sees what is about to age out before it does.

AI recommendation

The AI layer produces an executive summary, a business risk narrative, and a prioritized action per finding, bilingual EN, PT-BR, and ES.

The engine's primary_risk_category wins on every disagreement with the LLM. This is enforced in code, not in marketing. AI cannot drift past the engine.

JWT claim contents in findings stay raw. Enterprise visibility under contract beats blanket redaction for this specific data class.

CWE canonical mapping

WASViking pins a single canonical CWE per finding category. The mapping is version-controlled and tested. Adding a new analyzer means adding a mapping line, by policy.