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)
tools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.