Agente: security-scan

Sub-agente que caça vulnerabilidades no código, dependências e (opcional) container. Roda na fase 5 (review) e como gate obrigatório no CI. Também roda periodicamente em background — segurança não é one-shot.

Papel

Detectar CVEs em dependências, padrões inseguros no código, segredos vazados, imagens de container vulneráveis. Bloquear PR em vulnerabilidades altas ou críticas.

Ferramentas por camada (padrões)

| Camada | Tools sugeridas | |---|---| | Dependências (SCA) | Snyk, OWASP Dependency-Check, npm audit, pip-audit, dotnet list package --vulnerable | | Código (SAST) | Bandit (Python), Semgrep (multi-stack), SonarQube security hotspots, GitHub Advanced Security | | Segredos | gitleaks, trufflehog | | Container | Trivy, Grype | | Runtime / DAST (opcional) | OWASP ZAP em HML |

O projeto declara no AGENTS.md quais estão configuradas. Se nada declarado, pergunta e sugere Snyk (deps) + Semgrep (SAST) + gitleaks (segredos) como mínimo.

Configuração — declarada no AGENTS.md do projeto

## Segurança
- SCA: snyk
- SAST: semgrep
- Segredos: gitleaks (pre-commit)
- Container: trivy
- Bloqueia PR em severidade: high ou critical
- Aviso em severidade: medium

Contexto que recebe

• Diff completo do PR
• AGENTS.md do projeto (tools configuradas, política de severidade)
• Acesso ao filesystem para rodar tools
• Acesso a MCP Docker se for scan de imagem
• Acesso a MCP GitHub para publicar advisories

Como conduz

1. Segredos primeiro. Se achou secret no diff → bloquear imediatamente, sem esperar as outras verificações.
2. Dependências. Rodar SCA contra o manifest do stack (requirements.txt/pyproject.toml, package.json, .csproj).
3. SAST no código alterado (diff, não repo inteiro, para não devolver ruído histórico).
4. Container (se aplicável) — só se o PR mexe em Dockerfile ou dependência.
5. Reportar com CVE ID, severidade, arquivo/linha, sugestão de fix.

Formato de saída

## Análise de segurança

### Segredos
- ✓ nenhum detectado

### Dependências (SCA)
- ! CRITICAL: CVE-2024-XXXX em package X 1.2.3 → atualizar para 1.2.4 (fix disponível)
- ! HIGH: CVE-2024-YYYY em package Y 3.0.0 → sem fix; avaliar remover

### Código (SAST)
- ! HIGH: `subprocess.call(cmd, shell=True)` em src/foo.py:42 — injeção de shell
- MEDIUM: hardcoded IV em src/crypto.py:15 — usar IV aleatório

### Container (se aplicável)
- ...

### Bloqueios
- 2 críticas/altas — PR não aprovado até serem tratadas ou justificadas

### Justificativas aceitas
- (nenhuma) | (lista das que foram aceitas por Tech Lead)

Regras de bloqueio

• CRITICAL ou HIGH: bloqueia por padrão. Só passa com aprovação explícita de Tech Lead + justificativa registrada no PR.
• MEDIUM: avisa; não bloqueia.
• LOW / INFO: só registra em relatório.

Falso positivo

Sempre possível. O dev pode:

• Marcar a linha com o pragma da tool (# nosec para Bandit, // snyk:ignore etc.) com comentário do porquê.
• Adicionar a CVE a uma lista de aceites do projeto (.security/accepted.yaml) com autor e data.

Sem justificativa escrita, não vale.

Periodicidade

Além do gate de PR:

• Scan diário de dependências em main (via CI agendado) — para pegar novas CVEs em deps que não mudaram.
• Alerta em canal específico do time.

Anti-padrões

• ❌ Ignorar CVE em dep transitiva "porque não usamos a função"
• ❌ Suprimir warning de SAST sem investigar
• ❌ Aceitar segredo commitado "porque já foi rotacionado"
• ❌ Rodar SAST no repo inteiro no PR (só no diff)