Gritar «lobo» na cibersegurança

O menino que gritava «lobo» remonta a uma fábula em que um pastor zombava dos outros aldeões, dizendo-lhes que um lobo estava a atacar o rebanho. No início, os aldeões acreditavam nele, mas ele estava apenas a brincar com eles. Quando o pastor repetiu a sua piada, os aldeões começaram a ignorá-lo e, a certa altura, um lobo verdadeiro apareceu e atacou as ovelhas. O menino gritou «lobo», mas já ninguém acreditava nele.

As ferramentas de cibersegurança têm atuado como pastores: tendem a dar muitos alarmes falsos, o que cansa os programadores e os faz perder a atenção. Isso faz com que os programadores percam tempo e confiança nas ferramentas. Para trabalhar de forma eficiente e eficaz em cibersegurança, é necessário um bom filtro para evitar esses falsos positivos. É exatamente isso que o AutoTriage faz para SAST .

Exemplo verdadeiro positivo

A seguir, apresentamos um exemplo de um SAST . SAST Testes de segurança de aplicações estáticas, traduzido livremente como: detectar padrões perigosos no código-fonte, sem executar o código. É um método poderoso para sinalizar muitos tipos diferentes de vulnerabilidades.

Neste exemplo, vemos o AutoTriage a marcar uma amostra como «prioridade muito alta para correção». A SAST aponta para uma potencial vulnerabilidade NoSQL. O código representa um ponto final de login onde os utilizadores podem fornecer um nome e uma palavra-passe. Há uma chamada para a base de dados para procurar um registo correspondente tanto para o nome como para a palavra-passe.

The problem here is that NoSQL allows you to insert objects like { $ne: undefined }. In that case, the match will be based on anything that is different from undefined. Imagine that an attacker would upload something like this:

{
	name: LeoIVX,  
    password: { $ne: undefined }
}

Nesse caso, o invasor conseguiria fazer login como o papa (se o papa tivesse uma conta com esse nome de utilizador nessa plataforma de software), uma vez que a palavra-passe sempre corresponderia à consulta.

Neste caso, a SAST foi realmente positiva. O AutoTriage faz mais do que apenas confirmar aqui: ele também aumenta a prioridade, uma vez que essa vulnerabilidade é mais fácil de explorar e tem uma gravidade maior do que a média SAST .

Quando um problema como este é relatado, deve corrigi-lo o mais rápido possível. Não há método mais rápido do que usar a ferramenta AutoFix Aikido. Isso criará uma solicitação pull (ou solicitação de mesclagem) com um clique. Neste caso, o resultado é:

O AutoFix sempre sugerirá a correção mais simples que resolva adequadamente a vulnerabilidade. Neste caso, basta converter o nome e a palavra-passe para proteger o terminal e alinhar com a intenção do programador.

Tenha em mente que as palavras-passe nunca devem ser comparadas diretamente e que, em vez disso, devem ser utilizados hashes de palavras-passe — este exemplo foi utilizado por uma questão de simplicidade. O LLM utilizado pelo AutoFix tem instruções explícitas para não corrigir quaisquer outros problemas além da vulnerabilidade relatada, para que os pedidos de pull sigam a melhor prática de resolver um problema de cada vez.

Exemplo de falso positivo

Como mencionado anteriormente, o verdadeiro problema das SAST é o número de falsos alarmes que elas produzem. Um exemplo disso pode ser encontrado abaixo. Há uma potencial injeção SQL em que um «productName» é injetado numa consulta SQL. Além disso, esse «productName» vem do corpo da solicitação, portanto, é controlado pelo utilizador. Felizmente, existe uma lista de permissões que verifica se o productName é “iPhone15”, “Galaxy S24”, “MacBook Pro” ou “ThinkPad X1”. Isso garante que o productName não possa conter uma carga útil de ataque como productName = “iPhone15’; DROP TABLE products; - - ”.

Uma lista de permissões como a apresentada neste exemplo é uma contramedida eficaz contra injeções SQL. Mas scanners antigos, como o Semgrep não conseguem avaliar a eficácia dessas listas de permissões.

Os modelos de linguagem de grande porte (LLMs) oferecem uma grande oportunidade aqui: eles podem compreender muito mais do contexto do código-fonte e filtrar amostras como esta.

A narrativa Aikidosobre «segurança sem tretas»

Quando as empresas de software procuram AppSec , muitas vezes comparam as diferentes soluções disponíveis no mercado. Uma forma típica de como as empresas menos experientes comparam os fornecedores é contando o número de vulnerabilidades encontradas no seu código-fonte. Não é surpresa que elas tendam a acreditar que mais vulnerabilidades equivalem a melhores ferramentas. Às vezes, elas escolhem o seu fornecedor com base nessa avaliação inadequada. Consequentemente, algumas AppSec hesitam em filtrar falsos positivos, pois teriam um desempenho inferior nessa comparação frequentemente vista.

Na Aikido, adotamos uma abordagem diferente. A nossa narrativa «Sem tretas» significa que queremos ajudar os clientes tanto quanto possível, mesmo que isso signifique perder alguns negócios a curto prazo. O AI AutoTriage é um exemplo claro disso, uma vez que esta funcionalidade diferencia a oferta Aikidodas outras no mercado.

Disponibilidade

Ativámos esta funcionalidade para 91 SAST em diferentes linguagens, incluindo javascript/typescript, python, java, .NET e php. Mais regras estão a ser adicionadas a um ritmo acelerado.

Esta funcionalidade está ativada para todos, incluindo contas gratuitas. No entanto, as contas gratuitas podem atingir facilmente o número máximo de chamadas LLM.

CI Gating

O CI gating é o processo em que Aikido vulnerabilidades em cada pull request. O AI AutoTriage agora também está habilitado para esse recurso, o que torna o fluxo de trabalho muito mais conveniente.

Imagine que introduziu uma vulnerabilidade de traversal de caminho numa solicitação pull e aplicou uma AutoFix. Essa correção normalmente usaria uma lista de padrões negados antes de ler ou gravar o ficheiro. Como as listas negadas são difíceis de interpretar com padrões codificados, mesmo a versão corrigida ainda seria sinalizada como um problema. Isso agora está resolvido graças à aplicação do nosso AutoTriage diretamente no pipeline de CI.

Conclusão

Lançámos um recurso poderoso para filtrar SAST falsos positivos SAST e também ajudar na priorização das amostras verdadeiras positivas. Ele está disponível para todos testarem, mesmo para contas gratuitas. Esse recurso é um grande passo à frente na redução do efeito «Cry Wolf» na segurança cibernética, ajudando os programadores a se concentrarem no que realmente importa: resolver vulnerabilidades reais e ter mais tempo para criar recursos para os seus clientes.