Security audits

Skill NjoyimPeguy/augments/plugins/augments/skills/security-audits

A collection of rigorous, phase-isolated SDLC skills to tether autonomous agents to real-world engineering standards.

Install

npx -y skills add NjoyimPeguy/augments --skill security-audits

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

1 stars1 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

Use when a change touches a trust boundary — authentication, authorization, attacker-controlled input, secrets, or data exposure — and needs a security review before it ships. Skip for a change with no security surface.

SKILL.md

2.4 KB, as published. Nobody here has run it

Security Audits

A security review is not a tidier code review — it reasons about an adversary. The question is never "is this clean?" but "what can an attacker make this do?" Findings are traced, not guessed: untrusted input is followed from where it enters (source) to where it acts (sink).

When to use

A change touches auth, handles attacker-controlled input, moves secrets, or exposes data — anything with a trust boundary.
Skip for a change with no security surface: an internal refactor, docs, or a pure-compute helper over already-trusted input.

Procedure

Scope to the diff, then walk each category. For every suspect, state the concrete source → propagation → sink path — not "this could be unsafe".

Authn / authz — does the change touch who-can-do-what? Does it weaken an existing guard — a check removed, narrowed, or moved to after the action it protects?
Input validation — is attacker-controlled input validated before use? Follow it to every sink it reaches.
Injection — is untrusted input built into a query, shell command, path, URL, or template? (SQL, command, path traversal, SSRF.)
Secrets — is any credential, token, or key introduced in code or committed config instead of the environment or a secret store?
Data exposure — is sensitive data logged, serialized into an untrusted response, or returned in a field that shouldn't carry it?
Security regression — did the diff loosen something previously tighter: a validation, a rate limit, a permission check?

Report findings evidence-backed and severity-tiered (Critical / Important / Minor), each with its trace and a fix. End with an explicit ship / don't-ship verdict.

Common mistakes

Auditing the whole app instead of the change — review the diff's surface, deeply.
"Looks unsafe" with no source-to-sink path — that's a guess, not a finding.
Checking only added lines — a removed or weakened guard is the more dangerous diff.

For per-category checklists, the failure patterns most often missed, and the finding format, see references/audit-checklists.md.