robcsaszar/sentinel

Habilidade de Auditoria de Segurança

Realize uma auditoria de segurança estática rigorosa em uma base de código de aplicação web. Produz uma tabela resumo (PASS / FAIL / MANUAL-REVIEW) e blocos individuais para cada achado, com evidência de arquivo:linha, descrição do risco e código de remediação.

---

Fase 1 — Triagem da Pilha

Antes de escanear qualquer código, responda estas perguntas lendo package.json, arquivos de configuração e README:

1. Framework: SvelteKit / Next.js / Express / FastAPI / etc.
2. Driver de banco de dados: parametrizado (libsql, pg, prisma) vs. string bruta (drivers de baixo nível)
3. Mecanismo de autenticação: JWT / tokens HMAC / sessões / OAuth
4. Alvo de deploy: Fly.io / Cloudflare / Vercel / Node puro — determina qual cabeçalho IP confiar para rate-limiting e logs de auditoria (Fly-Client-IP vs CF-Connecting-IP vs X-Forwarded-For); confiar no cabeçalho errado permite que um atacante falsifique seu IP de origem.
5. Uploads de arquivos: sim/não — se sim, onde armazenados (sistema de arquivos local, compatível com S3, CDN)
6. Chamadas externas de saída: API de e-mail, webhooks, busca de mídia — superfícies potenciais de SSRF.

Apresente seu resumo da pilha em um parágrafo antes da Fase 2. Suposições erradas aqui geram achados errados.

---

Fase 2 — Varredura

LEITURA OBRIGATÓRIA: references/security-checklist.md

NÃO carregue references/security-checklist.md para revisões de endpoint único direcionadas — isso expandirá o escopo além da tarefa. Carregue-o apenas para auditorias de código completo.

Percorra cada categoria da checklist em ordem — pular um grupo exige um motivo por escrito no relatório.

Para cada categoria:

• Leia o(s) arquivo(s) de código relevante(s). Não marque PASS de memória.
• Se o arquivo não existir, marque MANUAL-REVIEW com uma nota.
• Registre o veredito (PASS / FAIL / MANUAL-REVIEW) e uma nota de evidência de uma linha.

Se o repositório for grande demais para ler todos os arquivos, priorize por risco: fluxos de autenticação e manipulação de tokens primeiro, depois limites de entrada/saída, depois configuração de dependências. Anote quais arquivos foram pulados.

---

Fase 3 — Classifique

Revise suas anotações brutas da varredura. Para cada item, aplique as regras de veredito:

• PASS — você leu o código relevante e confirmou que o controle está em vigor. Cite arquivo:linha.
• FAIL — você encontrou uma lacuna confirmada e explorável. Você tem um snippet. Você pode escrever uma correção.
• MANUAL-REVIEW — o veredito exige contexto de tempo de execução, acesso à infraestrutura ou julgamento humano (por exemplo, "verifique se este token tem escopo somente leitura no painel do Turso").

Antes de atribuir um veredito, pergunte: "Posso escrever o código de remediação agora, usando apenas o que li?" Sim → FAIL. Não → MANUAL-REVIEW.

Não rebaixe um FAIL para MANUAL-REVIEW para suavizar o relatório.

---

Fase 4 — Relatório

Tabela resumo primeiro:

#	Categoria	Status	Notas
1	Injeção SQL	PASS	Parametrizado em todo o código
2	XSS	FAIL	{@html} em campo controlado pelo usuário — veja o achado
…	…	…	…

Então, para cada FAIL e MANUAL-REVIEW, um bloco de achado:

### [N]. CATEGORIA — FAIL
**Arquivo:** `src/lib/example.ts:42`
**Snippet:**
  cookies.set(name, token, { httpOnly: true })   // ← flag Secure ausente
**Risco:** Cookie transmitido por HTTP simples em não produção; capturado por MITM passivo.
**Correção:**
  cookies.set(name, token, {
    httpOnly: true,
    secure: process.env.NODE_ENV === "production",
    sameSite: "lax",
  });

Blocos MANUAL-REVIEW usam o mesmo formato, mas substituem Correção por Ação, descrevendo o que o humano deve verificar e onde.

Itens PASS aparecem apenas na tabela resumo — sem blocos.

---

NUNCA

• NUNCA marque PASS sem ler o arquivo Em vez disso: Leia o arquivo, cite arquivo:linha na nota de evidência. Por quê: Verdictos PASS baseados em memória produzem falsa segurança — o objetivo da auditoria é a evidência.

• NUNCA marque FAIL sem um snippet de código Em vez disso: Cite a(s) linha(s) vulnerável(eis) exata(s). Se não conseguir encontrar um snippet, é MANUAL-REVIEW. Por quê: Um FAIL sem evidência é ruído; os desenvolvedores precisam da localização exata para corrigi-lo.

• NUNCA confunda FAIL e MANUAL-REVIEW Em vez disso: FAIL = você pode escrever a correção agora. MANUAL-REVIEW = você não pode, e você diz por quê. Por quê: Misturá-los destrói a acionabilidade do relatório.

• NUNCA pule a triagem da pilha da Fase 1 Em vez disso: Leia package.json e um arquivo de configuração antes de escanear qualquer coisa. Por quê: Qual cabeçalho IP confiar, qual abordagem CSP é válida e qual modelo de autenticação se aplica dependem da pilha — suposições erradas geram vereditos errados.

• NUNCA relate código de remediação que não corresponda ao framework/biblioteca do projeto Em vez disso: Escreva correções usando as APIs exatas já em uso (por exemplo, cookies.set do SvelteKit, não res.setHeader). Por quê: Remediação genérica que não compila é ignorada; correções específicas do framework são mescladas.

• NUNCA escreva um bloco de achado para uma categoria cujo arquivo de código você não leu Em vez disso: Abra o arquivo, leia-o, depois escreva o bloco. Por quê: Um bloco de achado sem evidência de arquivo é afirmação, não auditoria — ele corrói a confiança em todo o relatório quando se descobre que está errado.

• NUNCA pule arquivos silenciosamente em um repositório grande Em vez disso: Priorize por risco (autenticação/manipulação de tokens → limites de entrada/saída → configuração de dependências) e liste explicitamente cada arquivo pulado no relatório. Por quê: Puladas silenciosas tornam as alegações de cobertura da auditoria não verificáveis — um relatório limpo em uma varredura incompleta parece um falso sinal verde.