Understanding Findings

Learn what findings are, where they appear, and how to interpret them.

A finding is a security issue detected by PrismSec during a scan. Findings represent vulnerabilities, exposed secrets, risky dependencies, or misconfigurations that could compromise your application's security.

Anatomy of a Finding

Every finding includes the following information:

Title

A concise summary of the issue, including the vulnerability type:

Examples:

  • SQL Injection in user authentication
  • Hardcoded AWS Secret Access Key
  • Dependency vulnerability: lodash@4.17.15 (CVE-2020-8203)
  • Public S3 bucket with read access

Severity

One of four levels indicating the risk:

  • Critical (Red) — Immediate action required
  • High (Orange) — High priority, should be fixed soon
  • Medium (Yellow) — Moderate risk, fix when possible
  • Low (Blue) — Low risk, best-practice improvement

See Severity & Risk Score for details on how severity is assigned.

Location

The exact file and line number where the issue was detected:

Example:

File: src/auth/login.py
Line: 42

For dependency vulnerabilities, the location points to the manifest file (e.g., package.json, requirements.txt).

Category

Which security pillar detected the finding:

  • SAST — Code-level vulnerability (e.g., SQL injection, XSS)
  • Secret — Hardcoded credential or API key
  • Dependency — Known CVE in a third-party library
  • IaC — Infrastructure or configuration issue

Description

A human-readable explanation of the issue:

  • What the vulnerability is
  • Why it's dangerous
  • How an attacker could exploit it

Example:

This code constructs a SQL query by concatenating user input directly into the query string.
An attacker can manipulate the `user_id` parameter to inject malicious SQL commands, potentially
bypassing authentication, extracting sensitive data, or modifying the database.

Evidence

PrismSec provides context to help you understand the issue:

  • Data flow trace (for SAST findings) — Shows how untrusted input flows to a dangerous sink
  • Secret match (for secret findings) — The pattern or signature that identified the secret
  • CVE details (for dependency findings) — Link to the CVE database entry, CVSS score, affected versions
  • Configuration snippet (for IaC findings) — The exact YAML/HCL/JSON block with the misconfiguration

Example data flow:

Source: request.GET['user_id'] (untrusted user input)
  ↓
Variable: user_id
  ↓
Sink: db.execute(query) (SQL query execution)

Suggested Fix

A recommendation for how to remediate the issue securely:

Example:

Use parameterized queries to prevent SQL injection:

# Before (vulnerable)
query = f"SELECT * FROM users WHERE id = {user_id}"

# After (secure)
query = "SELECT * FROM users WHERE id = %s"
db.execute(query, (user_id,))

For auto-fixable issues, PrismSec will also open a fix PR (see Auto-fix PRs).

Status

The current state of the finding:

| Status | Description | |--------|-------------| | Open | The issue exists and has not been addressed | | Fixed | The issue has been remediated (code changed or dependency updated) | | Ignored | The finding has been marked as a false positive or accepted risk |

Where Findings Appear

Findings are displayed in two places:

1. Pull Request Comments (Inline)

When a PR is scanned, findings appear as inline comments on the exact line of code where the issue was detected.

Example PR comment:

🔴 Critical: SQL Injection

This code constructs a SQL query using unsanitized user input.
An attacker can inject malicious SQL to bypass authentication or extract data.

Recommendation: Use parameterized queries.

See: https://owasp.org/www-community/attacks/SQL_Injection

2. PrismSec Dashboard

All findings for a repository are aggregated in the PrismSec dashboard:

  • Findings overview — Total counts by severity and category
  • Finding list — Searchable/filterable table of all findings
  • Risk score — Overall security health metric
  • Trends — Historical view of findings over time

You can filter findings by:

  • Severity (Critical, High, Medium, Low)
  • Category (SAST, Secret, Dependency, IaC)
  • Status (Open, Fixed, Ignored)
  • File path or line number

Finding States

A finding moves through the following states:

Open → Fixed

When you fix the issue (e.g., patch the vulnerable code, rotate the exposed secret, upgrade the dependency), PrismSec automatically detects the remediation on the next scan and marks the finding as Fixed.

Open → Ignored

If a finding is a false positive or an accepted risk, you can mark it as Ignored. See Triage & Ignoring for details.

Open → Auto-Fix PR Opened

For some findings, PrismSec can automatically generate a fix. The finding remains Open until the fix PR is merged. See Auto-fix PRs.

Understanding Data Flow (SAST Findings)

For SAST findings, PrismSec provides a data flow trace showing how untrusted input reaches a dangerous operation.

Example:

# Vulnerable code
def search_users(request):
    query = request.GET['search']  # Source: untrusted input
    results = db.execute(f"SELECT * FROM users WHERE name LIKE '{query}'")  # Sink: SQL query
    return results

Data flow trace:

  1. Source: request.GET['search'] — User-controlled input
  2. Propagation: Assigned to query variable
  3. Sink: Interpolated into SQL string and passed to db.execute()

Why it's vulnerable: The query variable is never validated or sanitized, allowing an attacker to inject SQL commands.

Next Steps