> ## Documentation Index
> Fetch the complete documentation index at: https://docs.launchsafe.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Findings

> Understand LaunchSafe vulnerability findings — severity levels, CVSS scores, proof-of-concept evidence, and the triage-to-remediation workflow.

Findings are verified vulnerabilities discovered during a scan. Unlike simple code linters or basic scanners that flag potential issues, LaunchSafe's AI engine confirms vulnerabilities through exploitation before reporting them — significantly reducing false positives.

## Anatomy of a finding

Every finding in LaunchSafe contains the following information:

### Title & category

A concise description and classification of the vulnerability. Categories follow industry standards including OWASP Top 10, CWE (Common Weakness Enumeration), and SANS Top 25.

**Example:** *SQL Injection via unsanitized user input (CWE-89)*

### Severity & CVSS score

Each finding is assigned a severity level based on its CVSS v3.1 (Common Vulnerability Scoring System) score. The score accounts for:

* **Attack vector** — network, adjacent, local, or physical
* **Attack complexity** — low or high
* **Privileges required** — none, low, or high
* **User interaction** — none or required
* **Impact** — confidentiality, integrity, and availability

### Location

For white-box findings: the exact file path, line number, and function name where the vulnerability exists.

For black-box findings: the URL endpoint, HTTP method, and parameter where the vulnerability was triggered.

For hybrid findings: both — the code location and the runtime endpoint.

### Evidence

Proof that the vulnerability is real and exploitable:

* **White-box:** data flow trace showing how untrusted input reaches a dangerous sink, with each intermediate step annotated
* **Black-box:** full HTTP request/response pair showing the exploit payload and the application's vulnerable response
* **SCA:** CVE identifier, affected version, advisory URL, and proof-of-concept if available

### Remediation

Specific, actionable guidance for fixing the vulnerability:

* Code examples showing the vulnerable pattern and the fixed version
* Library or framework-specific recommendations
* Links to relevant documentation and security guides
* For SCA findings: the exact version to upgrade to

### References

External links to:

* CWE entry explaining the vulnerability class
* OWASP testing guide for the vulnerability type
* CVE entry (for known vulnerabilities)
* Relevant security advisories

***

## Severity levels

### Critical (CVSS 9.0–10.0)

Vulnerabilities that can be exploited remotely, with no authentication, and lead to full system compromise. These require immediate action — they represent active, exploitable paths to data breaches, remote code execution, or complete application takeover.

**Examples:**

* Remote code execution via insecure deserialization
* SQL injection with data exfiltration capability
* Authentication bypass allowing admin access
* Hardcoded production database credentials in public repository
* SSRF with access to cloud metadata endpoint (AWS IMDSv1)

### High (CVSS 7.0–8.9)

Significant vulnerabilities that could be exploited with moderate effort or specific conditions. These should be fixed within days — they represent substantial risk even if exploitation requires some prerequisites.

**Examples:**

* Stored cross-site scripting (XSS) in user-generated content
* Insecure direct object reference (IDOR) exposing other users' data
* Server-side request forgery (SSRF) with internal network access
* Broken access control allowing horizontal privilege escalation
* Dependency with known RCE vulnerability (actively exploited CVE)

### Medium (CVSS 4.0–6.9)

Vulnerabilities that require specific conditions, user interaction, or chaining with other issues to exploit. Fix within your current sprint — they represent real risk but aren't immediately dangerous in isolation.

**Examples:**

* Reflected XSS requiring user to click a crafted link
* Cross-site request forgery (CSRF) on state-changing operations
* Missing security headers (CSP, X-Frame-Options, HSTS)
* Information disclosure via verbose error messages
* Weak cryptographic algorithm usage (SHA-1 for signatures)

### Low (CVSS 0.1–3.9)

Minor issues with limited security impact. Fix when convenient — these are hardening recommendations rather than exploitable vulnerabilities.

**Examples:**

* Cookie without `Secure` flag on HTTPS-only site
* Missing `X-Content-Type-Options` header
* Directory listing enabled on non-sensitive paths
* Server version disclosure in HTTP headers
* Debug comments in production HTML

### Info (CVSS 0.0)

Informational observations with no direct security impact. Review at your discretion — these may indicate areas for improvement but don't represent vulnerabilities.

**Examples:**

* Outdated dependency with no known CVEs
* Non-standard HTTP methods accepted but unused
* Suboptimal TLS cipher suite ordering
* Missing DNS CAA records

***

## Triage workflow

A professional vulnerability triage workflow follows these steps:

<Steps>
  <Step title="Review the finding">
    Read the title, severity, description, and evidence. Understand what the vulnerability is and how it can be exploited. The evidence section shows you exactly what LaunchSafe found.
  </Step>

  <Step title="Verify in your application">
    Confirm the vulnerability exists in your application. For code-level findings, navigate to the file and line number. For runtime findings, try to reproduce using the provided request details.
  </Step>

  <Step title="Assess business impact">
    Consider the finding's severity in your specific context. A SQL injection on a public endpoint with PII is more urgent than one on an internal admin tool behind VPN. Adjust priority accordingly.
  </Step>

  <Step title="Assign and fix">
    Create a ticket in Jira or Linear (one click from the finding), assign it to the appropriate developer, and apply the remediation. If an auto-fix PR is available, review and merge it.
  </Step>

  <Step title="Verify the fix">
    Run another scan to confirm the vulnerability is resolved. LaunchSafe will mark the finding as fixed if it's no longer detected.
  </Step>
</Steps>

***

## Auto-fix pull requests

For supported vulnerability types, LaunchSafe can automatically open a pull request with the fix applied. Auto-fix PRs include:

| Category                       | What gets fixed                                     |
| ------------------------------ | --------------------------------------------------- |
| **Dependency vulnerabilities** | Package version bumped to patched release           |
| **Hardcoded secrets**          | Secret replaced with environment variable reference |
| **Missing input validation**   | Sanitization or parameterization added              |
| **Security headers**           | Middleware or configuration updated                 |
| **Insecure configuration**     | Settings corrected (cookie flags, CORS, etc.)       |

Each PR includes:

* The minimal code change to remediate the vulnerability
* A description explaining what was found and why the fix works
* A link back to the finding in LaunchSafe for full context
* The PR is created from a `launchsafe/fix-*` branch for easy identification

<Info>
  Auto-fix PRs are suggestions, not guarantees. Always review the changes before merging — the fix should be tested against your application to ensure it doesn't break existing functionality.
</Info>