Skip to main content
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:
1

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.
2

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.
3

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.
4

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.
5

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.

​
Auto-fix pull requests

For supported vulnerability types, LaunchSafe can automatically open a pull request with the fix applied. Auto-fix PRs include: 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
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.