Security Scanner Skill

Description

# Security Scanner Skill Use this skill when the user asks to scan a code repository, package, diff, dependency list, CI output, or configuration bundle for security risks. It is designed for defensive review only and must not be used to exploit, weaponize, or bypass systems. ## What To Scan Prioritize these risk classes: - Exposed secrets: API keys, tokens, private keys, passwords, webhook secrets, cloud credentials, database URLs, JWT signing keys, and seed phrases. - Vulnerable dependencies: known-CVE packages, abandoned packages, suspicious typosquats, risky postinstall scripts, and outdated security-critical libraries. - Risky code patterns: command injection, SQL injection, path traversal, unsafe deserialization, SSRF, XSS sinks, weak crypto, insecure random generation, hardcoded admin bypasses, excessive permissions, and missing auth checks. - Configuration issues: public storage buckets, permissive CORS, debug flags in production, plaintext secrets in CI, overly broad IAM policies, missing security headers, and unpinned container images. ## Workflow 1. Establish scope. Identify the files, package managers, language, framework, deployment surface, and whether the user provided a diff or full repo. 2. Refuse unsafe requests. Do not help exploit targets, steal credentials, bypass auth, persist malware, or hide activity. Offer a defensive review instead. 3. Inventory likely sensitive files. Check env examples, CI files, package manifests, lockfiles, Dockerfiles, infrastructure manifests, auth middleware, API routes, database access, and upload/download handlers. 4. Search for secrets with conservative patterns. Treat matches as sensitive; do not print full secret values. Show only prefixes/suffixes when necessary, for example sk_live_...abcd. 5. Review dependencies. Use available local tools such as npm audit, pnpm audit, pip-audit, osv-scanner, cargo audit, or language-native lockfile inspection when present. If tools are unavailable, explain the limitation and inspect manifests manually. 6. Review code paths. Trace user-controlled input to file system, shell, database, HTTP client, template rendering, auth decisions, and serialization boundaries. 7. Rate severity. Use Critical, High, Medium, Low, or Info. Tie severity to exploitability, impact, exposure, and compensating controls. 8. Provide fixes. For every Critical, High, and Medium finding, include a minimal remediation and a verification step. ## Output Format Return a concise report: ### Summary - Overall risk: Critical | High | Medium | Low - Scope reviewed - Tools used or unavailable - Highest-priority fix ### Findings For each finding: - Severity - Title - Evidence location - Why it matters - Recommended fix - Verification step ### Secret Handling Never reveal complete secrets. If a secret is found, redact it and recommend immediate rotation plus history cleanup if committed. ### Residual Risk List unreviewed areas, missing context, skipped tools, or files excluded by scope. ## Quality Bar Be specific and actionable. Avoid vague warnings like "sanitize input" without naming the vulnerable input, sink, and exact fix. Prefer small patches and verification commands when the user has granted code-edit permission.

Security Status