dev-workflows/skills/wf-security-review/SKILL.md

name, description, license, metadata

name	description	license	metadata
wf-security-review	Use para revisão de segurança de código, diff ou PR (frontend e backend), para varrer dependências atrás de CVE, procurar segredos commitados ou auditar auth, API e injeção; também quando o dev-router dispara um gatilho de segurança (auth, dinheiro, dados pessoais, upload, SQL montado à mão, dependência nova, feature com LLM). Consulta fontes vivas de vulnerabilidade com data. Não use para revisão de correção ou estilo sem aspecto de segurança (isso é o agente reviewer) nem para desenhar arquitetura (wf-architecture).	MIT	dev-workflows uses external safedeps sca-audit code-review-security secrets-scan api-security-review web-security-review cve-triage patch-prioritization dependency-scanning hermaguard bola-detector injection-checker auth-rbac-scaffold

Workflow Security Review

O conhecimento de CVE do modelo para na data de corte do treino. Por isso toda revisão consulta fontes vivas (OSV.dev, GitHub Advisory Database, NVD, CISA KEV) e registra a data da consulta. Nunca afirme "sem CVE" sem ter consultado. Uma revisão sem fonte e sem data já nasce vencida.

Este workflow vem pré-carregado no agente security-auditor.

Profundidade por nível (do dev-router)

Nível	Escopo	Padrão	Ferramentas
1 com gatilho	só o diff	Top 10 no que o diff toca	gate --tier 1 (gitleaks, semgrep)
2	diff + superfície alcançável (rotas, handlers, queries, componentes que usam o código alterado)	ASVS 5.0 L1	gate --tier 2 (+ osv-scanner), safedeps em toda dependência nova
3 ou auditoria completa	toda a superfície	ASVS 5.0 L2	gate --tier 3 (+ trivy), passe adversarial do hermaguard, STRIDE contra a arquitetura

Gate: "${CLAUDE_PLUGIN_ROOT}/scripts/quality-gate" --tier N. Checagens e configuração em ../dev-router/references/quality-gate.md. Os scanners são ponto de partida, não substituem a leitura do código.

Fase 1: SCOPE

1. Delimite o alvo: git diff --stat <base> e arquivos não rastreados; front, back ou os dois.
2. Registre a stack, os gerenciadores de pacote e os lockfiles (package-lock.json, pnpm-lock.yaml, requirements.txt, poetry.lock, go.mod, Cargo.lock).
3. No nível 2 ou mais, mapeie a superfície alcançável: quem chama o código alterado e o que fica exposto (rota, fila, webhook, UI).

Fase 2: HUNT (dependências)

1. safedeps nas dependências novas ou alteradas, com versão e ecossistema: python3 "${CLAUDE_PLUGIN_ROOT}/skills/safedeps/check_deps.py" [email protected]:npm ou o manifest inteiro: python3 "${CLAUDE_PLUGIN_ROOT}/skills/safedeps/check_deps.py" requirements.txt.
2. sca-audit para alcance (reachability): a função vulnerável é chamada pelo projeto?
3. cve-triage e patch-prioritization para ordenar por CVSS 4.0, EPSS e CISA KEV.
4. Separe alcançável (bloqueia) de não alcançável (risco residual registrado).

Fase 3: CONSULT (fontes vivas)

Responda "há vulnerabilidade nova que eu não conheço?" consultando, com data:

• OSV.dev (já coberto pelo safedeps; batch: POST https://api.osv.dev/v1/querybatch).
• GitHub Advisory Database: gh api graphql -f query='{securityAdvisories(first:10, orderBy:{field:PUBLISHED_AT,direction:DESC}){nodes{ghsaId summary severity publishedAt}}}'.
• NVD: curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=<framework>&resultsPerPage=10".
• CISA KEV para saber se já há exploração ativa.
• Página de security ou changelog do framework em uso.

Vulnerabilidade nova que afeta a versão do projeto vira achado HIGH, com a versão de correção.

Fase 4: CODE REVIEW

Referências atuais: OWASP Top 10:2025, OWASP API Security Top 10 (2023), ASVS 5.0 e, se a feature chama um LLM, OWASP LLM Top 10 (2025). As skills OWASP vendorizadas ainda citam o Top 10 de 2021; use o mapa 2021 para 2025 em references/owasp-2025.md.

Frontend (web-security-review, code-review-security):

• renderização de HTML com entrada do usuário (dangerouslySetInnerHTML, v-html, innerHTML);
• segredo no bundle do cliente; token em localStorage (prefira cookie httpOnly, Secure, SameSite);
• CSP, links e redirecionamentos montados com entrada do usuário.

Backend (code-review-security, api-security-review; se instaladas, bola-detector, injection-checker, auth-rbac-scaffold):

• autenticação e autorização por objeto (BOLA/IDOR): a query é escopada pelo usuário autenticado?
• injeção: SQL, ORM cru, shell, template, path traversal; SSRF (agora dentro de A01);
• tratamento de condição excepcional (A10:2025): erro que falha aberto, exceção engolida, stack trace na resposta;
• rate limit em escrita e login, CORS com allowlist explícita, segredo nunca em log.

Segredos: secrets-scan no diff e no histórico (git log -p -S "<padrão>"); o gitleaks do gate cobre os arquivos alterados.

Cadeia de suprimentos (A03:2025): dependência nova justificada, lockfile commitado, scripts de instalação suspeitos, versões fixadas no CI.

Nível 3: rode o hermaguard no diff (edge cases, ataque, blast radius) e confira o threat model STRIDE do wf-architecture: cada ameaça tem mitigação no código?

Cada achado: severidade (CRITICAL, HIGH, MEDIUM, LOW), CWE, referência OWASP, arquivo:linha, passos de exploração, impacto e correção. Diferencie confirmado de suspeita. "Não achei com grep" não é "não existe": siga o fluxo.

Fase 5: REPORT + GATE

Relatório com: cabeçalho (nível, escopo, padrão ASVS e a linha "consulta de atualização feita em via "), resumo por severidade, decisão do gate, os achados, tabela de dependências (pacote, versão, CVE, severidade, corrigida em, alcançável, fonte), veredito do gate de qualidade com o que ficou não verificado, e riscos aceitos.

Regra do gate: CRITICAL ou HIGH alcançável em aberto = não aprovado. MEDIUM entra no próximo ciclo; LOW e residual ficam registrados como risco aceito. Depois de cada correção, rode de novo a checagem que acusou o problema e o gate no mesmo nível.

Regras duras

• Nunca "sem vulnerabilidades" sem consulta a fonte viva com data.
• Nunca CVE sem versão afetada e versão corrigida.
• Nunca expor um segredo encontrado no relatório: cite arquivo, linha e tipo, com o valor mascarado.
• Queries sempre parametrizadas, nunca concatenadas com entrada.
• Correção que muda dependência ou mais de 3 arquivos: nova rodada de revisão.