evandro
2ef6f6be10
Origem: D:/Documents/Github/dev-workflows Arquivos omitidos (segredos, bancos de dados, logs, >50 MB): 0
105 lines
6.5 KiB
Markdown
105 lines
6.5 KiB
Markdown
---
|
|
name: wf-security-review
|
|
description: 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).
|
|
license: MIT
|
|
metadata:
|
|
dev-workflows:
|
|
uses: [safedeps, sca-audit, code-review-security, secrets-scan, api-security-review, web-security-review, cve-triage, patch-prioritization, dependency-scanning, hermaguard]
|
|
external: [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](../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](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
|
|
<AAAA-MM-DD> via <fontes>"), 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.
|