Risk Scoring

Why CVSS alone isn't enough

CVSS is a useful base — it tells you the worst-case impact of a vulnerability class. But it doesn't know:

• Whether the vulnerability is actually exploitable in YOUR environment (is the vulnerable code path reachable? is the sink behind auth? is there a mitigation nearby?)
• Whether attackers are CURRENTLY exploiting it (KEV listing)
• How critical the affected asset is (your auth service vs your internal staging box)
• Whether two engines independently agree (SAST says yes + DAST says yes = much higher confidence)

Sectora's risk score combines all of these. Result: a 0–100 number that maps to a queue position, not just a severity bucket.

The formula

risk_score = base_cvss
           × exploitability_multiplier
           × asset_criticality_multiplier
           × kev_multiplier
           × correlation_multiplier
           × (1 - ai_fp_confidence)

All multipliers default to 1.0 (no effect); they only push the score up or down when their signal fires.

base_cvss (0–10)

From NVD / GHSA for known CVEs, or from the rule's declared severity for custom checks. Scaled to 0–100 to align with the final risk_score range.

exploitability_multiplier (0.5–1.5)

Reflects how reachable the vulnerability is in YOUR specific deployment:

• 1.5 — DAST confirmed exploitable. We literally triggered it.
• 1.3 — Public proof-of-concept exists in the wild (EPSS > 0.5).
• 1.0 — Default, no specific signal.
• 0.7 — Behind authentication that's known-strong (e.g. requires admin role).
• 0.5 — Code path requires a non-default config or feature flag.

asset_criticality_multiplier (0.7–1.5)

Set per-asset in Settings → Assets. Tag your services with criticality:

• 1.5 — Tier 0 (auth, payments, customer data). A breach here ends the business.
• 1.2 — Tier 1 (primary product surface).
• 1.0 — Tier 2 (supporting services).
• 0.7 — Tier 3 (internal tools, staging, demo).

If you don't tag, everything defaults to Tier 1.

kev_multiplier (1.0 or 1.5)

1.5 if the CVE is on CISA's Known Exploited Vulnerabilities catalogue — there is confirmed in-the-wild exploitation right now. 1.0 otherwise.

correlation_multiplier (1.0 or 1.4)

1.4 when the same vulnerability was independently detected by TWO engines (e.g. SAST + DAST). Cross-scanner agreement is one of the strongest signals — neither side hallucinated.

ai_fp_confidence (0.0–1.0)

AI Smart Triage's confidence that the finding is a false positive. The score is multiplied by (1 - ai_fp_confidence), so an AI verdict of fp_confidence: 0.85 reduces the risk score by 85%. AI-marked-confirmed-real (fp_confidence: 0.05) barely touches it.

Worked example

A SQLi finding in your payment service's checkout endpoint, confirmed exploitable by DAST:

base_cvss = 9.8         (CVSS Critical for SQLi)
exploitability = 1.5    (DAST confirmed)
asset_criticality = 1.5 (Tier 0 — payments)
kev = 1.0               (custom finding, not a CVE)
correlation = 1.4       (SAST + DAST agree)
ai_fp = 0.05            (AI: definitely real)

risk_score = 9.8 × 1.5 × 1.5 × 1.0 × 1.4 × (1 - 0.05)
           = 29.3 → capped at 100

→ risk_score = 100 (max), goes to top of queue.

Severity bucketing

The 0–100 risk score also maps back to the severity chip you see on each finding:

Two findings with identical CVSS can end up in different buckets because of the multipliers — that's by design.

Trends + benchmarks

The Risk dashboard shows aggregate risk over time per project, per scan engine, per severity. Trend lines surface regressions (yesterday's Critical was fixed; today's deploy introduced two new ones).

Benchmark comparison (Pro+) shows your risk profile vs. anonymised averages from similar-sized teams in the same industry. Useful for board reporting ("we're 40% below the SaaS average for High-severity exposure").

Customising the formula

Each multiplier can be tuned in Settings → Risk Scoring. If your team genuinely doesn't care about KEV-listed CVEs in your dev environment (because the dev environment is isolated), set kev_multiplier to 1.0 for Tier 3 assets. Changes are versioned in the audit log.

What's next

• Vulnerability Management — the workflow that consumes the risk score.
• Compliance — reporting on risk over time + SLA adherence.
• Alerts — wire high-risk findings into your on-call channels.