security-review
SolidExploitability-first standalone security review of code changes, diffs, PRs, or services. Use when asked for a security review, security audit, vulnerability assessment, or pre-merge security check (安全审查/安全评审/漏洞排查) — covers auth, input, secrets, API, data, concurrency, container, third-party, and dependency risk across Go, Node.js/TypeScript, Java, and Python, with mandatory evidence, false-positive suppression, scope-based depth (Lite/Standard/Deep), and CWE/OWASP-mapped machine-readable output. NOT for general-purpose Go code review — use go-review-lead for that (it dispatches go-security-review as its security dimension); this skill is the deeper security-only process with mandatory gates and audit-grade output.
Install
Quality Score: 85/100
Skill Content
Details
- Author
- johnqtcg
- Repository
- johnqtcg/awesome-skills
- Created
- 4 months ago
- Last Updated
- yesterday
- Language
- Python
- License
- MIT
Integrates with
Similar Skills
Semantically similar based on skill content — not just same category
security-review
Use when the user asks whether code is safe or wants it audited for security - "security review", "audit this", "check for vulns", "is this exploitable", "any injection risk here", "threat model this endpoint" - covering authentication, authorisation, injection, secret handling, crypto, deserialisation, SSRF, and sensitive data exposure.
go-security-review
Review Go code for security vulnerabilities including OWASP Top 10, injection, auth/authz, crypto, secrets, SSRF, XSS, and input validation. Trigger when code involves SQL, user input, authentication, HTTP handlers, TLS, crypto, secrets, or file path operations. Use for security-focused code review of Go projects.
security-review
A focused, single-lens security review of a change. The one specialist a user runs alone when they care about exploitability — not a general sweep. Core method is taint tracing - follow untrusted input from its source, across the trust boundary, to a dangerous sink - and prove the path is reachable before calling it a finding. Covers injection (SQL/NoSQL/command/LDAP), XSS, SSRF, path traversal, insecure deserialization, authn/authz gaps (missing permission checks, IDOR), secret handling, sensitive-data exposure in logs/errors/URLs, crypto misuse, and unsafe defaults. Every finding cites file:line, a severity (a real exploit path is a blocker), the concrete attack, and a fix.