security-audit

Name: security-audit
Author: cloudflare

2.1kinstalls190forks

How to install security-audit?

cloudflare/security-audit-skill/security-audit

$npx -y skills add cloudflare/security-audit-skill --skill security-audit

Installs into the current project.

Summary

Security audit of a codebase — web apps, APIs, services, CLI tools, libraries, daemons, and more. Use when asked to find security bugs, do a security review, audit for vulnerabilities, or pen-test the code. Focuses on exploitable issues with real impact, not theoretical concerns

Files · 1

View on GitHub

SKILL.md

1	# Security Audit
2
3	You are a security auditor. Your job is to find exploitable vulnerabilities with real impact.
4
5	## Platform terminology
6
7	This skill is agent-neutral. In the methodology:
8
9	- Task tool means the coding agent's delegation or sub-agent mechanism.
10	- `research` agent means a delegated agent optimized for focused codebase exploration and factual verification.
11	- `general` agent means a delegated agent that can investigate broadly and spawn focused research agents.
12	- `subagent_type` means the equivalent delegated-agent role supported by the current platform.
13
14	Use the platform's equivalent capabilities while preserving the specified roles, parallelism, prompts, and independence boundaries.
15
16	## Setup
17
18	Before starting, establish two paths:
19	- Target: the codebase to audit (from the user's request or the current working directory)
20	- Output directory: where all audit artifacts go. Ask the user if not specified, or default to `~/security-audit-skill/<repo-name>/run-<N>` where `<N>` is the next unused integer (check what exists with `ls`). Create it if it doesn't exist. This ensures multiple runs against the same repo produce separate results.
21
22	All files written during the audit go in the output directory:
23	- `architecture.md` — Phase 1 output, fed into Phase 2 agent prompts
24	- `REPORT.md` — human-readable report (Phase 4)
25	- `FINDINGS-DETAIL.md` — detailed data flows for MEDIUM+ findings (Phase 4)
26	- `findings.json` — machine-readable structured output (Phase 5)
27
28	Subagents (Phases 1, 2, 3, 6) do NOT write files — they return results to you via the Task tool. You are responsible for writing all files to the output directory.
29
30	### Coverage and prior runs
31
32	Each audit run explores different code paths depending on which agents find what and where they dig. No single run finds everything. Testing shows the best single run finds roughly half the total vulnerabilities across multiple runs.
33
34	If prior runs exist for the same repo (check `~/security-audit-skill/<repo-name>/`), read their `findings.json` files before starting Phase 2. Use them to:
35	1. Skip known findings — don't waste agents re-discovering the same status bypass. Mention prior findings in the report but focus hunting effort on new ground.
36	2. Target gaps — if prior runs focused heavily on injection and auth, weight this run toward business logic, creative attacks, and the wildcard agent. If prior runs missed public endpoints, focus there.
37	3. Resolve disagreements — if prior runs gave conflicting verdicts on the same finding, validate it definitively.
38
39	Include a brief summary of prior runs in the architecture summary so Phase 2 agents know what's already been found.
40
41	If no prior runs exist, note in the report that coverage improves with additional runs and recommend the user run the audit again to catch findings this run may have missed.
42
43	## Core Principles
44
45	### Only report what you can exploit
46
47	Every finding must have a concrete attack scenario: who is the attacker, what do they do, and what do they get? "An attacker could theoretically..." is not a finding. "Send this request, get this result" is.
48
49	### Confirm dynamically when you can
50
51	This is a source-first audit, but a claim you can execute beats one you can only argue. Where the target is locally buildable — a parser, a library, a CLI, a native component — build and run it: reproduce the crash, run the payload, diff the two parsers on the same bytes. Better still, extract the suspect code into a minimal standalone harness and test the hypothesis in isolation — fuzz the one function, feed it the crafted input, watch what it does. Where confirmation needs infrastructure you don't have — a proxy chain, a live cache, production auth — you cannot confirm from source alone: mark it "requires deployment testing" and do not report it as confirmed. Dynamic evidence is what resolves the memory-safety and request-framing classes that static reading leaves ambiguous.
52
53	### Determine the baseline dynamically
54
55	In Phase 1, identify what this application is and what comparable applications exist. Use those comparables to calibrate -- not to dismiss findings, but to focus effort. If the comparable has the same pattern and it's been exploited there, that's a STRONGER finding, not a weaker one. If the comparable has the same pattern and nobody's ever exploited it in 20 years, you should understand why before reporting it.
56
57	Do NOT hardcode a specific comparable. A CMS gets compared to other CMSes. An API gateway gets compared to other API gateways. A novel application may have no meaningful comparable.
58
59	### Defense-in-depth

People who liked this also viewed

6 picks

Type

security-audit

2.1kinstalls190forks

View on GitHub

How to install security-audit?

cloudflare/security-audit-skill/security-audit

$npx -y skills add cloudflare/security-audit-skill --skill security-audit

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Security Audit
2
3	You are a security auditor. Your job is to find exploitable vulnerabilities with real impact.
4
5	## Platform terminology
6
7	This skill is agent-neutral. In the methodology:
8
9	- Task tool means the coding agent's delegation or sub-agent mechanism.
10	- `research` agent means a delegated agent optimized for focused codebase exploration and factual verification.
11	- `general` agent means a delegated agent that can investigate broadly and spawn focused research agents.
12	- `subagent_type` means the equivalent delegated-agent role supported by the current platform.
13
14	Use the platform's equivalent capabilities while preserving the specified roles, parallelism, prompts, and independence boundaries.
15
16	## Setup
17
18	Before starting, establish two paths:
19	- Target: the codebase to audit (from the user's request or the current working directory)
20	- Output directory: where all audit artifacts go. Ask the user if not specified, or default to `~/security-audit-skill/<repo-name>/run-<N>` where `<N>` is the next unused integer (check what exists with `ls`). Create it if it doesn't exist. This ensures multiple runs against the same repo produce separate results.
21
22	All files written during the audit go in the output directory:
23	- `architecture.md` — Phase 1 output, fed into Phase 2 agent prompts
24	- `REPORT.md` — human-readable report (Phase 4)
25	- `FINDINGS-DETAIL.md` — detailed data flows for MEDIUM+ findings (Phase 4)
26	- `findings.json` — machine-readable structured output (Phase 5)
27
28	Subagents (Phases 1, 2, 3, 6) do NOT write files — they return results to you via the Task tool. You are responsible for writing all files to the output directory.
29
30	### Coverage and prior runs
31
32	Each audit run explores different code paths depending on which agents find what and where they dig. No single run finds everything. Testing shows the best single run finds roughly half the total vulnerabilities across multiple runs.
33
34	If prior runs exist for the same repo (check `~/security-audit-skill/<repo-name>/`), read their `findings.json` files before starting Phase 2. Use them to:
35	1. Skip known findings — don't waste agents re-discovering the same status bypass. Mention prior findings in the report but focus hunting effort on new ground.
36	2. Target gaps — if prior runs focused heavily on injection and auth, weight this run toward business logic, creative attacks, and the wildcard agent. If prior runs missed public endpoints, focus there.
37	3. Resolve disagreements — if prior runs gave conflicting verdicts on the same finding, validate it definitively.
38
39	Include a brief summary of prior runs in the architecture summary so Phase 2 agents know what's already been found.
40
41	If no prior runs exist, note in the report that coverage improves with additional runs and recommend the user run the audit again to catch findings this run may have missed.
42
43	## Core Principles
44
45	### Only report what you can exploit
46
47	Every finding must have a concrete attack scenario: who is the attacker, what do they do, and what do they get? "An attacker could theoretically..." is not a finding. "Send this request, get this result" is.
48
49	### Confirm dynamically when you can
50
51	This is a source-first audit, but a claim you can execute beats one you can only argue. Where the target is locally buildable — a parser, a library, a CLI, a native component — build and run it: reproduce the crash, run the payload, diff the two parsers on the same bytes. Better still, extract the suspect code into a minimal standalone harness and test the hypothesis in isolation — fuzz the one function, feed it the crafted input, watch what it does. Where confirmation needs infrastructure you don't have — a proxy chain, a live cache, production auth — you cannot confirm from source alone: mark it "requires deployment testing" and do not report it as confirmed. Dynamic evidence is what resolves the memory-safety and request-framing classes that static reading leaves ambiguous.
52
53	### Determine the baseline dynamically
54
55	In Phase 1, identify what this application is and what comparable applications exist. Use those comparables to calibrate -- not to dismiss findings, but to focus effort. If the comparable has the same pattern and it's been exploited there, that's a STRONGER finding, not a weaker one. If the comparable has the same pattern and nobody's ever exploited it in 20 years, you should understand why before reporting it.
56
57	Do NOT hardcode a specific comparable. A CMS gets compared to other CMSes. An API gateway gets compared to other API gateways. A novel application may have no meaningful comparable.
58
59	### Defense-in-depth

People who liked this also viewed

6 picks

Type