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.
