Vulnerability Management

Finding lifecycle

Every finding flows through this state machine:

detected → open → in_progress → resolved → verified
                ↓
                false_positive (terminal)
                ↓
                accepted_risk (terminal; expires)

Status changes are user-driven (via the UI or API) except detected → open which is automatic, and the auto-FP path via fingerprint inheritance (see below).

Severity model

Five levels; the band determines escalation behavior:

Severity isn't purely CVSS — Sectora's risk-scoring model adjusts based on exploitability, asset criticality, KEV listing, and DAST correlation. See Risk Scoring.

AI Smart Triage

Every finding gets an AI verdict before reaching your queue. The AI receives the finding metadata + code/request context (whole file ≤ 500 lines, otherwise enclosing function + same-file helpers) and returns:

• false_positive — bool
• fp_confidence — 0.0–1.0, how sure
• risk_score — 0–100, refined exploit-likelihood
• analysis — cited reasoning (which lines support the verdict)
• fix_suggestion — concrete fix grounded in the actual code

Triage actions

From any finding card, three primary actions:

Mark as False Positive

When the finding is wrong (sanitizer present, not exploitable in this context, etc.). Record a reason (helps future-you and your team). The finding is removed from the active queue and its fingerprint is remembered — same finding on future scans auto-marks FP without re-triage.

Accept Risk

The finding is real but you've decided not to fix it (acceptable risk for the business context). Set an expiry (default 90 days); the finding resurfaces at expiry to force re-review. Audit log captures who accepted, when, why.

Create Ticket

Pushes to your linked tracker (Jira / Linear / GitHub Issues). The ticket includes:

• Reproduction details (URL + payload for DAST; file:line for SAST)
• Severity + CVSS + CWE
• AI fix suggestion (grounded in your actual code)
• Back-link to the Sectora finding for verify-fix later

On Pro+, auto-ticketing creates one ticket per finding above your configured severity threshold (Settings → Integrations → ticket policy).

Fingerprint-based FP inheritance

Every SAST finding gets a deterministic SHA-256 fingerprint derived from rule_id + file_path + code_snippet (canonicalised, line-number-independent). When you mark a finding as FP, the fingerprint is stored. Subsequent scans on the same target check the fingerprint set and auto-mark matching findings as FP — no re-triage needed for the same bug.

Useful when refactoring: a known-FP that moves to a different line number (but same code shape) stays suppressed. DAST findings use a slightly different fingerprint (URL pattern + method + payload class) but the same inheritance logic applies.

DAST ↔ SAST correlation

The correlator runs after every SAST scan: for each finding, it queries DAST vulnerabilities for the same user's scans matching by file/URL pattern. Matches are stored on correlated_dast_vuln_id and surface in the UI as a green Confirmed chip.

Verify-fix flow

Once a developer claims the fix is shipped, click the green ✓ shield next to the finding. Sectora replays the original exploit:

• DAST findings — same payload, parameter, method, auth context as the original detection. Verdict: Fixed (payload no longer reflects, or endpoint 401/403/404), Still exploitable (payload still triggers — finding stays open with the new response captured for diff), or Error (target unreachable).
• SAST findings — re-runs the scan scoped to the file. Verdict: Fixed (rule no longer fires) or Still present.

Verify-fix can be wired into CI: PR can't merge until POST /api/v1/vulnerabilities/:id/verify returns fixed: true.

Filtering + queue management

The Vulnerabilities page supports filtering by:

• Severity (multi-select)
• Status (open / in_progress / resolved / verified / false_positive / accepted_risk)
• Engine (SAST / DAST / SCA / Secrets / API)
• Project / scan target
• AI verdict (Real / Likely FP / FP confirmed)
• DAST-confirmed (Yes / No)
• Has ticket (Yes / No)
• Age (last 24h / 7d / 30d)

Save filter combinations as views (e.g. "Critical + DAST-confirmed + no ticket" → "Drop everything triage") for one-click access from the dashboard.

SLA tracking (Business plan)

Set time-to-fix targets per severity (e.g. Critical = 48h, High = 7d, Medium = 30d). Findings approaching SLA breach get escalated alerts; SLA-breached findings appear on the Dashboard's "SLA Status" card and in compliance reports.

Bulk operations

Select multiple findings in the list view to:

• Mark FP with a shared reason (e.g. "all use-of-md5 in /scanner is response-dedup not crypto")
• Create tickets in one batch
• Reassign to a team member
• Tag for custom grouping

API

# List findings
GET /api/v1/vulnerabilities?severity=high&status=open&engine=dast

# Update status
PATCH /api/v1/vulnerabilities/:id
{"status":"false_positive","reason":"sanitizer present at line 64"}

# Trigger verify-fix
POST /api/v1/vulnerabilities/:id/verify

# Create ticket
POST /api/v1/vulnerabilities/:id/ticket
{"tracker":"jira","project_key":"SEC"}

What's next

• Risk Scoring — how severity is computed across signals.
• Alerts — Slack / PagerDuty / email wiring.
• Integrations — ticket tracker setup.
• Compliance — reporting on findings + SLAs.