Cloudflare security audit skill and Strix on vibe-coded apps

In October 2026, Cloudflare's open source security-audit-skill was everywhere in vibe coding circles on X, and its GitHub repo passed 41,000 stars. Strix, an open source AI pentesting agent, is the other name that keeps coming up. The pitch for both is the same: let an agent attack your code before someone else does. That is a good idea for a vibe-coded app. It is also easy to read a clean report as "my app is safe" when the tool never looked at the places vibe-coded apps usually leak.

This guide explains what each tool does, how to run it without new risks, and the gaps you still have to cover yourself. Short answer: yes, they are worth running on a vibe-coded app, but they audit what they can see. The Cloudflare skill reads source only and refuses to probe your deployed site. Strix can test a running app, but only the one you point it at, on your model budget. Neither can read a Supabase policy you clicked together in a dashboard unless you put it in the repo.

Checked on October 23, 2026 against the security-audit-skill repository (commit c1c8a8c), Cloudflare's post Build your own vulnerability harness, the Strix repository and Strix docs, and the Supabase CLI and Advisor docs linked below. We installed the Cloudflare skill with the Skills CLI into a throwaway project for both Claude Code and Cursor and ran its two bundled validator test suites (34 of 34 and 31 of 31 tests passed). We did not run a full audit or a Strix scan, because both spend paid model credits. VibeLocked is independent and not affiliated with Cloudflare, Strix, or Supabase.

The short version

1. Run the Cloudflare skill on your repo for a source review that tries to disprove its own findings. It is free to install; you pay for the model.
2. Put your database rules in the repo first. On Supabase, supabase db pull writes the remote schema into a migration file the audit can read.
3. Read the "needs validation" list, not only the confirmed findings. That is where dashboard settings and deployment facts end up.
4. Use Strix only on apps you own, ideally a staging copy with test accounts, and always with --max-budget.
5. Run more than once. Cloudflare says one run finds about half of what repeated runs find.
6. Check the deployed app from the outside too: Security Advisor in the Supabase dashboard, and a read-only scan of the live URL.
7. Treat skills like code you run. They work with your agent's permissions. Install from the official repo and read what you installed.

What Cloudflare's security-audit-skill does

It is a skill (a folder of instructions and scripts) that a coding agent such as Claude Code or Cursor loads when you ask for a security audit. Cloudflare released it with its June 18, 2026 post on building a vulnerability harness, and the README says it is the skill that seeded Cloudflare's own vulnerability discovery system. It is MIT licensed.

The README describes six phases: reconnaissance that maps architecture and trust boundaries, coverage-led hunting by isolated agents, validation where a fresh agent tries to disprove each candidate, structured output to findings.json, independent re-verification of the final records, and a report. Its best-known rule is that "the agent that checks a finding is never the agent that found it." Every result ends up as one of three verdicts: confirmed, needs_validation, or rejected, and only confirmed findings get a severity.

Things worth knowing before you run it, all from the skill's own files:

• It reads source, it does not attack your site. The skill tells the agent: "Do not probe deployed endpoints, external services, shared infrastructure, production identities, other users' data, or live control planes."
• It does not edit your code. It describes the smallest fix for each confirmed finding; you or your agent apply it afterward.
• It only runs your code in a real sandbox. It asks for an OS-enforced sandbox with no network. Without one, it keeps a lead as needs_validation instead of executing your code.
• It writes its report outside your repo by default, to ~/security-audit-skill/<repo-name>/run-<N>.
• It has run profiles: quick, standard (the default), and deep, plus an optional budget counted in agent invocations.
• It checks the obvious things too, such as hardcoded keys, committed .env or key files, and wildcard CORS, alongside deeper authorization and data isolation classes.

Install and run it

From your project folder, the README's install command is:

npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit

In our test, installing for Claude Code (-a claude-code) put the skill in .claude/skills/security-audit, installing for Cursor (-a cursor) put it in .agents/skills/security-audit, and the CLI also wrote a skills-lock.json. Run npx skills --help for the other agent options. The installed files were identical to the repository. The CLI ended with a fair warning: "Review skills before use; they run with full agent permissions." Add --global to install it for your user instead of one project.

Then open your agent in the project and ask:

security audit this codebase

A direct audit request starts the full six-phase workflow. A narrower question ("is this upload route safe?") uses guidance mode, which answers without writing report files.

What Strix does

Strix is an open source (Apache 2.0) AI pentesting tool. Its README describes "autonomous AI penetration testing agents" that run your code, find vulnerabilities, and try to prove them with working proofs of concept. Unlike the Cloudflare skill, it is built to send real traffic.

• Targets: a local folder, a GitHub repo, or a live URL, and you can pass source and a deployed URL together.
• Needs: Docker running and a model key from a supported provider, or a ChatGPT subscription sign-in, or its paid Strix Cloud.
• Scan modes: quick (minutes), standard (30 minutes to 1 hour), and deep (1 to 4 hours, depending on the target). Deep is the default.
• Spend cap: --max-budget sets a maximum model spend in US dollars for the whole scan. Without it, there is no limit, and the docs note the final spend can slightly overshoot because the check runs after each model response.
• Results: saved to strix_runs/<run-name>, and strix view opens a local dashboard.
• Permission: the README says to run it only against systems you own or have explicit written permission to test.

A detail that fits this month's news: Strix depends on LiteLLM, and its pyproject.toml now tells uv to only resolve packages that have been on the index for at least 5 days, citing the poisoned litellm 1.107.0 release of October 21, 2026. If you install Python tools that pull in LiteLLM, our AI coding tool breach guide covers who was affected and how to pin.

What audit agents cannot see in a vibe-coded app

The Cloudflare skill is honest about its blind spot. Its "respect source visibility" rule says deployment controls, provider settings, and similar facts that are not in the repository must not be assumed present or absent. They become needs_validation. For a typical vibe-coded app, a lot of the security lives exactly there.

Where the risk lives	Can a source audit see it?	How to cover it
Supabase RLS and policies created in the dashboard	Only if they are in a migration file	supabase db pull, then audit; run Security Advisor (warnings explained)
Storage bucket public or private setting	Only if it is in code or migrations	Check the bucket settings (storage bucket security)
Firebase rules deployed from the console	Only if firestore.rules in the repo matches what is deployed	Compare with the console (rules checklist)
Env vars set in your host's dashboard	No, only the names your code reads	Review the host settings and which ones are public (env vars in Cursor, Bolt and Lovable)
What the build actually ships (JS bundles, source maps, a served .env)	Partly; the deployed output can differ from the repo	Check the live site (exposed .env, .git and source maps)
Keys in old commits	The skill asks agents to look at git history, but it is not a secret scanner	Gitleaks over full history (check if an API key leaked on GitHub)

Strix closes part of this gap because it can test the running app. It still only sees the URL and accounts you give it, and a scan that stops at its budget is a partial scan.

The skill's own files do not mention Supabase or Firebase by name (we searched all 15 of them). It does hunt for row-level policy and tenant isolation mistakes in general, so give it the SQL to read.

Put your database rules where the audit can read them

If you use Supabase and built tables in the dashboard, link the project and pull the schema before you audit. Per the Supabase CLI docs, supabase db pull writes a new migration under supabase/migrations and needs Docker running:

supabase link --project-ref your-project-ref
supabase db pull

Open the new file and confirm you see enable row level security and create policy lines for your tables. If a table has no policy in that file, the audit cannot judge it, and neither can you. Once the policies are in the repo, test them in CI so a later change cannot quietly open a table.

How to run an audit agent safely

• Install from the official repo (cloudflare/security-audit-skill, usestrix/strix). Other packages called a "security audit skill" were promoted on X the same week, so check the source is the one you meant. A skill runs with your agent's permissions, the same risk as an MCP server (MCP server security).
• Give the agent no real secrets. Use a separate model key with a spend limit for audits, and never put production keys or customer data in the prompt.
• Point Strix at staging, with test accounts, not at production with real users. Its --instruction flag can pass test credentials; use throwaway accounts made for the scan.
• Set a budget every time: --max-budget for Strix, a profile and invocation budget for the Cloudflare skill.
• Review every fix. Strix can generate patches and the Cloudflare skill proposes fixes. A fix that "works" by turning off RLS or removing an auth check is a new hole. Read the diff.

How to read the report

• Start with confirmed. Each one should name the attacker, the boundary crossed, and the evidence. Reproduce it with a second test user before you fix it.
• Then read needs_validation. For a vibe-coded app this is often the most useful list: it names the dashboard settings and deployment facts the agent could not check. Check each one yourself.
• Do not treat hardening notes as bugs. The skill's design rule is that a missing extra layer is not a vulnerability if another layer already stops the attack.
• Run it again after fixes. Runs are additive: the skill reads prior ledgers and findings and targets the gaps.

Common AI-generated mistakes these audits catch, and the ones they miss

Likely to be found in source, because they are in the code:

• Service role or secret keys hardcoded in frontend files, or in NEXT_PUBLIC_ and VITE_ variables
• API routes that check for a session but not who owns the record (IDOR)
• Webhook handlers that skip signature checks
• Wildcard CORS with credentials

Easy to miss without extra steps:

• RLS turned off on a table created in the Supabase dashboard
• A using (true) policy that only exists in the live database (permissive policies)
• A public storage bucket
• Source maps or a .env file served by the deployed site
• A secret key that was set as a public env var only in the hosting dashboard

Checklist

• I installed the skill from cloudflare/security-audit-skill and read the files it added
• My Supabase schema and policies are in migration files (supabase db pull), or my Firebase rules file matches the console
• I ran a full audit and read both the confirmed and the needs validation lists
• I reproduced each confirmed finding with a second test user before fixing it
• I reviewed every proposed fix, and none of them disables RLS or removes an auth check
• I ran the audit a second time after fixing
• If I used Strix, the target was an app I own, preferably staging, with test accounts and --max-budget set
• The audit used a separate model key with a spend limit, and no production secrets were in the prompt
• I ran Supabase Security Advisor and checked the live site from the outside

Copy-paste prompt for your AI coding tool

After installing the skill, paste this into Claude Code, Cursor, or another agent that loaded it. It keeps secret values out of the output.

Security audit this codebase. This is a web app built with AI coding tools. Before hunting, list every security control this app depends on that is not visible in the repository, for example database row level security and policies, storage bucket settings, auth provider settings, and environment variables set in the hosting dashboard, and record each as needs validation with the exact fact I must check. Treat any SQL under supabase/migrations or any firestore.rules file as the intended database rules and check every table and collection the app reads or writes against them. Never print secret values; report file paths and variable names only. Do not change any files.

For a lighter check without installing anything, use the security review prompt, which has its own list of what a prompt will not do.

Check what your live app shows a stranger

A source audit and a live check answer different questions. To see what your deployed app shows anyone on the internet, run its URL through LeakCheck. It scans any live web app or public GitHub repo, read only: it looks for secret key patterns in the JavaScript your site ships, exposed files, and, for apps that use Supabase or Firebase, whether the public key can read data. It does not read your private code, and a clean result is not proof that your access rules are right, so keep the audit and the second-user test too.

Sources

• Cloudflare: security-audit-skill on GitHub (README: phases, install, usage, requirements, design principles)
• Cloudflare: security-audit-skill SKILL.md (operating modes, execution safety, source visibility, profiles)
• Cloudflare blog: Build your own vulnerability harness (June 18, 2026)
• skills.sh: cloudflare/security-audit-skill listing
• Strix on GitHub (README: targets, requirements, authorized use)
• Strix pyproject.toml (LiteLLM dependency and 5 day uv cooldown)
• Strix docs: Quick start
• Strix docs: Scan modes
• Strix docs: CLI reference (--max-budget)
• Supabase CLI: supabase db pull
• Supabase: Performance and Security Advisors
• Supabase: Row Level Security
• Firebase: Security Rules basics
• Gitleaks