Findings — Entendendo os Achados
Um finding é um problema ou risco detectado durante o assessment. Esta página explica como ler, filtrar e gerenciar os findings na plataforma.
Anatomia de um finding
Ao clicar em qualquer finding na lista, um drawer lateral se abre com todos os detalhes:
Campos do finding
| Campo | Descrição |
|---|---|
| Título | Nome curto e descritivo do problema |
| Severidade | Critical / High / Medium / Low / Info |
| Recurso afetado | Nome do recurso específico (ex.: s3://minha-empresa-docs) |
| Serviço | Serviço de nuvem ou categoria do código (ex.: S3, IAM, Gosec) |
| Região | Região onde o recurso está (para nuvem) |
| Descrição | Explicação técnica detalhada do que foi encontrado |
| Impacto | O que pode acontecer se o problema não for corrigido |
| Compliance | Controles de conformidade violados (CIS, SOC2, PCI-DSS, etc.) |
| Remediação | Link para o guia de correção (CLI, Terraform, Console) |
| ID do finding | Identificador único para referenciar em tickets e allowlist |
Severidades explicadas
Critical
Riscos com potencial de exploração imediata ou impacto catastrófico:
- Bucket S3 público com dados sensíveis
- Chave AWS root com acesso programático ativo
- Instância de banco de dados exposta à internet sem senha
- Segredo (API key, senha) hardcoded no código-fonte
- Vulnerabilidade crítica (CVSS 9.0+) em dependência em produção
Ação esperada: Corrija em até 24 horas.
High
Riscos significativos que aumentam a superfície de ataque:
- Security Group com SSH aberto para 0.0.0.0/0
- MFA não habilitado para usuários IAM com console access
- Criptografia em repouso desabilitada em volumes EBS
- Dependência com CVE de severidade alta (CVSS 7.0–8.9)
Ação esperada: Corrija em até 7 dias.
Medium
Riscos moderados; desvios de boas práticas:
- CloudTrail desabilitado em regiões secundárias
- Logs de acesso do S3 não configurados
- Dependência desatualizada sem CVE ativo mas com fixes de segurança
- Ausência de tags de custo nos recursos
Ação esperada: Corrija em até 30 dias.
Low
Desvios menores de boas práticas:
- Descrição ausente em IAM Role
- Recurso sem tag de ambiente (
env=prod) - Versão do Kubernetes levemente desatualizada (sem CVE ativo)
Ação esperada: Corrija conforme disponibilidade da equipe.
Info
Observações informativas sem risco imediato:
- Recurso criado há mais de 1 ano sem uso recente
- Configuração não padrão que pode ser intencional
- Sugestão de melhoria sem implicação de segurança
Filtrando findings
Por severidade
Na barra de filtros da aba Findings, clique nos botões coloridos para incluir ou excluir severidades:
Por padrão, todos os níveis são exibidos. Clique em um botão para desativar aquela severidade.
Foco em Critical e High
Para triagem inicial, clique em "Low" e "Info" para desativá-los e focar apenas nos findings Critical e High.
Por serviço
Use o dropdown Serviço para filtrar findings de um serviço específico (ex.: apenas IAM, apenas S3, apenas EKS).
Por busca textual
O campo de busca filtra tanto pelo título do finding quanto pelo nome do recurso afetado:
- Buscar
s3://minha-empresamostra findings do bucket específico - Buscar
sshmostra todos os findings relacionados a SSH - Buscar
CVE-2024mostra findings que mencionam CVEs de 2024
Snooze — adiar um finding
O Snooze permite adiar um finding por um período específico, sem resolvê-lo ou suprimi-lo. Útil quando você sabe que vai corrigir o problema mas não tem disponibilidade imediata.
Como usar:
- Abra os detalhes do finding.
- Clique em Snooze.
- Selecione a data de retorno (ex.: 30 dias, 60 dias, ou data personalizada).
- Opcionalmente, adicione uma nota (ex.: "aguardando janela de manutenção").
- Clique em Confirmar Snooze.
Efeito do Snooze:
- O finding fica marcado como "Snoozed" com um ícone de relógio
- Não é contabilizado no score durante o período de snooze
- Na data de retorno, volta automaticamente ao status normal
- O administrador pode ver todos os findings snoozed e por quem
Snooze não é remediação
Use o snooze apenas como ferramenta de planejamento. Findings snoozed ainda aparecem nos relatórios de compliance e podem ser questionados por auditores.
Exportar findings para Jira / GitHub Issues
Para criar tickets de acompanhamento diretamente do finding:
Jira
- Abra os detalhes do finding.
- Clique em Criar Ticket → Jira.
- Selecione o projeto Jira destino, tipo de issue e responsável.
- Clique em Criar.
O ticket é criado no Jira com o título, descrição, impacto e guia de remediação do finding preenchidos automaticamente.
Pré-requisito
A integração com Jira precisa ser configurada pelo administrador em Configurações → Integrações.
GitHub Issues
- Abra os detalhes do finding.
- Clique em Criar Ticket → GitHub Issue.
- Selecione o repositório destino.
- Ajuste o título e os labels se necessário.
- Clique em Criar Issue.
Exemplos de findings comuns
AWS
| Finding | Severidade | Serviço |
|---|---|---|
| Bucket S3 com Block Public Access desabilitado | High | S3 |
| Security Group permite ingress de 0.0.0.0/0 na porta 22 | High | EC2 |
| CloudTrail não habilitado em todas as regiões | Medium | CloudTrail |
| Instância RDS sem backup automático | High | RDS |
| Usuário IAM sem MFA habilitado | High | IAM |
| Volume EBS sem criptografia | Medium | EC2 |
Código-Fonte
| Finding | Severidade | Scanner |
|---|---|---|
| API Key hardcoded no código | Critical | Gitleaks |
| Dependência com CVE crítico | Critical | OSV Scanner |
| SQL injection potencial | High | Semgrep |
| Ausência de timeout em cliente HTTP | Medium | Gosec |
| Cobertura de testes abaixo de 40% | Medium | Coverage |
| Dockerfile sem usuário não-root | High | Trivy |