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
- rmichak/claude-skillstheir own version, first seen Nov 8, 2026
- zedarvates/frugal-skillstheir own version, first seen Nov 8, 2026
- kcayme/k-agentstheir own version, first seen Nov 1, 2026
- leonvanzyl/agentic-coding-starter-kittheir own version, first seen Oct 8, 2026
- alexblag023/claude-skillstheir own version, first seen Oct 1, 2026
- dkpapadopoulos/auto-claude-skillstheir own version, first seen Sep 22, 2026
Other versions14 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 14
- leonvanzyl/agentic-coding-starter-kit★ 447same name
- glincker/claude-code-marketplace★ 37same name
- dkpapadopoulos/auto-claude-skills★ 6same name
- casedone/claude-code-security-plugins★ 4same name
- ianalloway/openclaw-skills★ 4same name
- leonvanzyl/claude-code-pro-workflow-demo★ 4same name
- mehdiozdemir/awesome-agent-skills★ 2same name
- alexblag023/claude-skills★ 1same name
- cicoccc/openclaw-security-scanner★ 1same name
- rmichak/claude-skills★ 1same name
4 more not listed
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.
In this repository13 other files it gives its agents.
- AGENTS.mdAGENTS.md
- llms.txtllms.txt
- annotateSkill
- debug-loop-breakerSkill
- deploy-checklistSkill
- goalSkill
- growth-playbookSkill
- seo-auditSkill
- svg-diagramSkill
- tdd-disciplineSkill
- teaching-modeSkill
- verify-frontend-changeSkill
- SKILL_NAMESkill
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
- Distinctive: line 8
Run when: user says "security scan", "check for secrets", "audit security", or before any deploy.
- Distinctive: line 22
Workflow: Run all three for a full scan.
- Very specific: line 46
Run: git ls-files | grep -i '\.env' — if any .env is tracked, alert immediately
- Very specific: line 47
Check for .env.example — should exist if .env is used, with placeholder values only
- Distinctive: line 67
If secrets were ever committed, they're in history even if deleted.
- Very specific: line 86
Don't assume
gitleaks/trufflehogare installed: Check with which gitleaks trufflehog before relying on either. - Distinctive: line 92
Git history leaks persist after deletion: If a secret was ever committed, git filter-branch or BFG Repo-Cleaner is needed.
- Distinctive: line 115
If zero issues found, say so clearly.
“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.
Files
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.
| Script | Purpose |
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
.envfiles 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.envis 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-verifiedscripts/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 -uIf 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/trufflehogare installed. Check withwhich gitleaks trufflehogbefore relying on either. If neither is present, install withbrew install gitleaks/brew install trufflehogfor a real content-scan of git history — otherwisescan-secrets.shdegrades gracefully to the filename-grep fallback (weaker, but it never hard-fails just because a scanner isn't onPATH). grepfor secrets has false positives.API_KEYin 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-branchor BFG Repo-Cleaner is needed. Just deleting the file doesn't remove it from history. npm auditis noisy. Many vulnerabilities are in dev dependencies or don't apply to your use case. Focus onhighandcriticalin 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.jsonin 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 dateIf zero issues found, say so clearly. Don't invent problems.
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.

