Por que a lista de achados não é priorização
Uma avaliação de postura sobre um patrimônio multicloud típico devolve dezenas de milhares de achados. A severidade emitida pelo verificador é uma propriedade da regra, não do ambiente: o mesmo controle vale o mesmo em uma conta de laboratório sem rota externa e em uma conta de produção com dado regulado.
Priorização exige contexto de alcance. Um achado só é acionável quando se sabe quem pode explorá-lo, a partir de onde e o que ele alcança depois de explorado.
As quatro camadas que precisam convergir
Um CNAPP entrega valor quando as quatro camadas escrevem no mesmo modelo de dados e se referenciam pelo mesmo identificador de recurso.
- Postura (CSPM): desvio de configuração frente a benchmark e política interna
- Direito de acesso (CIEM): princípios, papéis e permissões efetivas, não declaradas
- Workload (CWPP): vulnerabilidade em imagem, pacote em execução e comportamento de runtime
- Dado: classificação, sensibilidade e exposição efetiva de armazenamento
Permissão efetiva contra permissão declarada
A diferença entre a política escrita e o acesso efetivamente alcançável é onde a maior parte do risco de nuvem se acumula. Cadeias de assunção de papel, políticas de recurso, limites de permissão e federação de identidade compõem um alcance que nenhum documento descreve integralmente.
O cálculo de permissão efetiva percorre essas cadeias e devolve o conjunto real de recursos alcançáveis por princípio. É esse conjunto — não a política — que deve ser comparado ao princípio do menor privilégio.
Da exposição ao caminho de ataque
Um caminho de ataque é uma sequência verificável: ponto de entrada exposto, vulnerabilidade explorável em execução, credencial alcançável a partir do workload e recurso sensível ao final da cadeia. Cada elo é evidência estrutural derivada do inventário, não inferência.
Quando os caminhos são ordenados por sensibilidade do destino e por facilidade do ponto de entrada, a fila resultante costuma conter dezenas de itens, não dezenas de milhares. É uma fila que uma equipe de plataforma consegue drenar em ciclos de sprint.
Remediação com dono e prazo
A correção pertence a quem opera o recurso. O CNAPP deve derivar o responsável a partir da tag de propriedade, do repositório de infraestrutura como código e do histórico de deploy, e abrir o item diretamente no fluxo de trabalho da equipe dona — não em uma fila genérica de segurança.
Remediação verificável fecha o ciclo: o achado só é encerrado quando a próxima coleta confirma o estado corrigido na fonte, com registro de quem alterou e quando.