Explicar esta Ameaça

Achados de segurança podem ser secos. Uma linha que diz “CORS aberto observado em endpoint público” ou “CVE crítica em [email protected] afetando 2 serviços” te diz o que aconteceu. Se você não é a pessoa de segurança do time, talvez ainda queira saber o que isso realmente significa e o que fazer.

Explicar esta Ameaça é uma ação inline em todo achado e todo evento que produz uma explicação em linguagem clara: o que é a condição, por que importa neste contexto, e próximos passos concretos.

O que você recebe

Cada explicação gerada tem o mesmo formato:

Descrição em linguagem clara. O que o achado ou evento é, escrito para um desenvolvedor que não é especialista em segurança.
Por que importa no seu contexto. Conectando o achado ao seu escopo específico: o serviço afetado, o projeto, a severidade e quaisquer achados relacionados.
O que fazer. Próximos passos concretos, ordenados por impacto e facilidade.
Esclarecimento sobre o escopo. Onde apropriado, esclarecimento explícito sobre o que o achado de fato significa neste contexto específico, para você dimensionar a resposta corretamente.

A explicação é escrita para ser útil por conta própria; você deve conseguir encaminhá-la a um colega e que ele aja sem mais contexto.

Como o escopo do modelo é limitado

Esta é a parte mais importante de como Explicar esta Ameaça funciona:

Segredos brutos ficam fora do modelo. Achados de exposição de segredos chegam à explicação apenas como evidência redigida. O valor do segredo em si nunca está no prompt.
Bodies brutos de requisição e resposta ficam fora do modelo. As verificações de serviço não armazenam bodies, então a explicação só vê o que já está anexado como evidência.
Conteúdo de logs do cliente fica fora do modelo. Achados referenciam serviços, não logs.
Cada explicação roda no escopo de uma única conta. O modelo vê apenas o achado e a evidência limitada anexada a ele.

Se a evidência de um achado já é redigida (por exemplo, para uma exposição de segredo), a explicação opera sobre a evidência redigida. O modelo recebe exatamente o que você consegue ver no dashboard, e nada além disso.

Quando usar

Explicar esta Ameaça é mais útil quando:

Você está triando um tipo de achado que nunca viu antes.
Você está repassando um achado a um colega que não está no plantão de segurança.
Você quer uma segunda opinião sobre severidade antes de decidir entre suprimir, reconhecer ou corrigir.
Você está escrevendo uma nota pós-incidente e quer um parágrafo em linguagem clara para colocar no documento.

É menos útil quando:

Você já sabe exatamente o que o achado significa e o que fazer. (Não gere explicações para ruído. Tecnicamente não custa nada, mas dilui o valor das que você gera.)
O achado é um estado transitório já resolvido. A explicação continua correta, mas a ação é “não fazer nada”.

Gerando e regerando

Quando você abre o detalhe de um achado ou evento, a ação inline ou mostra a explicação existente (se já gerada) ou oferece gerar uma. Você também pode explicitamente regerar a explicação, o que é útil quando o achado foi atualizado com nova evidência desde a última explicação.

Cada geração grava uma entrada de auditoria security.threat_explanation.generated, para que você possa auditar quem pediu quais explicações sem adicionar ruído à linha do tempo de Eventos de Segurança.

Para onde ir agora

Leia a caixa de entrada onde a ação vive: Achados de Segurança.
Revise a atividade de explicações geradas nos logs de auditoria da conta.
Para uma visão agregada que sumariza temas em muitos achados: Relatórios e Postura.