Secscan

Skill Hayatelin/devsecops-skills/skills/secscan

A security skills pack for Claude Code, Cursor, Codex and Gemini CLI: secrets pre-flight, dependency audit, secret rotation, STRIDE threat modeling, secure code review, Dockerfile hardening and env hygiene.

Install

npx -y skills add Hayatelin/devsecops-skills --skill secscan

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Run a fast secrets and dangerous-code pre-flight scan before committing or pushing code. Trigger when the user says "scan before commit", "check for secrets", "is this safe to push", or whenever you are about to stage, commit, or open a PR with new code.

SKILL.md

3.0 KB, as published. Nobody here has run it

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

Make sure the companion secscan tool is available. Prefer pip: pip install secscan-skill then run secscan . --min-severity high.
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
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.
Read every finding. Do not auto-suppress. Classify each as a real issue or a confirmed false positive.
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.