skills/security-auditor/SKILL.md
Security vulnerability scanner and OWASP compliance auditor for codebases. Dependency scanning (npm audit, pip-audit), secret detection (high-entropy strings, API keys), SAST for injection/XSS vulnerabilities, and security posture reports. Activate on 'security audit', 'vulnerability scan', 'OWASP', 'secret detection', 'dependency check', 'CVE', 'security review', 'penetration testing prep'. NOT for runtime WAF configuration (use infrastructure tools), network security/firewalls, or compliance certifications like SOC2/HIPAA (legal/organizational).
npx skillsauth add curiositech/windags-skills security-auditorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Comprehensive security scanning for codebases. Identifies vulnerabilities before they become incidents. Focuses on actionable findings with remediation guidance.
Use for:
Do NOT use for:
# Run comprehensive scan
./scripts/full-audit.sh /path/to/project
# Output: security-report.json + summary
# Dependency vulnerabilities only
npm audit --json > deps-audit.json
# Secret detection only
./scripts/detect-secrets.sh /path/to/project
# OWASP check specific file
./scripts/owasp-check.py /path/to/file.js
| Package Manager | Command | Severity Levels |
|-----------------|---------|-----------------|
| npm | npm audit --json | critical, high, moderate, low |
| yarn | yarn audit --json | same as npm |
| pip | pip-audit --format json | critical, high, medium, low |
| cargo | cargo audit --json | same |
Decision Tree:
Critical severity found?
├── YES → Block deployment, immediate fix required
│ └── Check if patch available → npm audit fix --force
├── NO → High severity?
├── YES → Fix within sprint, document if deferred
└── NO → Low/Moderate → Track, fix during maintenance
High-Risk Patterns:
/[A-Za-z0-9_]{20,}/ near "key", "api", "secret"AKIA[0-9A-Z]{16}-----BEGIN (RSA|EC|OPENSSH) PRIVATE KEY-----eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+://[^:]+:[^@]+@Entropy Analysis:
False Positive Handling:
Secret-like pattern found?
├── In test file? → Lower severity, document
├── In example/docs? → Check if placeholder
├── High entropy + near "password"/"secret" → High confidence
└── In .env.example? → Acceptable if placeholder values
| # | Vulnerability | Detection Pattern | |---|---------------|-------------------| | A01 | Broken Access Control | Missing auth checks on routes | | A02 | Cryptographic Failures | Weak algorithms (MD5, SHA1 for passwords) | | A03 | Injection | Unparameterized queries, eval(), innerHTML | | A04 | Insecure Design | Hardcoded credentials, missing rate limits | | A05 | Security Misconfiguration | Debug mode in prod, default credentials | | A06 | Vulnerable Components | Known CVEs in dependencies | | A07 | Auth Failures | Weak password policies, session issues | | A08 | Integrity Failures | Unsigned updates, untrusted deserialization | | A09 | Logging Failures | Sensitive data in logs, missing audit trails | | A10 | SSRF | Unvalidated URL inputs to fetch/request |
JavaScript/TypeScript:
eval(), new Function() - code injectioninnerHTML, outerHTML - XSS vectorsdocument.write() - DOM-based XSSchild_process.exec() with user input - command injectionPython:
pickle.loads() with untrusted data - arbitrary code executionyaml.load() without Loader=SafeLoader - code injectionsubprocess.shell=True - command injectioneval(), exec() - code injectionSQL:
LIKE '%' + input + '%' - injection via wildcardsWhat it looks like: "Nobody will find this hardcoded password" Why wrong: Secrets in source always leak eventually Instead: Environment variables, secret managers, zero hardcoded secrets
What it looks like: 500 findings, all "medium", team ignores Why wrong: Critical issues buried in noise Instead: Prioritize by exploitability, start with critical/high only
What it looks like: npm audit fix --force without review
Why wrong: May introduce breaking changes, doesn't address root cause
Instead: Review each fix, understand the vulnerability, test after
What it looks like: "We did a security audit last year" Why wrong: New CVEs daily, code changes constantly Instead: CI/CD integration, weekly automated scans minimum
{
"summary": {
"critical": 0,
"high": 2,
"medium": 5,
"low": 12,
"informational": 8
},
"findings": [
{
"id": "SEC-001",
"severity": "high",
"category": "A03:Injection",
"title": "SQL Injection in user search",
"location": "src/api/users.js:45",
"description": "User input concatenated directly into SQL query",
"evidence": "const query = `SELECT * FROM users WHERE name = '${input}'`",
"remediation": "Use parameterized queries: db.query('SELECT * FROM users WHERE name = $1', [input])",
"references": ["https://owasp.org/www-community/attacks/SQL_Injection"]
}
],
"recommendations": [
"Implement parameterized queries across all database access",
"Add input validation layer",
"Enable SQL query logging for monitoring"
]
}
security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run security audit
run: |
npm audit --json > audit.json
./scripts/detect-secrets.sh . > secrets.json
./scripts/generate-report.py
- name: Fail on critical
run: |
if jq '.summary.critical > 0' report.json; then
echo "Critical vulnerabilities found!"
exit 1
fi
scripts/ folder)| Script | Purpose |
|--------|---------|
| full-audit.sh | Comprehensive security scan |
| detect-secrets.sh | High-entropy string and pattern detection |
| owasp-check.py | OWASP Top 10 static analysis |
| generate-report.py | Combine findings into unified report |
| Novice | Expert | |--------|--------| | Runs audit once before release | CI/CD integration, every commit | | Focuses on tool output only | Understands vulnerability context | | Fixes everything or nothing | Triages by exploitability | | Uses one scanner | Layers multiple tools | | Ignores false positives | Tunes detection rules |
| Metric | Target | |--------|--------| | Critical/High pre-production | 0 | | Mean time to remediate critical | < 24 hours | | False positive rate | < 10% | | Scan coverage | 100% of deployable code |
references/owasp-top-10-2024.md - Detailed OWASP guidancereferences/secret-patterns.md - Comprehensive regex patternsreferences/remediation-playbook.md - Fix guidance by vulnerability typereferences/ci-cd-templates.md - Integration examplesscripts/ - Working security scanning scriptsDetects: Dependency CVEs | Secret leaks | Injection vulnerabilities | OWASP violations | Security misconfigurations
Use with: site-reliability-engineer (deployment gates) | code-review (PR security checks)
data-ai
license: Apache-2.0 NOT for unrelated tasks outside this domain.
development
Use when designing caching strategies (cache-aside, write-through, write-behind), implementing distributed locks, building rate limiters, leaderboards, real-time streams (XADD/consumer groups), pub/sub, or tuning eviction policies. Triggers: thundering-herd on cache miss, dogpile on key expiry, Redlock vs SET-NX-PX choice, sliding-window rate limiter, hot-key on a single cluster slot, big-key blowup, MULTI/EXEC across slots, KEYS in production. NOT for Redis Cluster operations/admin (different domain), embedded KV (SQLite, leveldb), in-process LRU caches, or Memcached.
tools
Drawing the `'use client'` boundary correctly in React Server Components apps (Next.js App Router, RSC frameworks) — leaf-pushing, slot composition, serialization rules, and environment poisoning prevention. Grounded in react.dev and Next.js 16 docs.
development
Use when designing rate limiting for an API, choosing between token bucket / sliding window / leaky bucket / fixed window, implementing it in Redis, deciding edge (Cloudflare/Upstash) vs origin enforcement, sizing per-user vs per-IP vs per-endpoint quotas, returning the right 429 response with Retry-After, or fixing the boundary-burst bug in fixed-window limiters. Triggers: 429 too many requests, INCR + EXPIRE, ZADD + ZREMRANGEBYSCORE + ZCARD, X-RateLimit-Remaining header, Cloudflare WAF rate limiting rules, Upstash @upstash/ratelimit, leaky bucket shaping vs policing, distributed rate limiter consistency. NOT for DDoS mitigation specifically (different scale), CAPTCHA / bot management, full WAF design, or per-user quota billing.