Cloudflare security audit skill: GitHub repo, install, and limits

The Cloudflare security audit skill is at github.com/cloudflare/security-audit-skill. It is an MIT-licensed skill that turns a coding agent into a source code auditor. The repository had about 55,800 stars on November 1, 2026.

Use this command to install the skill:

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

The skill audits a repository. It does not test the application that your users reach. Read the section on what the skill does not test before you trust a clean report.

Security audit skill: repository facts

The name causes one common error. The cloudflare/skills repository is a different project. That repository holds skills for building on Workers and other Cloudflare products. It does not hold this audit skill.

What does the Cloudflare security audit skill do?

The skill runs a structured audit in six phases. Different agents do different jobs, so the agent that finds a problem never confirms that problem.

The skill also holds attack guides for specific target types. There are companion files for web protocols, client-side code, cloud deployment, LLM features, data isolation, supply chain, memory safety, and desktop and mobile IPC.

The Cloudflare blog says that the original skill had about 450 lines and seven phases. The current repository describes six phases, and its SKILL.md file has 192 lines. If you read an older article that gives other numbers, this change is the probable reason.

How do I install the security audit skill?

Do these steps in this order.

1. Read the repository. Open SKILL.md and the two .cjs validators. A skill runs with the rights of your agent, so read the skill before you install it.
2. Scan the repository. Use a skill scanner. The section on vetting the skill shows the result that we got.
3. Install for one project or for all projects. Use the command at the top of this page. Add --global for a user-level install.
4. Confirm the install. Start a new agent session and ask the agent to list its skills.
5. Set up a sandbox. You need this step only if you want the skill to execute target code.

For a global install, use this command:

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

To choose the agent, add -a claude-code or -a codex. The install guide for Claude Code and the install guide for Codex give the details for each agent.

Warning: The Skills CLI collects anonymous usage data by default. Set DISABLE_TELEMETRY=1 or DO_NOT_TRACK=1 to stop this. The Skills CLI README describes these settings.

How do I run the skill?

The skill has two modes. The mode controls the time, the cost, and the files that the skill writes.

A full audit also has three profiles. The default is standard.

The profile changes the breadth of the audit. It does not change the evidence that a finding must have.

Paste one of these prompts into your agent.

Prompt 1: explain the scan before it starts.

You have the security-audit skill. Do not start the audit.
Explain the scan for this repository in plain words:
1. Which mode and profile will you use?
2. Which files and folders will you read?
3. Will you execute any code? If yes, in which sandbox?
4. Which facts can you not see from the source?
5. How many agents will the run use, approximately?
Wait for my approval.

Prompt 2: run a small audit first.

Run a full security audit of ./src with the quick profile.
Set a limit of 15 agents. Output to ~/audits/my-app.
Do not change the source code.

Prompt 3: run a focused review with no report files.

Use the security-audit skill in guidance mode.
Review the auth checks in ./src/api/orders for cross-tenant access.
Give me each lead with the file, the line, and the missing check.

Start with Prompt 1. The answer shows the plan and the limits before the agent spends your tokens.

How do I read the results?

The skill gives each record one of three verdicts. Only confirmed records have a severity.

The needs_validation file is the most important file for a deployed app. The word “unresolved” often means that the answer is in production. Treat this file as your test list.

The skill also uses strict rules for severity. A missing best practice is not a finding. If a first layer stops the attack, the absence of a second layer is a hardening note. These rules reduce noise, but they also mean that the report is short by design. A short report does not mean a safe app.

How much does a full audit cost?

Cloudflare does not publish a token cost for the skill. The cost depends on the size of the repository, your model, and the profile.

The SKILL.md file gives a way to count the work:

• One ledger unit is approximately one hunter assignment.
• One surviving candidate is one or two verifier assignments.
• Each run has four baseline reconnaissance calls, plus critic agents.

You can set a limit. If the limit cannot cover the validation work, the skill stops the hunt and marks the run as incomplete. Do not read an incomplete run as a finished audit.

The blog gives one reference point for the larger harness, not for the skill. A repository of about 30,000 lines gave 100 initial findings. A full harness run took 3 to 4 hours.

What did Cloudflare learn from running the skill?

Cloudflare used this skill as the start of a larger system. The blog post gives results for the system and the limits of the skill.

The blog names three limits of a single skill run:

1. Context. After about an hour, the context window fills and the model loses earlier work.
2. Persistence. A crash in one session loses the run.
3. Cross-repository reasoning. One repository cannot show how other software uses it.

The blog also says that a single run finds “only about half the bugs you’d catch across multiple runs.” The bugs that a single run found “skewed toward the simpler and less subtle.”

Run the skill more than once. Use the same output directory, because later runs read the earlier ledger and target the gaps.

Cloudflare also says: “We don’t claim a false-negative rate for our system.” The reason is that nobody has a list of every real bug in a codebase. Be careful with any tool that claims a detection rate on your code.

What does the skill not test?

The skill does not test your deployed application. This is a design rule. It is not a bug. The SKILL.md file says:

Do not probe deployed endpoints, external services, shared infrastructure, production identities, other users’ data, or live control planes.

This rule is correct for a tool that an agent runs on your laptop. An agent that sends requests to production can do damage. The skill also records the policy in each run as execution_policy: "sandboxed-source-and-local-only".

The skill is also clear about the facts that it cannot see:

Deployment controls, proxy behavior, provider settings, browser headers, identity policy, broker ACLs, packaging, and topology are real controls. If they are required and absent from the repository, do not assume either presence or absence.

The anti-pattern list in the same file names “Guessing provider, proxy, browser, identity, or deployment behavior not present in source.” So the skill will not guess. It records needs_validation, and the work comes back to you.

Which security facts are outside the repository?

A repository is one fragment of a running system. These facts decide if an attack works, and many of them are not in the source.

The Supabase documentation states the first risk directly: “A table in an exposed schema without RLS is readable and writable by any role with a grant on it.” Source code can show the policy that you wrote. Only the live database can show the policy that is active.

Cloudflare Workers give a second example. The workers.dev documentation says that if you disable the route in the dashboard but not in the Wrangler file, the route “will be re-enabled the next time you deploy.” The Previews documentation says: “Preview URLs are public by default.” A correct code audit cannot show these states.

How does Cloudflare solve this gap?

Cloudflare solves the gap with more context. The harness adds a stage that the open source skill does not have. The blog calls it Judgment.

The Judgment agent builds context from MCP servers “to get the shape of what the service looks like in production.” It searches “the wiki, Jira, git, config, and all available other sources.” Then it decides if the code path “is reachable in prod.”

This is the important lesson. Cloudflare owns the code, the infrastructure, and the internal documents. Its source audit still needs a separate stage for production facts. If you install only the skill, you have the source stage and you do not have the production stage.

How do I verify the findings against the live app?

Use the audit to find leads. Then use real requests to prove or disprove each lead.

Warning: Test only systems that you own or have written permission to test. Use a staging copy when you can.

1. Record the commit. Compare the audited commit with the deployed commit. If they differ, the audit does not describe production.
2. Fix the confirmed findings. Deploy the fixes.
3. Convert NEEDS-VALIDATION.md into tests. Use Prompt 4 below.
4. Create two test accounts. Most access control bugs need one account that tries to read the data of a second account.
5. Run the tests against staging. Save each response as evidence.
6. Scan the deployed app from the outside. A black-box scanner sees the same surface as an attacker.
7. Run the audit again. Use the same output directory after each large change.

Prompt 4: convert open records into a live test plan.

Read NEEDS-VALIDATION.md. Do not send any network requests.
For each record, write:
1. The exact fact that is unresolved.
2. The place where that fact lives (database, host, CDN, or identity provider).
3. One safe test that I can run on my staging URL.
4. The response that proves the problem, and the response that disproves it.
Use two test accounts, A and B. Do not use real user data.

VibeEval does the outside step. It tests the deployed URL without source code, and each finding includes the actual response. It cannot see code paths that are not reachable from the outside, so it does not replace a source audit. The two methods cover different parts of the system. The guide on the layer between SAST and a pentest compares the options.

Should I vet the skill before I install it?

Yes, for every skill. Popular skills are not an exception. The OWASP Agentic Skills project reports that five of the top seven most-downloaded ClawHub skills were confirmed malware at the peak of one campaign.

We ran Skillisus on this repository at commit c1c8a8c. Skillisus is a static scanner for skills. Disclosure: Skillisus and VibeEval have the same author.

skillisus -min low cloudflare/security-audit-skill

All seven matches had a benign reason. A security skill must talk about attacks, so the words match the rules. This result shows the correct way to use a scanner: the scanner tells you which lines to read, and you make the decision.

Static scanners also have a hard limit. The guide on security skills on GitHub shows a test where a plain-English instruction passed Skillisus with zero findings. Read the SKILL.md file yourself.

What is the correct order for a security audit?

Use each tool for the question that it can answer.

1. Vet the skill. Use a scanner, then read the files.
2. Audit the source. Use the Cloudflare skill. Run it more than once.
3. Check the production facts. Work through NEEDS-VALIDATION.md.
4. Test the live app. Use real requests from outside, with two accounts.
5. Repeat after each large change. An audit describes one commit on one day.

A confirmed source finding is proof of a defect in code. A response from your live app is proof of what an attacker gets. You need both.