jarvis-ai-framework 1.0.0

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

@@ -0,0 +1,312 @@
+---
+description: Workflow de Engenharia para Auditoria de Seguranca (OWASP, secrets, supply chain)
+globs:
+  alwaysApply: false
+recommended_model: claude-opus-4-6-20250529
+model_tier: very_high
+model_justification: Auditoria de seguranca requer analise profunda de codigo, identificacao de padroes de vulnerabilidade, classificacao CVSS e geracao de relatorios estruturados
+---
+
+# Workflow de Engenharia – Security Audit
+
+## Objetivo
+
+Guiar o SENTINEL (ENG) na auditoria proativa de seguranca de projetos — analisando codigo, configs, dependencias e arquitetura contra OWASP Top 10, supply chain e boas praticas de seguranca. Gera relatorio com severidade CVSS e cards no `$TASK_MANAGER`.
+
+---
+
+## Quando Usar Este Workflow
+
+- Auditoria periodica de seguranca (por sprint ou release)
+- Onboarding em projeto sem historico de seguranca
+- Pre-lancamento de feature com superficie de ataque significativa
+- Pos-incidente para verificar outros vetores
+- Avaliacao de compliance (LGPD, GDPR, PCI-DSS)
+
+---
+
+## Pre-requisitos
+
+### Validar ENV.md
+
+```bash
+if [ ! -f "$IDE/ENV.md" ]; then
+  echo "ENV.md nao encontrado. Execute /init-jarvis primeiro."
+  exit 1
+fi
+
+required_vars=("WORKSPACE" "IDE" "SQUAD" "HUB" "AREA" "POSITION")
+for var in "${required_vars[@]}"; do
+  if ! grep -q "^$var=.\+" "$IDE/ENV.md"; then
+    echo "Variavel $var nao definida no ENV.md"
+  fi
+done
+```
+
+### Definir Escopo (Argumento)
+
+```
+/eng.security-audit [escopo]
+
+Onde [escopo] pode ser:
+- Caminho de pasta/arquivo: ./src/auth/
+- Modulo especifico: payment-service
+- Projeto completo: --all
+- Foco especifico: --focus=owasp|secrets|supply-chain|headers|compliance
+```
+
+---
+
+## Fase 0 – Analise de Contexto (CDD)
+
+> Skill: Use `/context-detect` se existir uma sessao ativa
+> Configuravel: Controlada pela variavel `ENABLE_CDD` no ENV.md
+
+```bash
+grep "^ENABLE_CDD=" $IDE/ENV.md
+```
+
+- Se `ENABLE_CDD=false` ou nao definida: pular esta fase
+- Se `ENABLE_CDD=true`: herdar contexto
+
+---
+
+## Fase 0.5 — Threat Model Scoping
+
+Se `THREAT_MODEL.md` existe no projeto (gerado por `/eng-threat-model`):
+
+1. Ler secao 3 "Entry points & trust boundaries" → usar como lista base de focus areas para fan-out
+2. Ler secao 4 "Threats" → filtrar por `status != mitigated` → priorizar areas com ameacas `almost_certain` ou `likely`
+3. Registrar `threat_model_ref` para incluir no `security-findings.json` de output
+
+Se nao existe: prosseguir para Fase 1 (recon manual de areas).
+
+> Threat model transforma o scan de "busca geral" em "busca guiada" — reduz ruido e aumenta recall nas areas criticas.
+
+---
+
+## Fase 1 – Scoping
+
+### 1.1 Mapear superficie de ataque
+
+```bash
+# Endpoints publicos (controllers, rotas)
+grep -rn --include="*.ts" --include="*.js" --include="*.py" \
+  -E "@(Get|Post|Put|Patch|Delete|Controller|app\.(get|post|put|delete)|router\.(get|post))" \
+  src/ 2>/dev/null | head -50
+
+# Arquivos de auth
+grep -rl --include="*.ts" --include="*.js" \
+  -E "(auth|guard|middleware|session|jwt|passport|oauth)" \
+  src/ 2>/dev/null
+
+# Configs de seguranca existentes
+find . -maxdepth 3 \( -name "helmet*" -o -name "cors*" -o -name "csp*" -o -name "*.security.*" \) 2>/dev/null
+```
+
+### 1.2 Priorizar areas
+
+| Prioridade | Area | Motivo |
+|------------|------|--------|
+| P0 | Auth, sessions, tokens | Bypass = acesso total |
+| P1 | Inputs (forms, APIs, uploads) | Injection, XSS |
+| P2 | Dados sensiveis (PII, financeiro) | Exposicao, compliance |
+| P3 | Dependencias e configs | Supply chain, misconfiguration |
+| P4 | Logs e monitoramento | Deteccao de ataques |
+
+---
+
+## Fase 2 – Reconnaissance
+
+### 2.1 Mapear tecnologias e frameworks
+
+```bash
+# Stack detection
+cat package.json 2>/dev/null | grep -E '"(nest|express|fastify|next|react|vue|prisma|typeorm|mongoose)"'
+cat requirements.txt 2>/dev/null | head -20
+cat go.mod 2>/dev/null | head -20
+
+# Verificar se ha ferramentas de seguranca ja instaladas
+cat package.json 2>/dev/null | grep -E '"(helmet|cors|csurf|express-rate-limit|bcrypt|argon2|zod|joi)"'
+```
+
+### 2.2 Mapear dados sensiveis
+
+```bash
+# Modelos com campos sensiveis
+grep -rn --include="*.ts" --include="*.js" --include="*.py" \
+  -E "(password|cpf|cnpj|credit_card|card_number|ssn|phone|birth_date|salary)" \
+  src/ 2>/dev/null | head -30
+
+# Verificar .gitignore para .env
+grep -E "\.env" .gitignore 2>/dev/null
+```
+
+---
+
+## Fase 3 – Analysis (OWASP Top 10)
+
+### Fan-out por focus-area
+
+Quando o projeto tem >15 arquivos de codigo-fonte, spawnar **1 subagente Task por focus-area** (max 10 concorrentes).
+Em projetos pequenos (<15 arquivos): analise sequencial sem fan-out.
+
+Cada subagente recebe:
+- Focus area derivada da Fase 0.5 (threat model) ou Fase 1 (recon manual)
+- Trust boundary do `THREAT_MODEL.md` secao 3, ou `"untrusted input → processo"` como fallback
+- O brief OWASP abaixo como instrucao de analise
+
+**Subagentes rodam sem MCP** — apenas Read/Grep para o codigo-alvo. Veredicto mais deterministico e barato.
+
+Para cada vetor, verificar no codigo e classificar achados:
+
+### A01 - Broken Access Control
+```bash
+# Endpoints sem guard/middleware de auth
+grep -rn --include="*.ts" "@(Get|Post|Put|Delete)" src/ | grep -v -E "(Guard|Auth|Roles|Public)" | head -20
+
+# IDOR patterns
+grep -rn --include="*.ts" "req.params\.\(id\|userId\|orderId\)" src/ | head -20
+```
+
+### A03 - Injection
+```bash
+# SQL injection patterns
+grep -rn --include="*.ts" --include="*.js" -E "(\$queryRaw[^U]|query\(.*\+|query\(.*\$\{|exec\(.*\+)" src/ 2>/dev/null
+
+# Command injection
+grep -rn --include="*.ts" --include="*.js" -E "(exec\(|execSync\(|spawn\()" src/ 2>/dev/null | head -20
+```
+
+### A05 - Security Misconfiguration
+```bash
+# CORS config
+grep -rn --include="*.ts" --include="*.js" -E "(enableCors|cors\()" src/ 2>/dev/null
+
+# Debug/dev configs em producao
+grep -rn --include="*.ts" --include="*.js" -E "(debug:\s*true|DEBUG=true|stack.*trace)" src/ 2>/dev/null
+```
+
+### A06 - Vulnerable Components
+```bash
+# Verificar vulnerabilidades
+npm audit --audit-level=moderate 2>/dev/null || echo "npm audit nao disponivel"
+```
+
+> Repetir para cada vetor relevante usando o skill `eng-cybersecurity` como referencia.
+
+---
+
+## Fase 4 – Supply Chain
+
+```bash
+# Verificar lockfile commitado
+git ls-files | grep -E "(package-lock|yarn.lock|pnpm-lock)" | head -5
+
+# Verificar se .npmrc esta seguro (sem tokens hardcoded)
+cat .npmrc 2>/dev/null | grep -v "^#" | grep -i "token\|auth" | head -5
+
+# Licencas problematicas
+npx license-checker --summary 2>/dev/null | head -20
+```
+
+---
+
+## Fase 5 – Classification
+
+Classificar cada achado no formato:
+
+```markdown
+### [SEV] Titulo da vulnerabilidade
+
+- **Severidade**: CRITICAL | HIGH | MEDIUM | LOW | INFO
+- **CVSS estimado**: X.X
+- **Vetor OWASP**: A01-A10
+- **Arquivo(s)**: `path/to/file.ts:line`
+- **Evidencia**: {codigo ou config vulneravel}
+- **Vetor de ataque**: {como um atacante exploraria}
+- **Impacto**: {o que acontece se explorado}
+- **Correcao**: {codigo ou config corrigido}
+- **Status**: aberto | corrigido | mitigado
+```
+
+---
+
+## Fase 6 – Reporting
+
+### 6.1 Gerar relatorio
+
+Criar arquivo `security-audit-report.md` na sessao:
+
+```markdown
+# Security Audit Report
+
+**Workspace**: $WORKSPACE
+**Squad**: $SQUAD
+**Data**: {data ISO-8601}
+**Auditor**: SENTINEL (AI-assisted)
+**Escopo**: {escopo auditado}
+
+## Resumo Executivo
+
+| Severidade | Quantidade |
+|------------|-----------|
+| CRITICAL | {n} |
+| HIGH | {n} |
+| MEDIUM | {n} |
+| LOW | {n} |
+| INFO | {n} |
+
+## Achados
+
+{lista de achados classificados, do mais critico ao menos}
+
+## Recomendacoes Prioritarias
+
+1. {correcao mais urgente}
+2. {segunda mais urgente}
+...
+
+## Proximos Passos
+
+- [ ] Corrigir achados CRITICAL/HIGH
+- [ ] Agendar correcao de MEDIUM para proxima sprint
+- [ ] Documentar LOW/INFO como debt de seguranca
+```
+
+### 6.2 Criar cards no $TASK_MANAGER
+
+Para achados CRITICAL e HIGH, criar cards com:
+- Titulo: `[SECURITY] {titulo da vulnerabilidade}`
+- Label: `security`, `{severidade}`
+- Descricao: evidencia + correcao sugerida
+- Prioridade: maxima para CRITICAL, alta para HIGH
+
+---
+
+## Fase 6.3 — Output JSON (security-findings.json)
+
+Alem do relatorio markdown, escrever `.security/outputs/security-findings.json` conforme `docs/SECURITY-ARTIFACTS-SCHEMA.md` secao 2. Criar `.security/outputs/` se nao existir.
+
+Um arquivo por focus-area durante o fan-out (prefixar IDs: `AUTH-F001`, `DEPS-F002`).
+Consolidar em arquivo unico ao final em `.security/outputs/security-findings.json`, reordenando por (impact, likelihood) decrescente.
+
+Este arquivo e o input direto do skill `eng-security-triage`.
+
+---
+
+## Regras
+
+### Nunca
+- Ignorar um achado porque "provavelmente nao sera explorado"
+- Executar exploits reais contra o sistema em producao
+- Expor secrets encontrados no relatorio (mascarar com `***`)
+- Minimizar severidade sem justificativa tecnica
+- Pular a classificacao CVSS
+
+### Sempre
+- Usar o skill `eng-cybersecurity` como referencia de padroes
+- Classificar TODOS os achados por severidade
+- Incluir evidencia (codigo) e correcao para cada achado
+- Mascarar secrets encontrados antes de reportar
+- Comunicar achados CRITICAL imediatamente ao usuario (nao esperar o relatorio final)

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

@@ -0,0 +1,275 @@
+---
+description: Workflow de Engenharia para Resposta a Incidentes de Seguranca (CVEs, vulnerabilidades, breaches)
+globs:
+  alwaysApply: false
+recommended_model: claude-opus-4-6-20250529
+model_tier: very_high
+model_justification: Incident response requer analise rapida e precisa de vulnerabilidades, avaliacao de impacto e decisoes de contencao que afetam producao
+---
+
+# Workflow de Engenharia – Security Incident Response
+
+## Objetivo
+
+Guiar o SENTINEL (ENG) na resposta estruturada a incidentes de seguranca — desde CVEs criticas ate vulnerabilidades reportadas e breaches. Prioriza contencao rapida seguida de correcao definitiva e documentacao preventiva.
+
+---
+
+## Quando Usar Este Workflow
+
+- CVE critica publicada que pode afetar dependencias do projeto
+- Vulnerabilidade reportada por ferramenta de scan (SAST/DAST)
+- Secret vazado no repositorio ou em producao
+- Incidente de seguranca reportado (acesso indevido, dados expostos)
+- Alerta de dependencia comprometida (supply chain attack)
+
+---
+
+## Pre-requisitos
+
+### Validar ENV.md
+
+```bash
+if [ ! -f "$IDE/ENV.md" ]; then
+  echo "ENV.md nao encontrado. Execute /init-jarvis primeiro."
+  exit 1
+fi
+```
+
+### Entrada do Incidente
+
+```
+/eng.security-incident [referencia]
+
+Onde [referencia] pode ser:
+- CVE ID: CVE-2024-XXXXX
+- URL do advisory: https://github.com/advisories/GHSA-xxxx
+- Descricao: "SQL injection no endpoint /api/users"
+- Card do $TASK_MANAGER: TASK-1234
+```
+
+---
+
+## Fase 1 – Triage
+
+**Objetivo**: classificar rapidamente a severidade e impacto.
+
+### 1.1 Coletar informacoes
+
+```markdown
+## Triage
+
+**Referencia**: {CVE, advisory URL ou descricao}
+**Reportado por**: {ferramenta, pesquisador, equipe interna}
+**Data do report**: {ISO-8601}
+**Tipo**: {CVE em dependencia | vulnerabilidade no codigo | secret leak | breach | outro}
+```
+
+### 1.2 Classificar severidade
+
+| Criterio | CRITICAL | HIGH | MEDIUM | LOW |
+|----------|----------|------|--------|-----|
+| Explorabilidade | Remota, sem auth | Remota, com auth | Local ou com privilegio | Teorica |
+| Impacto | RCE, data breach, auth bypass | Escalacao de privilegio, data leak parcial | DoS, info disclosure limitada | Baixo impacto |
+| Dados afetados | PII, financeiro, credenciais | Dados internos sensiveis | Dados nao-sensiveis | Nenhum |
+| Superficie | Endpoint publico | Endpoint autenticado | Funcao interna | Codigo morto |
+
+### 1.3 Decisao de urgencia
+
+| Severidade | SLA de resposta | Acao imediata |
+|------------|-----------------|---------------|
+| **CRITICAL** | Conter em 1h, corrigir em 24h | Notificar TL/CTO, iniciar contencao |
+| **HIGH** | Corrigir em 48h | Notificar TL, planejar correcao |
+| **MEDIUM** | Corrigir na proxima sprint | Criar card, documentar |
+| **LOW** | Backlog | Documentar, corrigir quando conveniente |
+
+---
+
+## Fase 2 – Assessment
+
+**Objetivo**: determinar se e como o projeto e afetado.
+
+### 2.1 Para CVEs em dependencias
+
+```bash
+# Verificar se a dependencia vulneravel esta instalada
+grep "{pacote}" package.json package-lock.json 2>/dev/null
+# ou
+pip show {pacote} 2>/dev/null
+
+# Verificar versao instalada vs. versao afetada
+npm ls {pacote} 2>/dev/null
+
+# Verificar se o codigo usa a funcao/modulo vulneravel
+grep -rn --include="*.ts" --include="*.js" "{funcao_ou_import_afetado}" src/ 2>/dev/null
+```
+
+### 2.2 Para vulnerabilidades no codigo
+
+```bash
+# Localizar o codigo vulneravel
+grep -rn --include="*.ts" --include="*.js" --include="*.py" "{pattern}" src/ 2>/dev/null
+
+# Verificar se o endpoint e acessivel publicamente
+# Verificar se ha guards/middleware protegendo
+# Verificar se inputs sao validados antes de chegar ao ponto vulneravel
+```
+
+### 2.3 Para secrets vazados
+
+```bash
+# Verificar se o secret ainda esta ativo
+# Verificar onde o secret e usado
+grep -rn "{secret_parcial}" . --include="*.ts" --include="*.js" --include="*.env" --include="*.yml" 2>/dev/null
+
+# Verificar historico git
+git log --all --oneline -S "{secret_parcial}" 2>/dev/null | head -10
+```
+
+### 2.4 Documentar assessment
+
+```markdown
+## Assessment
+
+**Projeto afetado**: sim | nao | parcialmente
+**Versao afetada**: {versao da dependencia ou do codigo}
+**Superficie de ataque**: {endpoints, funcoes, configs afetadas}
+**Dados em risco**: {tipo de dados que podem ser comprometidos}
+**Exploracao confirmada**: sim | nao | nao verificavel
+```
+
+---
+
+## Fase 3 – Containment
+
+**Objetivo**: limitar o impacto imediato enquanto a correcao definitiva e preparada.
+
+### Acoes de contencao por tipo
+
+| Tipo | Acao de contencao |
+|------|-------------------|
+| Endpoint vulneravel | Desabilitar endpoint ou adicionar guard temporario |
+| Secret vazado | Revogar/rotacionar o secret IMEDIATAMENTE |
+| Dependencia com CVE | Avaliar se patch esta disponivel, aplicar se possivel |
+| Auth bypass | Adicionar validacao extra, revogar sessions ativas se necessario |
+| Data exposure | Verificar logs de acesso, avaliar notificacao (LGPD 72h) |
+
+### Documentar contencao
+
+```markdown
+## Containment
+
+**Acao tomada**: {descricao da contencao}
+**Timestamp**: {ISO-8601}
+**Reversivel**: sim | nao
+**Impacto da contencao**: {funcionalidades temporariamente afetadas}
+```
+
+> **IMPORTANTE**: Contencao e temporaria. Sempre seguir com correcao definitiva.
+
+---
+
+## Fase 4 – Remediation
+
+**Objetivo**: implementar correcao definitiva e validar.
+
+### 4.1 Implementar correcao
+
+- Usar o skill `eng-cybersecurity` como referencia de padroes seguros
+- Corrigir a causa raiz (nao apenas o sintoma)
+- Adicionar validacao/sanitizacao onde necessario
+- Atualizar dependencias afetadas
+
+### 4.2 Validar correcao
+
+```bash
+# Rodar testes existentes
+npm test 2>/dev/null
+
+# Verificar que a vulnerabilidade foi corrigida
+# (reproduzir o vetor de ataque e confirmar que falha)
+
+# Rodar npm audit novamente (se CVE em dep)
+npm audit 2>/dev/null
+```
+
+### 4.3 Documentar correcao
+
+```markdown
+## Remediation
+
+**Correcao aplicada**: {descricao tecnica}
+**Arquivos alterados**: {lista}
+**Testes adicionados**: {sim/nao — quais}
+**Dependencias atualizadas**: {pacote@versao_antiga → pacote@versao_nova}
+```
+
+---
+
+## Fase 5 – Post-mortem
+
+**Objetivo**: documentar o incidente para aprendizado e prevencao.
+
+### Template de post-mortem
+
+```markdown
+# Security Post-mortem
+
+**Incidente**: {titulo}
+**Severidade**: {CRITICAL|HIGH|MEDIUM|LOW}
+**Data de deteccao**: {ISO-8601}
+**Data de resolucao**: {ISO-8601}
+**Tempo de resolucao**: {duracao}
+
+## Timeline
+
+| Timestamp | Evento |
+|-----------|--------|
+| {t0} | Vulnerabilidade reportada/detectada |
+| {t1} | Triage concluida — severidade {X} |
+| {t2} | Contencao aplicada |
+| {t3} | Correcao implementada e testada |
+| {t4} | Deploy da correcao |
+
+## Causa Raiz
+
+{O que causou a vulnerabilidade? Quando foi introduzida?}
+
+## Impacto
+
+{Dados afetados, usuarios impactados, janela de exposicao}
+
+## Correcao
+
+{O que foi feito para resolver}
+
+## Prevencao
+
+{O que sera feito para evitar recorrencia}
+
+- [ ] {acao preventiva 1}
+- [ ] {acao preventiva 2}
+- [ ] {acao preventiva 3}
+
+## Licoes Aprendidas
+
+{O que o time aprendeu com este incidente}
+```
+
+---
+
+## Regras
+
+### Nunca
+- Minimizar um incidente de seguranca ("provavelmente ninguem explorou")
+- Deixar um secret vazado ativo enquanto investiga — revogar PRIMEIRO
+- Aplicar correcao sem testes de validacao
+- Pular o post-mortem ("ja foi resolvido, vamos seguir")
+- Expor detalhes do incidente em canais publicos antes da correcao
+
+### Sempre
+- Comunicar achados CRITICAL ao TL/responsavel imediatamente
+- Revogar secrets vazados antes de qualquer outra acao
+- Documentar timeline completa do incidente
+- Verificar se a vulnerabilidade afeta outros servicos do projeto
+- Propor melhorias preventivas no post-mortem