security-audit
Security Audit
Review security posture, trust boundaries, and unsafe defaults.
Scope
1. Trust boundaries and access control
- auth and trust boundaries
- authorization gaps between clients, sessions, and operations
- endpoint exposure and listener defaults
2. Transport and encryption
- transport security (
http/wsvshttps/wss) - sensitive payloads traversing insecure channels
- key/secret handling: env-based sourcing, redacted logs, no plaintext persistence
3. Execution boundaries
- path boundary enforcement for file operations
- path traversal and escaping project roots
- shell/command execution safety
- destructive operations without appropriate guards
4. Protocol abuse and resource exhaustion
- malformed payload handling and schema validation
- queue flooding, oversized input, replayable requests
- timeout/retry/cancel consistency
- unbounded work, logs, or memory growth
5. Secret exposure
- secrets in logs, errors, traces, or test fixtures
- error messages exposing tokens, paths, or private context
6. Defaults and dependencies
- config defaults creating insecure behavior
- unsafe opt-out flags or weak default modes
Evidence threshold
Only report findings with a concrete attack path, trust-boundary failure, or unsafe default. No speculative recommendations without a plausible abuse path.
Workflow
- Map entry points and trust boundaries.
- Classify each: local-only, authenticated, remote-accessible, privileged.
- Check validation, authorization, safe defaults at each boundary.
- Identify exploitable paths (read, write, execute, network, persist).
- Report findings by severity: critical → high → medium → low.
Output
For each finding: severity, affected files, attack/failure path, why risky, fix, test idea.
Then: Confirmed findings | Open questions | Optional hardening.
Anti-patterns
- Fear-driven recommendations without concrete attack paths
- Policy-heavy rewrites instead of minimal hardening
- Treating hypothetical deployment models as current vulnerabilities
- Security advice that is not actionable or testable
More from cniska/skills
pr
Create a pull request with review and verify. Use when the branch is ready to merge.
9plan
Design a feature or behavior change through dialogue. Use when asked to plan, scope, design, or break down work before coding.
9review
Run all review skills against the current branch diff. Use when reviewing a feature branch before merge.
9debug
Debug systematically with structured triage. Use when tests fail, builds break, or runtime behavior doesn't match expectations.
7build
Implement features incrementally through vertical slices. Use when building features, adding functionality, or implementing tasks that touch multiple files.
6simplify
Simplify code by reducing complexity while preserving exact behavior. Use after a feature is working, during review when complexity is flagged, or when encountering unclear code.
5