security-audit-fulllisted

Full security audit of the ENTIRE the-platform repository (all backend services, the-frontend, embeddable widgets/extensions, shared libraries libs/*, infrastructure configs helm/k8s/docker) — three independent passes (automated scanning SCA/SAST/secret-scan/IaC, line-by-line code review by zone, architectural review), a detailed 14-category checklist (auth/authz, multi-tenancy, websocket, internal API, injections, SSRF, XSS, secrets/PII, files, dependencies, docker, k8s/helm, error handling, CI/CD), findings with file:line and an exploitation scenario, and a final report for leadership. Use when asked to run a full security audit of the whole codebase/repository/platform, to find vulnerabilities across the entire project, to re-verify the status of findings from a previous security audit, or to assess the platform's overall readiness to handle customer personal data from a security standpoint — even if the user doesn't say the word "audit" literally, but says "let's check the whole project for security holes
smirnovalex-qa/qa-skills · ★ 1 · DevOps & Infrastructure · score 75

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

# Full repository 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. ## INPUT `$ARGUMENTS` — optionally a path to the previous audit report for a "before → after" comparison. If not passed, look for it yourself: the registry of past findings lives in `docs/bugs/security_audit/` (each finding records a verdict: confirmed / false positive / already fixed), and the regression check over it is `scripts/verify_audit_fixes.py`, if present in the repository. This is an audit of the WHOLE repository. If the task actually concerns only one feature/branch/PR/YouTrack task, use `security-audit-feature` instead of a full review of the entire codebase (otherwise the scope will be excessive and the findings will not be tied to what really needs checking before a specific release). ## KEY PRINCIPLE: VERIFICATION, NOT TRUST The main reason security audits fail is taking it on faith that "the fix was written" is equivalent to "the vulnerability is closed". It is NOT. Verify every fix adversarially: 1. If a check was added (a flag, an HMAC signature, escaping, authorization), make sure it is ENABLED by default and active in all environments (dev/staging/prod), not merely im