security-audit-featurelisted

Focused security audit of ONE specific feature/change in the-platform (not the whole repository) — scope taken from a directory/branch/diff, a spec/PRD document, or a YouTrack issue; the same verification discipline as the full audit (adversarial verification, three independent passes, a 14-category checklist — auth/authz, multi-tenancy, websocket, internal API, injections, SSRF, XSS, secrets/PII, files, dependencies, docker, k8s/helm, error handling, CI/CD), with findings tied to file:line and an explicit release-readiness verdict. Use when asked to check the security of a specific feature, branch, PR, or YouTrack task before merge/release, to find vulnerabilities in a new endpoint/integration/file upload/webhook, or to assess whether new functionality opens access to someone else's data or another company — even without the word "audit", e.g. "is this feature leaking between companies", "is this feature OK to merge security-wise", "check this branch for security holes". This is NOT the same as the `security
smirnovalex-qa/qa-skills · ★ 1 · Data & Documents · score 75

Install: claude install-skill smirnovalex-qa/qa-skills

# Feature-scoped security review (single-feature security audit) For the-platform project: a microservices CRM platform that processes customer personal data. Security is a critical priority, not a formality. The audit must find real, exploitable problems tied to file:line, not produce a generic checklist without verification. Every finding must be confirmed by hand, not merely mentioned in a scanner's output. This is the focused version of the full repository audit (see the `security-audit-full` skill if the task is the whole repository rather than a single feature). The verification principles are the same, but the scope, findings, and report are strictly limited to the code that belongs to this feature and to what it touches. The manual-analysis work can be delegated through the Agent tool — use parallelization by zone as described in the "Running the check" section below. ## INPUT: HOW TO DETERMINE THE FEATURE Feature: `$ARGUMENTS` The feature is passed in one of three forms — figure out which one you have and build the review scope accordingly. The scope is ALWAYS wider than the literal input: include direct consumers/calling code (the router that registers the handler; the frontend that hits the API; the neighboring service that receives the inter-service call). **A. DIRECTORY/BRANCH/DIFF** (e.g. `services/xxx-service/feature_y/` or "diff between dev and the feature/PROJ-XXXX branch"): - Scope = the entire contents of the directory (or the files from `git diff -