Findings

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:

---

​

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