Launch Security Check

We scanned sample-app (19 files, 396 lines) with LaunchCheck built-in checks and Gitleaks. The scan produced 70 findings across 27 distinct issue types: 15 critical, 42 high, 10 medium and 3 low.

Assessment: grade F, score 0/100. Not ready to launch. Critical issues expose data, credentials or infrastructure.

Every finding in this report was reviewed by Demo reviewer (illustrative decisions on planted sample data); 1 automated finding(s) were dismissed as false positives.

Highest risks

1. Hardcoded API key or provider secret (7 places) - Anyone who can read the code - a contractor, a leaked zip, a public repo, an AI tool with repo access - can use this key.
2. LLM output passed to a dangerous sink (3 places) - Model output is untrusted text: a prompt-injected document or user can make the model write anything.
3. Secret exposed to the browser through a public env prefix (2 places) - Variables with these prefixes are copied into the JavaScript that every visitor downloads.
4. Table created without Row Level Security (2 places) - Supabase exposes every table in the public schema through an auto-generated API.
5. Private key committed to the repository (1 place) - A private key proves identity.

Recommended order of work

1. Rotate every exposed credential and remove secrets from the repository. Assume they are already compromised.
2. Close access-control gaps: database row-level rules and authentication on every API route.
3. Remove injection paths and stop executing model output; restrict agent tools and MCP servers.
4. Harden configuration (CORS, debug, rate limits) and lock dependency versions.

This document starts as the output of an automated first pass. In a paid engagement a senior engineer then works through it and the codebase. That review adds what tooling cannot:

• Confirms what is exploitable. Each automated finding is checked in context. False positives are removed, and real issues are ranked by what an attacker could do with them, not by pattern match.
• Tests authorisation logic. Whether user A can read user B's records, whether tenants are isolated and whether admin functions are reachable are logic questions a pattern scanner cannot answer.
• Reads the database rules against the data model. Row Level Security policies are reviewed table by table for what each role can select, insert, update and delete.
• Looks at how the app is deployed. With access you grant: environment configuration, exposed endpoints, storage buckets, security headers and what the production build ships to the browser.
• Exercises the LLM features. Prompt injection, data leakage through the model, and what the agent's tools and MCP servers allow when the model is manipulated.
• Checks git history and third-party access. Secrets that were committed and later deleted are still in history; tokens are checked for scope and rotation.
• Delivers a fix plan. A prioritised list your developer or AI assistant can act on, a walkthrough call, and a re-check after fixes.

In scope: a static review of the source tree sample-app as provided on 2026-11-11: 19 text files, 396 lines. Dependency folders, build output, lockfile contents, test fixtures and git-ignored .env files were skipped.

Scanners used

Findings from all scanners are normalised into one schema and de-duplicated (same rule class, file and line range); the Source column lists every scanner that reported a finding. A scanner shown as skipped or failed contributed nothing to this report.

Not covered

• The running application, its hosting, cloud accounts, DNS and network were not tested. This is not a penetration test.
• Git history was not examined by the built-in checks; a secret that was committed and later removed will not appear.
• Authorisation logic (who may access which record), business logic and payment flows are not assessed by pattern matching.
• The built-in checks are heuristics over source text. They do not follow data across files, so they produce both false positives and missed issues.
• Languages and frameworks outside JavaScript/TypeScript (Next.js, Express), Python (FastAPI, Flask), SQL migrations and MCP configuration receive secret scanning only.
• The known-bad package list is a small bundled sample, not a vulnerability database.
• A clean result means none of these checks matched. It is not a statement that the application is secure.

Score. Start at 100. Each issue type with open findings costs its severity weight per instance, capped at two instances: critical 15, high 8, medium 3, low 1. Findings dismissed in review cost nothing. Grade: A 90+, B 80+, C 65+, D 50+, F below 50; an open critical finding caps the grade at D and an open high finding at B.

Severity is the default for the issue type, adjusted by the evidence found (stated under each finding) and by the reviewer. Secret values are masked everywhere in this report; only the first four characters are shown.

Checks run