jarvis-ai-framework 1.0.0

package/workflows/engineering/eng.security-pipeline.md

@@ -0,0 +1,210 @@
+---
+description: Orquestrador do pipeline defensivo de segurança — encadeia threat-model, audit, triage e patch em um único fluxo guiado
+globs:
+  alwaysApply: false
+recommended_model: claude-opus-4-6-20250529
+model_tier: very_high
+model_justification: Orquestração do pipeline completo exige raciocínio profundo para avaliar estado, decidir fases e interpretar outputs encadeados
+---
+
+# Workflow de Engenharia – Security Pipeline (Orquestrador)
+
+## Objetivo
+
+Guiar o SENTINEL pelo pipeline defensivo completo de segurança, encadeando os 4 estágios em um fluxo único. Elimina a necessidade de lembrar a sequência de comandos — o usuário informa onde quer começar e o orquestrador conduz.
+
+---
+
+## Quando Usar Este Workflow
+
+- Auditoria de segurança completa de um projeto ou feature
+- Retomada de pipeline interrompido em sessão anterior
+- Onboarding de segurança em projeto sem histórico de audit
+- Quando o usuário pede "auditar segurança", "pipeline completo" ou "fechar o loop"
+
+---
+
+## Passo 0 — Detectar estado do pipeline
+
+Antes de perguntar qualquer coisa, verificar o que já existe:
+
+```bash
+# Artefatos de output
+ls .security/outputs/ 2>/dev/null
+# State de sessões anteriores
+ls .security/state/ 2>/dev/null
+```
+
+| Artefato encontrado | Fase concluída |
+|---------------------|----------------|
+| `THREAT_MODEL.md` | Estágio 1 feito |
+| `security-findings.json` | Estágio 2 feito |
+| `triage.json` | Estágio 3 feito |
+| `PATCHES/` com conteúdo | Estágio 4 feito |
+
+Exibir o estado detectado antes de mostrar o menu.
+
+---
+
+## Passo 1 — Menu de entrada
+
+```
+Pipeline de Segurança — SENTINEL
+
+Estado atual:
+  [✓/–] Estágio 1: Threat Model   (.security/outputs/THREAT_MODEL.md)
+  [✓/–] Estágio 2: Audit           (.security/outputs/security-findings.json)
+  [✓/–] Estágio 3: Triage          (.security/outputs/triage.json)
+  [✓/–] Estágio 4: Patch           (.security/outputs/PATCHES/)
+
+Onde iniciar?
+
+1. Completo    — estágio 1 → 2 → 3 → 4
+2. Audit+      — estágio 2 → 3 → 4  (já tenho ou pulo threat model)
+3. Triage+     — estágio 3 → 4       (já tenho security-findings.json)
+4. Só patch    — estágio 4            (já tenho triage.json)
+5. Retomar     — continuar de onde parou (detectar pelo state/)
+```
+
+> Se todos os artefatos existem, perguntar: "Pipeline completo encontrado. Reexecutar do início (--fresh) ou revisar outputs existentes?"
+
+---
+
+## Passo 2 — Executar os estágios selecionados
+
+Executar cada estágio em sequência. Ao final de cada um, confirmar com o usuário antes de prosseguir para o próximo.
+
+---
+
+### Estágio 1 — Threat Model (`/eng-threat-model`)
+
+**Skill**: `$IDE/skills/eng-threat-model/SKILL.md`
+
+Perguntar modo de operação:
+```
+Modo do threat model:
+1. bootstrap            — deriva o modelo do código automaticamente
+2. interview            — walk interativo com você como owner do sistema
+3. bootstrap-then-interview — bootstrap primeiro, entrevista refinadora depois
+```
+
+Invocar o skill com o modo escolhido. Output esperado: `.security/outputs/THREAT_MODEL.md`.
+
+Ao concluir:
+```
+✓ Threat model gerado em .security/outputs/THREAT_MODEL.md
+  Ameaças identificadas: {N}
+  Areas priorizadas para audit: {lista de focus-areas}
+
+Prosseguir para Estágio 2 (Audit)? [s/n]
+```
+
+---
+
+### Estágio 2 — Security Audit (`/eng.security-audit`)
+
+**Workflow**: `$IDE/workflows/engineering/eng.security-audit.md`
+
+Passar `THREAT_MODEL.md` como contexto se existir (Fase 0.5 do audit).
+
+Perguntar escopo se não informado:
+```
+Escopo do audit:
+1. Projeto completo (--all)
+2. Pasta específica (ex: ./src/auth/)
+3. Focus específico (owasp | secrets | supply-chain | headers | compliance)
+```
+
+Output esperado: `.security/outputs/security-findings.json` + `security-audit-report.md`.
+
+Ao concluir:
+```
+✓ Audit concluído
+  Achados brutos: {N}
+  Distribuição: CRITICAL {n} | HIGH {n} | MEDIUM {n} | LOW {n}
+  Output: .security/outputs/security-findings.json
+
+Prosseguir para Estágio 3 (Triage)? [s/n]
+```
+
+> Se N == 0: informar "Nenhum achado encontrado. Pipeline encerrado." e parar.
+
+---
+
+### Estágio 3 — Triage (`/eng-security-triage`)
+
+**Skill**: `$IDE/skills/eng-security-triage/SKILL.md`
+
+Input: `.security/outputs/security-findings.json`
+
+Perguntar modo:
+```
+Modo de triage:
+1. --auto    — sem perguntas interativas (recomendado para pipelines CI)
+2. interativo — coleta contexto de trust boundary e tolerância a ruído
+```
+
+Output esperado: `.security/outputs/triage.json`
+
+Ao concluir:
+```
+✓ Triage concluído
+  Achados confirmados: {N}  |  Falsos positivos descartados: {N}
+  Top 3 por exploitabilidade: {lista}
+  Output: .security/outputs/triage.json
+
+Prosseguir para Estágio 4 (Patch)? [s/n]
+```
+
+> Se N confirmados == 0: informar "Nenhum achado confirmado após triage. Pipeline encerrado." e parar.
+
+---
+
+### Estágio 4 — Patch (`/eng-security-patch`)
+
+**Skill**: `$IDE/skills/eng-security-patch/SKILL.md`
+
+Input: `.security/outputs/triage.json`
+
+Perguntar escopo:
+```
+Gerar patches para:
+1. Todos os achados confirmados
+2. Apenas top N (ex: top 3 por severidade)
+3. Achado específico (ID F-NNN)
+```
+
+Output esperado: `.security/outputs/PATCHES/bug_NN/{patch.diff, patch_result.json}` + `PATCHES.md`
+
+Ao concluir:
+```
+✓ Pipeline de segurança concluído
+
+Resumo:
+  Threat model : .security/outputs/THREAT_MODEL.md
+  Achados audit: .security/outputs/security-findings.json  ({N} achados)
+  Triage       : .security/outputs/triage.json              ({N} confirmados)
+  Patches      : .security/outputs/PATCHES/                 ({N} diffs gerados)
+  Relatório    : .security/outputs/security-audit-report.md
+
+Próximos passos para o TL:
+  1. Revisar diffs em .security/outputs/PATCHES/
+  2. Aplicar patches aprovados: git apply .security/outputs/PATCHES/bug_NN/patch.diff
+  3. Criar cards no $TASK_MANAGER para achados sem patch (no_patch)
+  4. Commitar .security/outputs/ (excluir .security/state/ via .gitignore)
+```
+
+---
+
+## Regras
+
+### Nunca
+- Pular a confirmação do usuário entre estágios sem `--auto` explícito
+- Avançar para Estágio 4 sem triage (patches gerados de achados não verificados têm alta taxa de erro)
+- Aplicar diffs automaticamente — output é sempre texto inerte para revisão humana
+
+### Sempre
+- Detectar estado existente antes de mostrar o menu
+- Informar quantos achados passaram de cada estágio
+- Parar o pipeline se nenhum achado sobreviver a um estágio (audit vazio ou triage sem confirmados)
+- Sugerir `.gitignore` para `.security/state/` se não estiver ignorado

package/workflows/engineering/eng.security-review.md

@@ -0,0 +1,235 @@
+---
+description: Workflow de Engenharia para Review de Seguranca em PRs/MRs (gate pre-merge)
+globs:
+  alwaysApply: false
+recommended_model: claude-sonnet-4-6-20250514
+model_tier: high
+model_justification: Security review de PRs requer analise focada de mudancas especificas — nao exige raciocinio tao profundo quanto audit completo, mas precisa de precisao
+---
+
+# Workflow de Engenharia – Security Review (Gate Pre-Merge)
+
+## Objetivo
+
+Guiar o SENTINEL (ENG) na revisao de seguranca de PRs/MRs que tocam areas sensiveis do codigo — autenticacao, autorizacao, inputs, APIs, configs e permissoes. Funciona como gate de seguranca complementar ao code review normal.
+
+---
+
+## Quando Usar Este Workflow
+
+- PR modifica fluxos de autenticacao ou autorizacao
+- PR adiciona ou modifica endpoints publicos
+- PR toca em processamento de inputs (forms, uploads, parsing)
+- PR modifica configs de seguranca (CORS, CSP, headers)
+- PR adiciona dependencias novas
+- PR toca em dados sensiveis (PII, financeiro)
+- PR modifica permissoes ou roles (RBAC, guards)
+- Tech Lead solicita security review explicito
+
+---
+
+## Pre-requisitos
+
+### Entrada
+
+```
+/eng.security-review [referencia-do-pr]
+
+Onde [referencia-do-pr] pode ser:
+- Numero do PR/MR: #123
+- URL: https://gitlab.com/org/repo/-/merge_requests/123
+- Branch: feature/nova-auth
+```
+
+---
+
+## Fase 1 – Scope
+
+### 1.1 Identificar arquivos alterados
+
+```bash
+# Listar arquivos alterados no PR/branch
+git diff --name-only main...HEAD 2>/dev/null || git diff --name-only origin/main...HEAD
+
+# Filtrar arquivos sensiveis
+git diff --name-only main...HEAD | grep -E "(auth|guard|middleware|session|login|permission|role|token|secret|password|cors|csp|helmet|security|\.env)" 2>/dev/null
+```
+
+### 1.2 Classificar risco do PR
+
+| Indicador | Risco | Motivo |
+|-----------|-------|--------|
+| Toca em auth/guard/session | **ALTO** | Bypass pode dar acesso total |
+| Adiciona endpoint publico | **ALTO** | Nova superficie de ataque |
+| Modifica CORS/CSP/headers | **ALTO** | Misconfiguration afeta toda app |
+| Processa input do usuario | **MEDIO** | Injection, XSS |
+| Adiciona dependencia nova | **MEDIO** | Supply chain |
+| Modifica roles/permissoes | **ALTO** | Escalacao de privilegio |
+| Toca em dados sensiveis | **ALTO** | Data exposure |
+| Refactoring sem mudanca de API | **BAIXO** | Risco minimo |
+
+---
+
+## Fase 2 – Analysis
+
+### 2.1 Checklist de seguranca por area
+
+#### Auth e Sessions
+- [ ] Tokens JWT: expiracao curta para access, refresh com rotacao
+- [ ] Sessions: `httpOnly`, `secure`, `sameSite: strict`
+- [ ] Password hashing: bcrypt/argon2 (nunca MD5/SHA1)
+- [ ] Rate limiting em login/registro
+- [ ] Logout invalida session/token no backend
+
+#### Inputs e Validation
+- [ ] Todos os inputs validados com schema (Zod, Joi, class-validator)
+- [ ] Queries parametrizadas (nunca concatenacao SQL)
+- [ ] Uploads: validar tipo, tamanho, nome de arquivo
+- [ ] Rich text: sanitizado com allowlist (DOMPurify)
+- [ ] URLs dinamicas: validadas contra allowlist (prevenir SSRF)
+
+#### APIs e Endpoints
+- [ ] Endpoints protegidos com auth guard (exceto os intencionalmente publicos)
+- [ ] Autorizacao verificada (RBAC/permissions, nao apenas autenticacao)
+- [ ] IDOR prevenido (usuario so acessa seus dados ou tem permissao)
+- [ ] Rate limiting em endpoints sensiveis
+- [ ] Erros nao vazam detalhes internos (stack traces, queries)
+
+#### Configs e Headers
+- [ ] CORS: origins especificas (nunca `*` em producao)
+- [ ] CSP: configurado e restritivo
+- [ ] HSTS: habilitado com `includeSubDomains`
+- [ ] X-Frame-Options: `DENY` ou `SAMEORIGIN`
+- [ ] Sem debug mode em producao
+
+#### Dependencias
+- [ ] `npm audit` sem vulnerabilidades HIGH/CRITICAL
+- [ ] Lockfile atualizado e commitado
+- [ ] Dependencia nova: verificar manutencao, downloads, issues
+
+#### Dados Sensiveis
+- [ ] PII criptografada em repouso
+- [ ] Logs nao contem dados sensiveis (senhas, tokens, PII)
+- [ ] Dados sensiveis nao expostos em respostas de API desnecessariamente
+
+---
+
+## Fase 2.5 — Verificacao Multi-Voto
+
+Para cada achado identificado no checklist (Fase 2), spawnar **3 subagentes de voto** independentes.
+
+> Subagentes de voto rodam **sem MCP** — apenas o texto do achado como contexto. Menos tool = veredicto mais deterministico e barato.
+
+**Brief por subagente de voto:**
+
+```
+Voce e um revisor de seguranca independente. Avaliar este achado:
+
+ACHADO: {titulo} em {arquivo}:{linha}
+EVIDENCIA: {codigo ou config vulneravel}
+CONTEXTO: PR #{referencia}, area {categoria}
+
+Este e um achado real e exploravel no contexto deste PR?
+
+Responda exatamente:
+verdict: confirmed | rejected | inconclusive
+reasoning: <uma linha explicando o veredicto>
+confidence: <0.0-1.0>
+```
+
+**Consolidacao dos votos:**
+
+| Resultado | Criterio | Acao |
+|---|---|---|
+| Confirmado | >= 2/3 votos `confirmed` | Incluir no report com severidade original |
+| Falso positivo | >= 2/3 votos `rejected` | Descartar — nao incluir |
+| Inconcluso | Divergencia | Incluir com flag `[REVISAR]` para humano |
+
+---
+
+## Fase 3 – Verdict
+
+### 3.1 Classificar resultado
+
+| Verdict | Criterio | Acao |
+|---------|----------|------|
+| **APPROVED** | Nenhum achado HIGH/CRITICAL | Aprovar merge |
+| **CHANGES REQUESTED** | Achados MEDIUM ou HIGH corrigiveis | Solicitar correcoes com evidencia |
+| **BLOCKED** | Achado CRITICAL ou HIGH nao corrigivel trivialmente | Bloquear merge, escalar para TL |
+
+### 3.2 Feedback estruturado
+
+Para cada achado, comentar no PR com:
+
+```markdown
+**[SECURITY - {SEVERIDADE}]** {titulo}
+
+**Arquivo**: `path/to/file.ts:line`
+**Vetor**: {tipo de vulnerabilidade}
+**Evidencia**:
+\`\`\`typescript
+// codigo vulneravel
+\`\`\`
+
+**Correcao sugerida**:
+\`\`\`typescript
+// codigo seguro
+\`\`\`
+```
+
+---
+
+## Fase 4 – Documentation
+
+### 4.1 Registrar decisao
+
+```markdown
+## Security Review Summary
+
+**PR/MR**: {referencia}
+**Reviewer**: SENTINEL (AI-assisted)
+**Data**: {ISO-8601}
+**Verdict**: APPROVED | CHANGES REQUESTED | BLOCKED
+
+### Areas revisadas
+- [ ] Auth e Sessions
+- [ ] Inputs e Validation
+- [ ] APIs e Endpoints
+- [ ] Configs e Headers
+- [ ] Dependencias
+- [ ] Dados Sensiveis
+
+### Achados
+| # | Severidade | Descricao | Status |
+|---|-----------|-----------|--------|
+| 1 | {sev} | {descricao} | {aberto|corrigido} |
+
+### Notas
+{observacoes adicionais relevantes}
+```
+
+---
+
+## Fase 4.2 — Output JSON (security-findings.json)
+
+Alem do summary markdown (Fase 4.1), escrever `security-findings.json` conforme `docs/SECURITY-ARTIFACTS-SCHEMA.md` secao 2.
+
+Incluir apenas achados com `vote_result.verdict != rejected` (confirmed + inconclusive).
+Este arquivo pode ser consumido por `eng-security-triage` para dedup e re-rank caso o PR faca parte de um audit maior.
+
+---
+
+## Regras
+
+### Nunca
+- Aprovar um PR com achado CRITICAL sem correcao
+- Bloquear um PR sem evidencia tecnica (nao bloquear por "sensacao")
+- Fazer review de seguranca superficial (checklist mecanico sem analise)
+- Ignorar dependencias novas adicionadas ao projeto
+
+### Sempre
+- Analisar o diff completo, nao apenas os arquivos marcados como "sensiveis"
+- Fornecer correcao sugerida para cada achado (nao apenas apontar o problema)
+- Considerar o contexto: um endpoint interno tem risco diferente de um publico
+- Comunicar achados CRITICAL ao TL imediatamente (nao esperar o review terminar)
+- Verificar se testes de seguranca foram adicionados para mudancas em auth