From goodvibesonly
Scan code for security vulnerabilities before committing. Catches hardcoded secrets, SQL injection, XSS, and other issues common in vibe-coded projects.
npx claudepluginhub jddoesdev/goodvibesonly# Security Scan
Run a security scan on the current changes before committing.
## Instructions
1. First, check what files have changed:
- Run `git diff --name-only --cached` for staged files
- If nothing staged, run `git diff --name-only` for unstaged changes
- If no changes, scan files mentioned by the user or recently modified files
2. For each changed file with a scannable extension (.js, .ts, .py, .rb, .php, .go, .java, etc.), scan for these patterns:
### CRITICAL - Block commit until fixed:
**Hardcoded Secrets:**
- OpenAI keys: `sk-[a-zA-Z0-9]{20,}`
- Anthropic keys: `sk-.../security-scanScans codebase for hardcoded secrets, vulnerable dependencies, common vulnerabilities like injections and XSS, and config issues, producing a structured security report with remediation steps.
/guardRuns manual security and quality scan on specified files/directories or git changes, producing categorized report of critical findings, warnings, and info.
/scanScans codebase for security vulnerabilities, hardcoded secrets, insecure patterns, and web security headers. Generates Markdown report with issues, code snippets, and remediation examples.
/security-scanScans codebase for OWASP Top 10 vulnerabilities and common security patterns. Defaults to entire project or limits to specified path.
/security-scanScans codebase for vulnerabilities, hardcoded secrets, OWASP Top 10 compliance, and security best practices violations. Produces report with issues and fix recommendations.
/code-reviewReviews uncommitted code changes via git diff for security vulnerabilities like hardcoded secrets and SQL injection, plus quality issues, generating a severity-based report with line numbers, descriptions, and fixes. Blocks commits on critical/high issues.
Share bugs, ideas, or general feedback.
Run a security scan on the current changes before committing.
First, check what files have changed:
git diff --name-only --cached for staged filesgit diff --name-only for unstaged changesFor each changed file with a scannable extension (.js, .ts, .py, .rb, .php, .go, .java, etc.), scan for these patterns:
Hardcoded Secrets:
sk-[a-zA-Z0-9]{20,}sk-ant-[a-zA-Z0-9-]{20,}AKIA[0-9A-Z]{16}ghp_[a-zA-Z0-9]{36}sk_(live|test)_[a-zA-Z0-9]{24,}api_key = "...", password = "..."-----BEGIN PRIVATE KEY-----Injection Vulnerabilities:
query("SELECT * FROM users WHERE id = " + userId)exec("rm " + userInput), shell=Trueeval(userInput)Dangerous Config:
Access-Control-Allow-Origin: *verify=False, rejectUnauthorized: falseXSS:
innerHTML = userContentdangerouslySetInnerHTMLv-html=Insecure Deserialization:
pickle.loads()yaml.load() without SafeLoaderWeak Crypto:
DEBUG = true in configconsole.log with passwords/tokensIf issues found:
GoodVibesOnly found [N] issues:
๐ด CRITICAL (must fix):
1. [Type]: [file]:[line]
`[code snippet]`
Fix: [how to fix]
๐ก HIGH (should fix):
...
๐ข MEDIUM (note):
...
Want me to fix the critical issues before you commit?
If clean:
โ GoodVibesOnly passed - no security issues found in [N] files
.goodvibesonly.jsonUsers can suppress specific findings by adding entries to .goodvibesonly.json in the project root:
{
"allow": [
{ "pattern": "XSS via dangerouslySetInnerHTML", "reason": "Sanitized with DOMPurify" },
{ "path": "test/**", "reason": "Test files contain intentional patterns" },
{ "pattern": "SQL Injection", "path": "src/db/raw.js", "reason": "Parameterized at call site" }
]
}
pattern only: suppress that pattern in all filespath only: suppress all patterns in matching files (supports * and ** globs)pattern + path: suppress specific pattern in specific filesreasonnode bin/scan.js --list-patterns to see all namesWhen a user wants to allow a finding:
One-time: Write entry to .goodvibesonly.json (don't stage it), re-run commit, then remove the entry afterward.
Permanent: Write entry to .goodvibesonly.json, re-run commit, leave the file for user to commit later.
Always show the user exactly what was added to the config.