security-conventions
Skill0 starsChanged 5 months agoMITView on GitHub
Security review conventions, standards checklists, scanner commands, and the live-probe authorization gate for the sentinel personas. Use when performing any security review, vulnerability assessment, OWASP/CEH audit, secrets/dependency scan, or browser-driven DAST.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- fpindej/netrocktheir own version, first seen Oct 8, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- fpindej/netrock★ 234same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 30
Read-only always: Never edit files. Never print secret *values* — report locations and redact tokens.
- Distinctive: line 32
Never silently skip a gate: if a scanner isn't installed, say so and print the install command (scanners.md).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Security conventions
The shared brain for the sentinel security personas. Don't review from memory — detect the target and stack, then read the topic file(s) you need.
1. Detect the target type
| Target | Signal | Network? |
| diff | reviewing git diff / unpushed commits | no |
| project | whole repo / a subtree | no |
| url | an http(s):// target | yes — gated |
| api | one endpoint URL or one OpenAPI operation | yes if live — gated |
| apis | a whole OpenAPI doc or the route table | yes if live — gated |
Any live/active probing requires the authorization gate — read authorization.md and enforce it before the first byte leaves the machine. Code-only scopes (diff/project, and the static half of api/apis) never touch the network.
2. Detect the stack
Reuse the signals from squad:stack-conventions when that skill is installed (load it). Otherwise: package.json (TS/Vue/Nest/Node), go.mod (Go), composer.json (PHP), requirements.txt/pyproject.toml (Python), plus framework route markers. The stack picks which scanners and which language taint patterns apply.
3. Signal discipline (applies to every persona)
- Report only findings with a concrete exploit path and confidence ≥ High in the main report. Park lower-confidence items in a clearly-labeled "Informational / low-confidence" appendix, and only if useful.
- Each finding: severity (Critical/High/Medium/Low) + CVSS v3.1 where it makes sense,
file:lineor the HTTP request/response evidence, the attack path, a concrete fix, and the standard tag (OWASP/API/LLM/CWE). - Read-only always. Never edit files. Never print secret values — report locations and redact tokens.
- Dedupe across personas, the built-in
/security-review, and the passivesecurity-guidanceplugin so the user sees one ranked list. - Never silently skip a gate: if a scanner isn't installed, say so and print the install command (scanners.md).
4. Topic files
- authorization.md — the hard gate for any live/active probe (read before url/api/apis/site).
- dast-browser.md — Acunetix-style browser-driven AI DAST via the Playwright MCP + the active-test catalog.
- site-scan.md — whole-site deep crawl (sitemap/BFS/auth/dedup/caps + coverage map) for the
sitescope. - scanners.md — every CLI scanner: purpose, invocation, install guard.
- owasp.md — OWASP Top 10 (2021/2025) + API Top 10 (2023) + LLM Top 10 (2025) checklists.
- ceh.md — EC-Council methodology phases + attack-tree format.
- stride.md — STRIDE architectural threat modeling (DFD + trust boundaries + threat table).
- whitebox.md — source-review / SAST patterns per stack (injection, RCE, authz/IDOR, secrets, headers, JWT, AI prompt-injection, misconfig).
- api-testing.md — OpenAPI parsing, per-operation authz, token redaction,
postman:securityhandoff.
5. Compose, don't reinvent
- Built-in
/security-review— run as a deterministic second gate on diff/project. security-guidanceplugin — passive, always-on; don't re-flag what it already surfaced this session; honor a repo'sclaude-security-guidance.mdpolicy file if present.squad:security-owasp— prefer it for the OWASP lens when thesquadplugin is installed; the localowasp-revieweris the self-contained fallback.postman:security— OWASP API Top 10 audit when a Postman collection / OpenAPI spec exists.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.