---
id: qa-security-checklist
agent: qa
title: Scan de segurança de 8 pontos
inputs: [story, diff]
outputs: [achados de segurança rastreados, entrada na seção QA Results]
elicit: false
modes: [interactive, yolo]
---

# Scan de segurança de 8 pontos

**Objetivo:** varrer a mudança da story contra as 8 classes de vulnerabilidade mais comuns e
registrar cada achado com severidade rastreável a uma AC/NFR — antes que vire incidente em produção.

**Pré-condições:**
- A story existe e tem ACs. Se não houver contrato a rastrear, **pare** — eu não invento critério de
  segurança fora da story/spec.
- O `diff` da mudança está disponível (commit local do @dev). Sem código para inspecionar, não há scan.
- O scan automatizado (`*code-review`) já rodou. Eu não refaço à mão o que a máquina pega de graça.

## Passos

1. **Defina o perímetro de risco.** Liste o que a story toca: entrada de usuário, autenticação,
   dados sensíveis, chamadas externas. O eixo de maior risco recebe o mergulho mais profundo.
2. **Percorra os 8 pontos**, marcando cada um PASS / CONCERNS / FAIL com evidência (linha/arquivo):
   a. **Injeção** — SQL/NoSQL/command: toda query usa parâmetro/prepared statement? Nenhuma
      concatenação de input cru.
   b. **XSS** — todo dado renderizado é escapado/sanitizado? Nenhum `dangerouslySetInnerHTML` sem
      sanitização.
   c. **Secrets hardcoded** — nenhuma chave/token/senha no código ou em log. Tudo via env/cofre.
   d. **AuthN/AuthZ** — o endpoint verifica identidade E permissão? Nenhuma rota sensível sem guarda.
   e. **Validação de input** — todo input é validado em tipo/tamanho/range no servidor (não só no
      cliente).
   f. **Exposição de dado sensível** — nenhum PII/credencial em resposta, log ou mensagem de erro.
   g. **Dependências** — nenhuma lib com CVE conhecida introduzida pela mudança.
   h. **Configuração insegura** — CORS, headers, defaults permissivos, debug ligado em prod.
3. **Rastreie cada achado** a uma AC ou NFR. Achado sem âncora no contrato vira nota, não bloqueio —
   mas exposição de secret/PII é FAIL independentemente, por ser risco real.
4. **Atribua severidade** por probabilidade × impacto: CRITICAL/HIGH bloqueiam; MEDIUM/LOW viram
   CONCERNS documentado.
5. **Escreva o resultado** SOMENTE na seção "QA Results" da story: pontos avaliados, achados, severidade
   e evidência. Não toco em mais nada da story.
6. **Roteie a saída.** Achado CRITICAL/HIGH → `*create-fix-request` para o @dev com o defeito preciso.
   Limpo → alimenta o `*gate`.

## Critério de pronto (DoD)

- [ ] Os 8 pontos avaliados, cada um com veredito e evidência
- [ ] Cada achado rastreia a uma AC/NFR ou é risco real autoevidente (secret/PII)
- [ ] Severidade atribuída por probabilidade × impacto
- [ ] Resultado escrito só na seção QA Results
- [ ] CRITICAL/HIGH roteado ao @dev via fix-request

## Falha / recuperação

- **Diff indisponível ou parcial** → HALT, reporto que não posso assegurar segurança sem ver o código
  completo. Não aprovo no escuro.
- **Achado CRITICAL (secret/injeção)** → FAIL imediato, fix-request ao @dev. Não dou PASS por pressão
  de prazo.
- **A correção exige tocar infra/config externa** (CORS, secret store) → delego ao @devops; eu aponto,
  ele opera o ambiente.
- **A mudança não tem teste de segurança para o caminho corrigido** → registro como gap no gate; risco
  sem regressão é hipótese, não fato.