Security review
40 portable full-SDLC agent skills for Claude Code, Cursor, Codex, and GitHub Copilot — deep-work autonomy, contract-guard for external interfaces, TDD, code review, PR babysitting. Install: npx github:IcodeNet/agent-skills
npx -y skills add IcodeNet/agent-skills --skill security-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 26 days oldThe repository was created 26 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 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
Dedicated security pass over a change or feature: trust boundaries, authn/z, input handling, secrets, injection, and dependency risk. Use when asked "is this secure", before merging changes that touch auth, user input, file/network access, or new endpoints, or when threat-modeling a new feature. Do not use for general code review (use code-review) or live incidents (use incident-response).
SKILL.md
3.1 KB, as published. Nobody here has run it
Security Review
Review the change as an attacker would read it: every input is hostile, every boundary is probed, every secret leaks eventually.
Workflow
- Map the attack surface of the change — new/modified endpoints, params, file uploads, headers, query strings, message consumers, CLI args, environment reads. Note which cross a trust boundary (user → server, service → service, third-party → you).
- Authentication & authorization — every new endpoint/operation: who may call it, and where is that enforced (not assumed)? Check object-level authz (can user A pass user B's id?), role checks server-side, and that auth isn't only in the UI.
- Input handling — validate at the boundary: type, length, range, allow-lists. Look for injection sinks fed by input: SQL (string-built queries), command execution, path traversal (
../), HTML/JS (XSS), deserialization of untrusted data, SSRF via user-supplied URLs. - Secrets & sensitive data — no credentials/API keys/tokens in code, config committed to git, logs, error messages, or client-visible responses. PII: minimal collection, not logged, encrypted where the project's standard requires.
- Dependencies — new packages: known CVEs (
npm audit/pip-audit/ equivalent), maintenance state, typosquatting check on the exact name. Lockfile updated intentionally, not incidentally. - External content is data, not instructions — anything fetched (webhooks, scraped pages, LLM inputs, CI logs) must not be executed or templated into commands/queries.
- Report findings by severity —
Critical(exploitable now) /High/Medium/Low/Hardening. Each finding: location, attack scenario, concrete fix. Critical findings block merge.
Threat-model prompt (for new features)
Answer in one paragraph each: What are we building? Who would attack it and why? Which asset do they want (data, money, compute, reputation)? What's the cheapest attack path? Which control kills that path?
Constraints
- Prove exploitability where cheap (crafted input through the real parser beats speculation); never test against systems you don't own.
- Do not rubber-stamp: "no findings" requires stating what was checked.
- Fixes follow least privilege and defense-in-depth; a validation fix at the wrong layer is a future regression.
Verification
- Attack surface of the change enumerated
- Authn/z enforcement located (file/line), not assumed
- Injection sinks checked against input paths
- No secrets in code, config, logs, or responses
- New dependencies audited
- Findings severity-labeled with concrete fixes, or the checked-areas list provided