| name | security |
| description | Security review skill for threat modeling, dependency audit, secret hygiene, and code review through a security lens. Activate when a change touches authentication, authorization, secrets, cryptography, input parsing, deserialization, network calls, or upgrades to dependencies. |
| license | Apache-2.0 |
| metadata | {"provenance":{"canonical":"https://github.com/hcross/crewrig","feedback":"https://github.com/hcross/crewrig","version":"1.1.0"}} |
Security
A focused review skill, not an exhaustive checklist. The goal is to
catch the realistic next exploit — not to enumerate the OWASP Top 10
every time.
When to activate
Mandatory triggers:
- Authentication, authorization, or session-handling code changes.
- Secret / credential / token storage or transmission paths.
- Cryptographic primitive use (hashing, signing, encryption, RNG).
- External input parsing (HTTP bodies, CLI args, file uploads, IPC).
- Deserialization of untrusted data.
- Outbound network calls (URLs from user input, redirects, SSRF surface).
- Dependency additions or upgrades touching the surface above.
Optional but encouraged: any code review on a security-adjacent module
(payment, PII, audit log) — even when the diff itself looks innocuous.
Operating mode
1. Trust boundary first
Before reading the diff, draw the trust boundary in your head:
- What input is untrusted here? (User input, network, file from
another process, env var passed in by the user.)
- What is inside the boundary? (Internal config, signed messages,
vetted constants.)
- The bug class to look for is the one that crosses the boundary
without proper handling.
2. Realistic threat, not paranoid theatre
Ask: what would the next attacker actually try here? Two concrete
threats with credible exploit paths beat a list of twenty generic
risks. Examples of credible threats per surface:
- HTTP handler reading from JSON: prototype pollution, type confusion,
unbounded length / depth.
- File path from user: traversal, symlink, race.
- SQL: parameterised? If yes, also check ORDER BY / LIMIT / table
name interpolation, which most ORMs do not parameterise.
- Crypto: AEAD with reused nonce, hash truncation, padding oracle, RNG
not from a CSPRNG.
- Deserialization: gadget chains, auto-instantiation.
3. Verify, do not assume
For each suspected issue, verify by:
- Reading the relevant function end-to-end (not just the diff hunk).
- Tracing the data flow from boundary to sink.
- Checking the test suite — if no test exists for the threat path,
flag the absence as part of the finding.
Do not flag a "potential" issue without showing how the data could
flow there. Speculation costs the user time and erodes credibility.
4. Output format
Report findings as a numbered list:
1. [SEV] <one-line summary>
Where: <file:line>
Threat: <what an attacker would do>
Evidence: <code snippet or trace>
Fix: <concrete recommendation>
Severity scale: BLOCKER / HIGH / MED / LOW / INFO. Reserve
BLOCKER for issues that must be fixed before merge (e.g. credential
leak, RCE, auth bypass).
Secret hygiene
- Never commit
.env, credentials.json, *.pem, or any file under
a vault path.
- Never echo a secret in logs, even at debug level. Even if the log is
ephemeral, the transcript may be persisted.
- If you find a leaked secret in the repo or transcript, rotate
guidance is part of the finding — flag the secret as compromised
the moment it touches a non-secret-grade store.
Dependency audit
When asked to review a dependency upgrade:
- Read the upstream changelog between current and target versions.
- Check the GitHub Security Advisory database for known CVEs.
- For minor / patch bumps, focus on transitive changes and licence drift.
- For major bumps, flag breaking changes and require a migration note.
Friction reporting
When a recognition signal fires (see config/TOOLS.md →
Friction Reporting → Recognition signals), invoke the
harness-report skill rather than reimplementing the protocol
inline. The reporter walks you through identifying the offender,
picking the room, and filling the payload.
