refactor(skills): cut the workflows to ~100 lines and scale phases by tier

Each workflow was ~300 lines of grep-count "VERIFICAR" steps and ran every
phase for every request. Phases now state their minimum tier, checks are the
quality gate plus real tools, detail moved to references/, and machine-specific
paths and non-public skills are gone. Security references move to OWASP Top
10:2025, ASVS 5.0 and the OWASP LLM Top 10.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

skills/wf-security-review/SKILL.md

@@ -1,209 +1,104 @@
 ---
 name: wf-security-review
-description: "Code review de segurança (front+back). OSV/NVD + OWASP."
-version: 1.0.0
-author: Hermes Agent
+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
-platforms: [linux, macos, windows]
 metadata:
-  hermes:
-    tags: [security, code-review, cve, owasp, sast, sca, workflow, devsecops]
+  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 Code Review (front + backend)
+# Workflow Security Review
 
-Orquestrador obrigatório para todo code review de segurança — frontend E
-backend. Cobre: revisão de código (OWASP), vulnerabilidades conhecidas em
-dependências, E consulta de NOVAS vulnerabilidades nos lugares certos
-(OSV.dev, NVD, GitHub Advisory) para que o review esteja sempre atualizado,
-não preso ao cutoff de treino do modelo.
+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.
 
-## When to Use
+Este workflow vem pré-carregado no agente `security-auditor`.
 
-- "revisa a segurança desse código/PR/diff" (front ou back)
-- "escaneia dependências por CVEs" / "alguma lib vulnerável?"
-- "tem vulnerabilidade nova conhecida pra X?" (consulta de atualização)
-- "audita auth/API/injeção" / "procura segredos commitados"
-- QUALQUER review de merge que mexa em dado sensível ou rota nova
-- Pré-commit ou pré-deploy como etapa de segurança
+## Profundidade por nível (do `dev-router`)
 
-## Skills do stack (3 principais + auxiliares)
+| 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 |
 
-**As 3 skills de segurança atuais (instaladas de fontes primárias):**
-1. `safedeps` (Jeneidi) — grounding em OSV.dev em tempo real: consulta
-   `package@version` e traz CVE com severidade e fix. Cobre o gap de o
-   modelo só conhecer vulns até o cutoff. CLI: `check_deps.py`.
-2. `sca-audit` (OWASP secure-agent-playbook) — SCA (Supply Chain Analysis)
-   de dependências com análise de alcance (reachability), CWE mapping.
-3. `code-review-security` (OWASP secure-agent-playbook) — code review de
-   segurança sistemático mapeado a OWASP Top 10 + ASVS.
+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.
 
-**Auxiliares (carregar por contexto):**
-- `secrets-scan` (OWASP) — busca credenciais/API keys no código e git history
-- `api-security-review` + `bola-detector` + `auth-rbac-scaffold` +
-  `injection-checker` (OWASP/API) — revisão de API
-- `web-security-review` (OWASP) — web app OWASP Top 10
-- `cve-triage` + `patch-prioritization` (UnitOne/SecuritySkills) — priorizar
-  CVE por CVSS 4.0 / EPSS / CISA KEV
-- Locais: `dependency-cve-audit`, `hermaguard` (caça bugs adversariais),
-  `security-threat-model`
+## Fase 1: SCOPE
 
-## Fase 1 — SCOPE (definir alvo antes de auditar)
+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).
 
-1. Identificar o que está no escopo: diff/PR, arquivos, front, back, ambos.
-2. Registrar stack do projeto (linguagens, frameworks, package managers,
-   se há lockfile: package-lock.json / requirements.txt / go.mod / etc).
-3. Rodar o código? Identificar se há ambiente local testável.
-4. VERIFICAR: `git status` + `git diff --stat` para delimitar o alvo real.
-5. Checkpoint: confirmar escopo com o usuário antes de gastar auditoria.
+## Fase 2: HUNT (dependências)
 
-**Checklist da fase 1:**
-- [ ] Escopo delimitado (arquivos/diff/PR)
-- [ ] Stack e lockfiles identificados
-- [ ] Alvo confirmado
+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 2 — HUNT (vulnerabilidades conhecidas — dimensão de dependências)
+## Fase 3: CONSULT (fontes vivas)
 
-1. `sca-audit` — scan de dependências com análise de alcance; mapear CVEs
-   por severidade e reachable/unreachable.
-2. `safedeps` — para cada dependência-chave do manifest, consultar OSV.dev:
-   `python3 ~/.hermes/skills/safedeps/check_deps.py "pkg@version"` (ou via
-   manifest completo) — traz CVE reais com fix (o modelo NÃO sabe CVE nova
-   do cutoff pra frente; o OSV.dev sim).
-3. `cve-triage` / `patch-prioritization` — priorizar achados por
-   CVSS 4.0 / EPSS / CISA KEV quando disponível.
-4. `dependency-cve-audit` (local) — varredura das deps do projeto atual.
-5. VERIFICAR: consolidar lista de CVE com severidade + versão afetada +
-   versão fixa; separar reachable (devem ser bloqueantes) de non-reachable
-   (registrar como risco residual).
-6. CHECKPOINT: apresentar sumário de CVE antes de partir para o code review.
+Responda "há vulnerabilidade nova que eu não conheço?" consultando, com data:
 
-**Comandos úteis:**
-```bash
-python3 ~/.hermes/skills/safedeps/check_deps.py "[email protected]"   # 1 pkg
-python3 ~/.hermes/skills/safedeps/check_deps.py -f package-lock.json  # manifest
-# veja a skill sca-audit p/ reachability; cve-triage p/ priorização
-```
+- 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.
 
-**Anti-padrões desta fase:**
-- NUNCA afirmar "sem CVE" sem ter CONSULTADO OSV.dev (memória do modelo é
-  congelada no cutoff).
-- NÃO tratar CVE de dependência transitiva não-reachable como crítica igual
-  a reachable — reportar com nuance.
-- NUNCA rodar scan em lockfile sem conferir o package manager certo.
+Vulnerabilidade nova que afeta a versão do projeto vira achado HIGH, com a versão de correção.
 
-**Comandos reais (Fase 2):**
-```bash
-python3 ~/.hermes/skills/safedeps/check_deps.py "[email protected]"
-python3 ~/.hermes/skills/safedeps/check_deps.py -f package-lock.json
-# alternatives: npm audit --json / pip-audit -r requirements.txt / trivy fs .
-```
+## Fase 4: CODE REVIEW
 
-## Fase 3 — CONSULT (novas vulnerabilidades — atualização contínua)
+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).
 
-O objetivo é responder "há vulnerabilidade NOVA que eu não conheço?" — o
-modelo só sabe até o cutoff; consultar fontes vivas:
+**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.
 
-1. OSV.dev (API aberta, sem key) — já coberto na Fase 2 via safedeps.
-2. GitHub Advisory Database — via `gh api`:
-   `gh api graphql -f query='{securityAdvisories(first:10, orderBy:{field:PUBLISHED_AT,direction:DESC}){nodes{ghsaId,summary,severity,publishedAt}}}'
-3. NVD — via API (key opcional): consultar CPE do stack ou CVEs recentes do
-   framework em uso (`curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=..."`).
-4. Registros de framework (ex: changelog/security de Next.js, Express,
-   NestJS, FastAPI) — advisories recentes do framework do projeto.
-5. VERIFICAR: para LIB versão X e FRAMEWORK Y, registrar qual fonte foi
-   consultada e a data — sem "não tem" sem fonte.
-6. CHECKPOINT: se alguma vuln nova afeta o stack do projeto, tratar como
-   finding HIGH e sugerir upgrade.
+**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.
 
-**Comandos úteis:**
-```bash
-gh api graphql -f query='{securityAdvisories(first:10, orderBy:{field:PUBLISHED_AT,direction:DESC}){nodes{ghsaId,summary,severity,publishedAt}}}'
-curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=nextjs&resultsPerPage=10"
-# OSV batch: curl -s -X POST https://api.osv.dev/v1/querybatch -d '@manifests.json'
-```
+**Segredos**: `secrets-scan` no diff e no histórico (`git log -p -S "<padrão>"`); o gitleaks do gate cobre os arquivos alterados.
 
-**Anti-padrões desta fase:**
-- NUNCA responder "não tem vulnerabilidade nova" sem citar fonte viva + data.
-- NÃO confiar no cutoff do modelo para saber CVE recente — sempre consultar.
-- NÃO esquecer de incluir data da consulta (revisão vence se ficar velho).
+**Cadeia de suprimentos** (A03:2025): dependência nova justificada, lockfile commitado, scripts de
+instalação suspeitos, versões fixadas no CI.
 
-## Fase 4 — CODE REVIEW (front + backend, OWASP)
+**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?
 
-Frontend (`web-security-review` + `code-review-security`):
-1. XSS/injeção em renderização (dangerouslySetInnerHTML, v-html, innerHTML).
-2. Exposição de segredos no client (API keys, tokens em bundle).
-3. Containers: loads, links com user input, cookies httpOnly/secure.
-4. `secrets-scan` — credenciais no código e git history.
-5. Auth de frontend: fluxo de tokens, storage inseguro (localStorage p/ JWT).
+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.
 
-Backend (`code-review-security` + `api-security-review` + `bola-detector` +
-`auth-rbac-scaffold` + `injection-checker`):
-1. AuthN/AuthZ: rotas sem auth, IDOR/BOLA (`bola-detector`), RBAC.
-2. Input validation: SQLi, XSS, command injection, SSRF, path traversal
-   (`injection-checker`).
-3. Segredos: env vars, nunca logar senha/token.
-4. Rate limit, erros sem vazar stack trace, CORS correto.
-5. `hermaguard` (opcional) p/ caça adversarial de bugs no mesmo diff.
-6. VERIFICAR: para cada rota com `:id`, rodar `bola-detector` de novo (IDOR
-   é o achado nº1 em API) e para cada query, `injection-checker`.
-7. VERIFICAR: rodar `secrets-scan` no diff E git history antes de fechar —
-   credencial commitada em algum commit antigo ainda vaza.
-8. VERIFICAR: conferir erros sem stack trace (grep por exceptions/console no
-   cliente) e CORS/headers (`grep -rn "access-control\|csp"`).
-9. VERIFICAR: `grep -rn "localStorage\|sessionStorage" src/` — nenhum JWT
-   sensível em storage de frontend (usar httpOnly cookie).
-10. VERIFICAR: confirmar rate limit em rotas de escrita (`grep -rniE "limiter|rate"`) e que respostas não vazam caminho interno.
+## Fase 5: REPORT + GATE
 
-**Output por finding:** Severidade (Critical/High/Med/Low) + CWE + OWASP ref +
-Arquivo:linha + Evidência + Remediação.
+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.
 
-**Anti-padrões desta fase (front + back):**
-- NUNCA approve sem reportar achado de AuthN/AuthZ ou injection como mínimo.
-- Padrão de coerência — NÃO misturar "parece ok" com achado sem evidência.
-- NÃO confundir "não achei com grep" com "não existe" — checar fluxo inteiro.
-- NÃO focar só no front quando o fix toca o back (IDOR/BOLA vive no back).
-
-**Comandos de auditoria (Fase 4):**
-```bash
-# segredos: busca em código e git history
-grep -rniE "(api[_-]?key|secret|password|token|bearer)" src/ | grep -v node_modules
-git log -p --all -S "sk-" --oneline | head   # chave vazada em commit antigo
-# headers/CORS/rate limit
-grep -rniE "access-control|content-security-policy" src/
-grep -rniE "ratelimit|rate_limit|limiter|express-rate" src/
-python3 ~/.hermes/skills/software-development/wf-qa/test_quality.py  # gate
-```
-
-## Fase 5 — REPORT + GATE (entregar e decidir)
-
-1. Consolidar tudo: sumário (nº por severidade), findings detalhados,
-   tabela de CVE com fonte/estado/reachable/fix, e status "consulta de
-   atualização feita em <data> via <fontes>".
-2. GATE: Critical/High reachable → BLOQUEAR merge até corrigir. Medium →
-   tratar no próximo ciclo. Low/residual → registrar risco aceito.
-3. Re-auditar após fixes: re-rodar as checagens que acusaram P0/P1.
-4. VERIFICAR: `python3 ~/.hermes/skills/software-development/wf-qa/test_quality.py`
-   (gate não-regressivo do stack de workflows).
-5. Relatório final em markdown (report.md) + resumo em chat.
-6. VERIFICAR (comandos de report): gerar `security-report.md` com
-   `find . -maxdepth 2 -name "*.md" | sort` conferindo artefatos, e
-   `grep -c "CVE-" security-report.md` para ter contagem explícita no doc.
-7. VERIFICAR (data da consulta): `grep -i "data da consulta\|20[2-9][0-9]-" security-report.md` — sem revisão sem carimbo de data (ela vence).
-
-**Checklist de entrega:**
-- [ ] Os 3 pilares rodados: safedeps (OSV), sca-audit, code-review-security.
-- [ ] Consulta de novas vulns feita em fonte viva (OSV/GH Advisory/NVD) com data.
-- [ ] Findings com CWE + OWASP + evidência + remediação.
-- [ ] GATE aplicado (block/allow) por severidade/reachability.
-- [ ] Nenhuma skill do stack removida; test_quality.py passando.
+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 afirmar "sem vulnerabilidades" sem consultar OSV.dev/GH Advisory
-  (modelo tem cutoff; fonte viva não).
-- NUNCA reportar CVE sem incluir versão afetada + versão fixa.
-- NUNCA blocker Critical/High reachable "para depois" — bloquear merge.
-- NUNCA logar/expor segredo durante o review (nem no relatório).
-- Re-auditar sempre que o fix tocar >3 arquivos ou mudar dependência.
-- SQL/queries: sempre parâmetros posicionais, nunca concatenação de input.
+- 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.