Pular para conteúdo

Allowlist — Gerenciando Falsos Positivos

A allowlist (também chamada de lista de supressão) permite que você marque findings específicos como aceitos ou falsos positivos, removendo-os dos contadores de score e dos relatórios. É especialmente útil quando um scanner detecta algo que não se aplica ao contexto do seu projeto.

O que é um falso positivo?

Um falso positivo ocorre quando um scanner reporta um problema que na verdade não é um risco no contexto específico do seu projeto. Exemplos comuns:

  • Scanner detecta "credencial hardcoded" em um arquivo de exemplo/fixture que usa dados fictícios
  • Regra de timeout aplicada a um worker de background que intencionalmente não tem timeout
  • Aviso de dependência vulnerável em uma biblioteca usada apenas em ambiente de desenvolvimento (não produção)
  • Padrão de logging identificado como "log injection" em código que já sanitiza a entrada

Use a allowlist com critério

A allowlist deve ser usada para falsos positivos reais, não para suprimir problemas legítimos. Todo item adicionado à allowlist deve ter uma justificativa registrada e deve ser revisado periodicamente.

Como adicionar uma regra à allowlist

Via interface de findings

A forma mais rápida de adicionar um item à allowlist é diretamente na tela de resultados:

  1. Na aba Findings, localize o finding que deseja suprimir.
  2. Clique no finding para abrir os detalhes.
  3. Clique no botão Suprimir / Adicionar à Allowlist.
  4. Preencha o formulário de supressão:
Campo Obrigatório Descrição
Motivo Sim Explicação por que este finding é um falso positivo
Padrão (regex) Não Se quiser suprimir em múltiplos arquivos com padrão similar
Expira em Não Data de revisão automática (recomendado: 90 dias)
  1. Clique em Confirmar Supressão.
Allowlist
Página de gerenciamento de allowlist (falsos positivos)

Via página de Allowlist

Para gerenciar todas as regras de uma vez:

  1. Na sidebar, acesse Código-Fonte → Allowlist (ou na aba de resultados, clique em Gerenciar Allowlist).
  2. A lista exibe todas as supressões ativas com finding ID, motivo e data de criação.
  3. Clique em Nova Regra para adicionar manualmente.

Campos da regra de allowlist

Finding ID

O identificador único do finding, no formato SCANNER-CODIGO (ex.: GOSEC-G401, SEMGREP-HARDCODED-SECRET). Você encontra o ID nos detalhes do finding.

Padrão (regex, opcional)

Um padrão de caminho de arquivo (regex) para aplicar a supressão em múltiplos arquivos. Exemplos:

Padrão O que suprime
testdata/.* Todos os arquivos dentro de testdata/
.*_test\.go Todos os arquivos de teste Go
fixtures/.*\.json Todos os JSONs em fixtures/
scripts/seed\.py Apenas o arquivo scripts/seed.py

Seja específico no padrão

Padrões muito amplos (ex.: .*) suprimem o finding em todos os arquivos do projeto, o que pode esconder problemas reais. Prefira padrões que cubram apenas a área relevante.

Motivo

Campo obrigatório de texto livre. Explique por que este finding não é um risco no contexto do projeto. Boas justificativas incluem:

  • "Fixture de teste com dados fictícios — sem credencial real"
  • "Script de migração legado, não executa em produção"
  • "Timeout não aplicável — worker consome fila sem SLA de latência"
  • "Dependência usada apenas em devDependencies, não enviada ao cliente"

Como revisar e remover regras

Revisão periódica

Recomendamos revisar a allowlist a cada 90 dias ou após grandes mudanças no projeto:

  1. Acesse a página de Allowlist.
  2. Clique no ícone de filtro e selecione Expiradas para ver regras vencidas.
  3. Para cada regra vencida, avalie:
  4. O problema foi corrigido? → Remova a regra.
  5. O problema ainda é falso positivo? → Renove a regra e atualize a data de expiração.

Remover uma regra

  1. Na tabela de allowlist, clique no ícone de lixeira na coluna Ações da regra que deseja remover.
  2. Confirme a remoção no modal de confirmação.
  3. O finding voltará a aparecer nos próximos assessments e será contabilizado no score.

O CrossCheck é uma verificação automática que compara as respostas do questionário de Performance/Resiliência com o que os scanners encontraram no código.

Se houver contradição, um banner de aviso é exibido no topo dos resultados:

Exemplo de banner CrossCheck

Conflito detectado: Você respondeu "Sim" para "Circuit breaker implementado nas integrações críticas", mas nenhum padrão de circuit breaker (Hystrix, resilience4j, go-resilience, etc.) foi detectado nos 47 arquivos que fazem chamadas HTTP. Verifique se a implementação está em um pacote não coberto pelo scanner ou se a resposta precisa ser revisada.

O que fazer ao ver um banner CrossCheck:

  1. Clique no banner para ver os detalhes do conflito.
  2. Se o código usa uma implementação não reconhecida pelo scanner → adicione à allowlist com motivo explicativo.
  3. Se a resposta do questionário estava errada → clique em Corrigir Resposta para revisitar aquela pergunta.
  4. Se o padrão não foi detectado corretamente → a equipe Elven Works pode adicionar suporte ao padrão (abra um ticket).

CrossCheck não bloqueia

O banner CrossCheck é informativo — não impede a visualização dos resultados nem afeta automaticamente o score. O score é ajustado conforme você resolve o conflito (corrigindo a resposta ou adicionando à allowlist).