Severity & Risk Score

Understand how PrismSec assigns severity levels and calculates repository risk scores.

Every finding in PrismSec is assigned a severity level (Critical, High, Medium, or Low) based on the potential impact and exploitability of the vulnerability. These severity levels feed into an overall risk score that quantifies the security health of your repository.

Severity Levels

PrismSec assigns one of four severity levels to each finding:

| Severity | Color | Description | Examples | |----------|-------|-------------|----------| | Critical | Red | Easily exploitable vulnerabilities that can lead to complete system compromise, data breaches, or remote code execution | Hardcoded production API keys, SQL injection in authentication flows, remote code execution (RCE) flaws, publicly exposed databases | | High | Orange | Exploitable vulnerabilities that can lead to unauthorized access, data leaks, or significant security degradation | Cross-site scripting (XSS) in user-facing features, insecure deserialization, privilege escalation, missing authentication checks | | Medium | Yellow | Vulnerabilities that require specific conditions to exploit or have limited impact | Weak cryptographic algorithms, insufficient input validation, exposed debug endpoints, missing rate limiting | | Low | Blue | Security weaknesses or best-practice violations that are unlikely to be exploited on their own | Information disclosure in logs, missing security headers, outdated dependencies with no known exploits, weak password policies |

How Severity is Determined

PrismSec evaluates multiple factors when assigning severity:

  1. Impact — What an attacker could achieve if the vulnerability is exploited (data theft, system access, service disruption)
  2. Exploitability — How easy it is to exploit the vulnerability (requires authentication? network access? specific conditions?)
  3. Scope — How much of the application is affected (single function vs. entire service)
  4. Context — Is the vulnerable code reachable from untrusted input? Is it deployed in production?

PrismSec uses context-aware analysis to adjust severity. A SQL injection in an internal admin panel may be rated Medium if it requires authentication, whereas the same vulnerability in a public API endpoint is rated Critical.

Severity for Different Pillars

Each security pillar uses severity differently:

SAST (Code Vulnerabilities)

Severity depends on the type of vulnerability and where it occurs:

  • Critical — SQL injection, command injection, remote code execution, authentication bypass
  • High — XSS, SSRF, insecure deserialization, path traversal
  • Medium — Weak cryptography, CSRF, information disclosure
  • Low — Missing input validation, insecure logging, weak password requirements

Secret Detection

Severity depends on the type and sensitivity of the exposed secret:

  • Critical — Production API keys, database credentials, private signing keys, OAuth tokens
  • High — Staging/development API keys, internal service tokens, SSH private keys
  • Medium — Low-privilege API keys, non-sensitive tokens
  • Low — Placeholder or example credentials (if clearly not real)

Dependencies (SCA)

Severity aligns with the CVSS score of the CVE:

  • Critical — CVSS 9.0–10.0
  • High — CVSS 7.0–8.9
  • Medium — CVSS 4.0–6.9
  • Low — CVSS 0.1–3.9

PrismSec also adjusts severity based on reachability analysis: if a vulnerable function in a dependency is never called in your code, the severity may be downgraded.

IaC & Misconfiguration

Severity depends on the security risk of the misconfiguration:

  • Critical — Publicly exposed databases, storage buckets with world-read access, overly permissive IAM roles granting admin access
  • High — Unencrypted data at rest, missing security groups, weak network policies
  • Medium — Missing logging/monitoring, non-rotated secrets, overly broad permissions
  • Low — Missing resource tags, non-compliant naming conventions

Risk Score

In addition to individual finding severities, PrismSec calculates an overall risk score for your repository. This is a single number from 0 to 100 that represents the security health of your codebase.

How Risk Score is Calculated

The risk score aggregates all findings by severity:

  • Critical findings have the highest weight
  • High findings contribute significantly to risk
  • Medium and Low findings have smaller impact

Formula:

Risk Score = 100 - (Critical × 20 + High × 10 + Medium × 3 + Low × 1)

The score is capped at 0 (highest risk) and 100 (lowest risk, healthiest codebase).

Example:

A repository with:

  • 2 Critical findings
  • 5 High findings
  • 10 Medium findings
  • 8 Low findings

Would have a risk score of:

100 - (2×20 + 5×10 + 10×3 + 8×1) = 100 - (40 + 50 + 30 + 8) = 100 - 128 = 0 (capped at 0)

A risk score of 100 means your repository has zero security findings. Scores above 80 indicate a healthy, well-secured codebase. Scores below 50 suggest significant security issues that should be addressed urgently.

Interpreting Risk Scores

| Risk Score | Status | Action | |------------|--------|--------| | 90–100 | Excellent | Maintain current security practices | | 70–89 | Good | Address Medium/Low findings as time permits | | 50–69 | Moderate Risk | Prioritize High findings; plan remediation for Critical issues | | 0–49 | High Risk | Immediate action required; block merges until Critical/High findings are resolved |

Risk Score Trends

The PrismSec dashboard shows risk score over time, allowing you to track security improvements:

  • Upward trend — Security is improving (findings are being fixed)
  • Downward trend — New vulnerabilities are being introduced faster than they're fixed
  • Flat — Security is stable, but not improving

Using Severity in CI/CD

You can configure PrismSec to fail CI checks based on severity thresholds:

# prismsec.yml
severity_threshold: high

With this setting, a pull request will fail if it introduces Critical or High findings.

See Configuring Scans for details.

Next Steps