Security

Security looks for anything that could expose someone's data, money or account: keys and passwords in the code, packages with known vulnerabilities, a database open to any visitor, a route that lets one user see another user's data.

Two layers

Both layers run on your computer. Only the results go to the dashboard, with the code excerpt masked. See What leaves your computer.

What the non-AI check looks for

• Keys and passwords written in the code, a .env committed to git and secrets in variables that ship to the browser.
• Packages with known vulnerabilities. Faundr reads your project's package lists (everything from npm, pnpm, yarn and bun to Python, Rust, Go, PHP, Flutter, Ruby, .NET, Java, Kotlin, and C/C++ with Conan) and queries the public OSV.dev database. Only package names and versions are sent there.
• Database: in your Supabase migrations, tables without RLS (the rule that decides who can read each row), policies that allow everything and public storage buckets.
• Code and configuration: routes with no rate limit, security headers, Firebase rules, a local .env pointing at the cloud database.
• Git history: keys that were removed from the code but are still in the history.

A noise filter downgrades or hides findings that aren't a real risk (an example key in a test, a package only used in development) and always tells you why.

Supported languages

The non-AI check works without installing anything:

• Code: JavaScript and TypeScript (including React Native, Vue, Angular, Svelte and Astro), Python, Flutter and Dart, PHP, Go, Java, Kotlin, C#, Rust, C, C++, Dockerfiles and HTML.
• Keys and passwords: any text file in the project, in any language.
• Packages: every language above except Docker images, which have no public vulnerability database. For C and C++, only with Conan.

The full table is in Supported languages.

What the AI review does

The agent walks through every entry point into your app (routes, server functions, database rules, CI) and asks the same questions about each one. Who can call it? Do they own the data? What comes in? Is there a limit? What goes out? Then it checks whether deleting, removing someone from the team, invites and exports follow the same rules, and whether every key, role and function has only the power it needs (least privilege). It checks that important actions are logged. It also looks at MFA (and whether it can be skipped) and highly sensitive data stored without encryption. If the project uses Supabase, it runs Supabase's own Security Advisor too. From the second review on, it starts with what changed since the last one.

In a full review, two more agents read the project in parallel. One works through a checklist of the obvious (a key in the code, an open debug route, .env in git). The other hunts for what the usual categories miss: odd code, half-finished features, a check removed in the history. At the end, a third agent points out what was left uncovered, and those gaps get reviewed too.

Every suspicion ends up confirmed, dismissed (with the control that prevents it) or needs check. Before it reaches the dashboard, every confirmed issue goes through an independent verifier: another agent that never saw the reasoning rereads the code and tries to knock the finding down. In a quick review, only high and critical findings get verified. Only what survives is logged, with what could happen and how to fix it. Nothing gets fixed unless you ask.

The verifier, the "needs check" status and the extra passes are based on Cloudflare's security-audit-skill.

The status card

It shows how many serious issues are open, when the last check ran and how much it covered (files, packages, tables), the counters (Critical and high, Open, Fixed) and a line for the last AI review. The buttons:

• Export report downloads a Markdown report you can show a co-founder, paste into an AI or turn into a ticket;
• Check now copies /faundr:security-scan.

Tabs

Issues

The S-n findings. Filter by source (Keys and passwords, Packages, Database, and also Git history, Code, Configuration and AI review when there are any), by status (Open, Fixed, Ignored) and with Show suppressed to see what the noise filter hid.

Severity shows up as the intensity of the tag: Critical, High, Medium, Low.

The detail view explains What it is, What could happen and How to fix, with the file, line and masked excerpt. For a package, it shows the version that fixes it and where the package comes from. When available, it includes the public vulnerability ID (CVE) and a link to the advisory. The buttons:

• Fix with AI (/faundr:security-fix S-n);
• Ignore, with a reason (Not an issue (false positive) or Accept the risk for now) and a duration (7, 30 or 90 days). When the time runs out, the issue comes back.

Needs check

Suspicions from the AI review where the path is in the code but the deciding factor isn't: a setting in the Supabase dashboard, a production variable, a provider rule. They don't count toward your issue total until someone checks them. Each one says what's still unknown and how to check (where to click, what to look for), and shows the severity if confirmed.

The Check with AI button copies /faundr:security S-n. The agent checks what was missing, through the Supabase MCP or by asking you what you see on screen. It then turns the suspicion into a real issue, or ignores it as "not an issue" and names the control it found.

Packages

Vulnerable packages, grouped by the action that fixes them: "Updating to version X fixes N issues". When a package came in through another one (you didn't install it directly), the detail view explains where it comes from and how to fix it.

Fixing

/faundr:security-fix fixes one issue, or every serious one if you don't name one:

• A key in the code moves to .env. The agent also explains how to rotate the key with the provider, because the old one is still in your git history.
• A vulnerable package is updated in the safest order. Big version jumps only happen with your OK.
• An open database gets a new migration with RLS and ownership rules.
• Code gets the smallest fix that works.

An issue only closes once the check stops finding it. Marking it resolved by hand doesn't work for automated findings.

Other tools

If your team already uses another security tool, you can bring its results into the same dashboard with !faundr security-import <file>. It works with Snyk, any tool that outputs SARIF (Semgrep, CodeQL, Gitleaks, Trivy…) and the Supabase Security Advisor. Each tool only closes its own findings.

Findings from your own skills

If you already use a security skill that isn't Faundr's (for audits, pentesting, secrets…), you can connect it to the dashboard with /faundr:skills. Every time it runs, the agent records what it found at the end of the response:

• each issue becomes an S-n here, tagged via /name, and counts toward Launch and Insights like any other;
• when the skill runs again and the issue is gone, it closes on its own;
• each skill only closes its own findings, and only in the files it looked at.

See how to connect one in Workflows.

The database test

The database test as a visitor lives in Launch and privacy. Every open door it finds becomes an S-n here.

Commands