Secscan

When to use

• Right before a git commit, git push, or opening a pull request.
• After generating or editing code that touches auth, config, env vars, DB queries, subprocess calls, or crypto.
• When the user pastes a file and asks "anything dangerous in here?"

Process

1. Make sure the companion secscan tool is available. Prefer pip: pip install secscan-skill then run secscan . --min-severity high.
2. If pip is unavailable or you want zero-install, fetch the single file and run it: curl -sSL https://raw.githubusercontent.com/Hayatelin/secscan-skill/main/secscan.py -o secscan.py && python secscan.py . --min-severity high
3. Scan only what is about to ship when possible: pass changed paths, or run on the staged set (git diff --cached --name-only) so you flag what this commit actually introduces.
4. Read every finding. Do not auto-suppress. Classify each as a real issue or a confirmed false positive.
5. Fix real issues (see "How to fix"), re-run the scan, and confirm it comes back clean before committing.

What to check

The scanner surfaces these categories — verify each one it reports:

• Hardcoded secrets — API keys, tokens, AWS keys, private keys, passwords, connection strings with credentials, high-entropy strings.
• eval / exec / dynamic code — and JS Function(), setTimeout("string"), child_process on untrusted input.
• shell=True / shell injection — subprocess(..., shell=True), os.system, backticks, unsanitized command strings.
• SQL injection — string-formatted/concatenated queries instead of parameterized statements.
• Weak crypto — MD5/SHA1 for security, DES/RC4, hardcoded IVs, random (not secrets) for tokens, disabled TLS verification.

How to fix

• Secrets: remove from source, move to env vars or a secrets manager, and ROTATE the exposed value — if it was ever committed, treat it as compromised (see the secret-rotation skill).
• eval/exec: replace with a safe parser, an allow-list dispatch table, or ast.literal_eval for data.
• shell=True: pass an argument list (["cmd", arg]) with shell=False; never interpolate user input into a command string.
• SQL injection: use parameterized queries / prepared statements or the ORM's safe query builder.
• Weak crypto: use SHA-256+/bcrypt/argon2 for hashing, AES-GCM for encryption, secrets.token_urlsafe() for tokens, and never disable certificate verification.

Report back

Summarize as: total findings by severity, the concrete issues that remain, what you fixed, and a final "clean / not clean" verdict. If anything is a deliberate false positive, say which line and why. Never report "safe to commit" until a re-scan at --min-severity high is clean.