agentleFS
jazzpujols34jazzpujols34/claude-skills/skills/security-scanner/SKILL.md

security-scanner

Skill0 starsChanged 5 months agoMITView on GitHub

Use before any production deploy or when asked to audit security. Scans for hardcoded secrets, .env exposure, git history leaks, dependency vulnerabilities, and OWASP issues. Trigger on "security scan", "check for secrets", "audit security".

  • Reads credentials
  • Installs packages

14 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 5 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 11 edited versions we read keep these.

  • 5

    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. Distinctive:

    Run when: user says "security scan", "check for secrets", "audit security", or before any deploy.

    line 8
  2. Distinctive:

    Workflow: Run all three for a full scan.

    line 22
  3. Very specific:

    Run: git ls-files | grep -i '\.env' — if any .env is tracked, alert immediately

    line 46
  4. Very specific:

    Check for .env.example — should exist if .env is used, with placeholder values only

    line 47
  5. Distinctive:

    If secrets were ever committed, they're in history even if deleted.

    line 67
  6. Very specific:

    Don't assume gitleaks/trufflehog are installed: Check with which gitleaks trufflehog before relying on either.

    line 86
  7. Distinctive:

    Git history leaks persist after deletion: If a secret was ever committed, git filter-branch or BFG Repo-Cleaner is needed.

    line 92
  8. Distinctive:

    If zero issues found, say so clearly.

    line 115

“Common” is measured: kept by at least 6 in 10 of the 11 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 Scanner

Run when: user says "security scan", "check for secrets", "audit security", or before any deploy.

Scripts

This skill ships three executable scripts. Each takes an optional [project-dir] argument and defaults to the current directory, so they run standalone from any checkout.

ScriptPurpose
scripts/scan-secrets.sh [dir]Hardcoded secrets, tracked .env, credential JSONs, git history leaks
scripts/scan-deps.sh [dir]npm audit + pip-audit for dependency vulnerabilities
scripts/scan-owasp.sh [dir]SQL injection patterns, CORS wildcards, eval/exec, route auth

Workflow: Run all three for a full scan. From the skill folder, pointing at the project you want to audit:

bash scripts/scan-secrets.sh ./path/to/project
bash scripts/scan-deps.sh ./path/to/project
bash scripts/scan-owasp.sh ./path/to/project

(Or omit the argument to scan the current directory.)

Scan checklist

1. Secrets in code

# Search for hardcoded keys, tokens, passwords
grep -rn --include="*.{ts,tsx,js,jsx,py,json,yaml,yml,toml,sh}" \
  -E "(api[_-]?key|secret|password|token|credential|private[_-]?key)\s*[:=]\s*['\"][^'\"]{8,}" . \
  --exclude-dir={node_modules,.git,venv,.next,dist,build}

Flag anything that isn't a placeholder or env var reference.

2. .env exposure

  • .env files must be in .gitignore
  • Run: git ls-files | grep -i '\.env' — if any .env is tracked, alert immediately
  • Check for .env.example — should exist if .env is used, with placeholder values only

3. Git history leaks

Prefer a real secret-scanner over grep — a filename/pattern grep pass is slow on real repos and misses the common secret shapes (sk-..., AKIA..., JWTs, base64 blobs, .env diffs), which gives false confidence:

gitleaks detect --source . -v
# or
trufflehog git file://. --only-verified

scripts/scan-secrets.sh auto-detects whether gitleaks/trufflehog are on PATH and uses whichever is available; if neither is installed it falls back to the grep-based added-filename check below (weaker — it only catches files whose name looks sensitive, not secret content committed under an innocuous filename).

Fallback (no scanner installed):

git log --all --diff-filter=A --name-only --pretty=format: | grep -i 'env\|secret\|key\|credential' | sort -u

If secrets were ever committed, they're in history even if deleted.

4. Dependency vulnerabilities

  • JS projects: npm audit --json 2>/dev/null | head -50
  • Python projects: pip audit 2>/dev/null || echo "pip-audit not installed"

5. OWASP quick check

  • Injection: Any raw SQL queries or string interpolation in queries?
  • Auth: Are auth tokens validated on every protected route?
  • CORS: Is CORS configured with specific origins (not * in production)?
  • Headers: Security headers set? (CSP, X-Frame-Options, etc.)

6. Infrastructure

  • Serverless / container services: service account has minimum permissions?
  • Hosting platform: environment vars set in the dashboard, not in code?
  • No --allow-unauthenticated (or equivalent public flag) on internal services?

Gotchas

  • Don't assume gitleaks/trufflehog are installed. Check with which gitleaks trufflehog before relying on either. If neither is present, install with brew install gitleaks / brew install trufflehog for a real content-scan of git history — otherwise scan-secrets.sh degrades gracefully to the filename-grep fallback (weaker, but it never hard-fails just because a scanner isn't on PATH).
  • grep for secrets has false positives. API_KEY in a TypeScript interface definition is not a leak. Check context before flagging.
  • Git history leaks persist after deletion. If a secret was ever committed, git filter-branch or BFG Repo-Cleaner is needed. Just deleting the file doesn't remove it from history.
  • npm audit is noisy. Many vulnerabilities are in dev dependencies or don't apply to your use case. Focus on high and critical in production dependencies.
  • CORS * in development is fine. Only flag it if it's in production config or there's no env-based override.
  • Service account JSON files in repos are the most common real leak. Always check for serviceAccount.json, credentials.json, key.json in tracked files.

Output format

## Security Scan: [project name]
Date: YYYY-MM-DD

### Critical (fix before deploy)
- [ ] ...

### Warning (fix soon)
- [ ] ...

### Clean
- [x] No hardcoded secrets
- [x] .env not tracked
- [x] Dependencies up to date

If zero issues found, say so clearly. Don't invent problems.

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.