agentleFS
rpraharajrpraharaj/ai-engineer/skills/security-pass/SKILL.md

security-pass

Skill1 starsChanged 15 days agoMITView on GitHub

Threat-model this diff only — new reachable surface, authorization, injection, secrets, and PII. Use when the change touches auth, input, files, HTML, URLs, or secrets, when ready-to-merge dispatches a security pass, or when the user asks for a security review of the change.

5 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 1 is distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read AGENTS.md if present.

    line 14
  2. Very specific:

    Follow engineering-bar Shared procedures for scope and evidence, reusing the caller's recorded scope when provided.

    line 18
  3. Distinctive:

    If the inventory is empty, report no new reachable surface and stop (still scan the diff for leaked secrets).

    line 25
  4. Very specific:

    If the user asked you to fix fails, use implement-change (smallest fix, tests via write-tests).

    line 66

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Security pass

Adversarial review of this delta, not a company-wide audit. Do not edit product code unless the user asked you to fix what you found.

Read AGENTS.md if present. Load engineering-bar (paths in that skill) for Security + Secret files; this skill is the method for walking them.

Collect

Follow engineering-bar Shared procedures for scope and evidence, reusing the caller's recorded scope when provided. Inventory:

  • New or changed reachable surfaces (HTTP routes, RPC, jobs that consume untrusted payloads, CLI flags, UI actions)
  • Trust boundaries crossed (client → server, webhook → app, file → parser, query → HTML)
  • Authn/authz code paths
  • Secret and PII handling (logs, fixtures, client bundles, storage)

If the inventory is empty, report no new reachable surface and stop (still scan the diff for leaked secrets).

For each new or changed surface

Walk in order. A "fail" needs file:line and a one-line attack or leak.

  1. Authorization — Is the action allowed for this principal? Authn alone is a fail if this repo uses auth. IDOR: can the caller swap an id?
  2. Untrusted input — Query, path, header, body, file name, HTML, URL. Follow it to sinks: SQL/ORM, command, path join, template/HTML, redirect, deserializer, eval.
  3. Injection / traversal — Parameterized queries or the repo's equivalent. No shell string concat. No path built from user input without a jail. No HTML from user input without the repo's encoder.
  4. SSRF / outbound — User-controlled URLs must not hit internal networks unless this repo already has a checked allow-list.
  5. Uploads — Type, size, path, and execution risk (stored where the server might serve or run them).
  6. Secrets — No new secrets in source, logs, errors, or client bundles. Compare to how this repo already loads secrets.
  7. PII — New personal data is minimized, access-controlled, and not logged in full.

Skip items the diff cannot hit. Do not file theoretical issues with no path from this change.

Severity

  • bug — exploitable or a secret/PII leak
  • suggestion — missing defense this repo already uses elsewhere
  • nit — hardening with no current path

Output

## Security pass: pass | fail | unverified

### Inventory
- Surfaces:
- Boundaries:

### Findings
### Finding 1 — Severity: bug
- File: path:line
- Description:
- Suggestion:

### Secrets
pass | fail | unverified

If the user asked you to fix fails, use implement-change (smallest fix, tests via write-tests). Do not "fix" security by deleting the check or broadening authz.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.