O lobo que grita na cibersegurança

A história do menino que gritava lobo remonta a uma fábula em que um pastor gozava com os outros aldeões, dizendo-lhes que um lobo estava a atacar o rebanho. A princípio, os aldeões acreditaram nele, mas ele estava apenas a rir-se com eles. Quando o pastor repetiu a piada, os aldeões começaram a ignorá-lo e, a dada altura, um lobo verdadeiro apareceu e atacou as ovelhas. O rapaz "gritou lobo", mas já ninguém acreditava nele.

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

Exemplo verdadeiramente positivo

O seguinte é um exemplo de uma descoberta SAST. SAST significa Static Application Security Testing, traduzido livremente como: detetar padrões perigosos no código fonte, sem executar o código. É um método poderoso para detetar muitos tipos diferentes de vulnerabilidades.

Neste exemplo, vemos o AutoTriage marcar uma amostra como "prioridade muito alta para corrigir". A descoberta do SAST aponta para uma possível vulnerabilidade NoSQL. O código representa um ponto final de início de sessão em que os utilizadores podem fornecer um nome e uma palavra-passe. É feita uma chamada à base de dados para procurar um registo correspondente ao nome e à 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 atacante poderia iniciar sessão como papa (se o papa tivesse uma conta com esse nome de utilizador nessa plataforma de software), uma vez que a palavra-passe corresponderia sempre à consulta.

Neste caso, a descoberta do SAST foi um verdadeiro positivo. O AutoTriage faz mais do que apenas confirmar aqui: também aumenta a prioridade, uma vez que esta vulnerabilidade é mais fácil de explorar e tem uma gravidade mais elevada do que a descoberta média do SAST.

Quando um problema como este é comunicado, deve corrigi-lo o mais rapidamente possível. Não existe um método mais rápido do que usar a ferramenta AutoFix do Aikido. Isto criará um pull request (ou merge request) com um clique. Neste caso, o resultado é:

O AutoFix irá sempre sugerir a correção mais simples que resolve adequadamente a vulnerabilidade. Neste caso, a substituição do nome e da palavra-passe é suficiente para proteger o ponto final e alinhar-se com a intenção do programador.

Por favor, tenha em mente que as senhas nunca devem ser comparadas diretamente e hashes de senha devem ser usados em vez disso - este exemplo foi usado por uma questão de simplicidade. O LLM utilizado pelo AutoFix é explicitamente instruído a não corrigir quaisquer outros problemas para além da vulnerabilidade reportada, por isso os pull requests seguem a melhor prática de resolver um problema de cada vez.

Exemplo de falso positivo

Como já foi referido, o verdadeiro problema das ferramentas SAST é o número de falsos alarmes que produzem. Um exemplo disso pode ser encontrado abaixo. Existe uma potencial injeção SQL em que um "productName" é injetado numa consulta SQL. Além disso, este "productName" vem do corpo do pedido, pelo que é controlado pelo utilizador. Felizmente, existe uma lista de permissões que verifica se productName é "iPhone15", "Galaxy S24", "MacBook Pro" ou "ThinkPad X1". Isso garante que productName não pode conter um payload de ataque como productName = "iPhone15'; DROP TABLE products; - - ".

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

Os modelos de linguagem de grande dimensão (LLM) oferecem uma grande oportunidade neste domínio: podem compreender muito mais contexto do código-fonte e filtrar amostras como esta.

Narrativa de segurança "sem tretas" do Aikido

Quando as empresas de software procuram fornecedores de AppSec, comparam frequentemente as diferentes soluções disponíveis no mercado. Uma forma típica de as empresas menos experientes compararem os fornecedores é contando o número de vulnerabilidades encontradas no seu código-fonte. Não será uma surpresa o facto de tenderem a acreditar que mais vulnerabilidades equivalem a melhores ferramentas. Por vezes, escolhem o seu fornecedor com base nesta má avaliação. Consequentemente, algumas empresas AppSec hesitam em filtrar os falsos positivos, uma vez que teriam um desempenho inferior nesta comparação frequente.

Na Aikido, adoptamos uma abordagem diferente. A nossa narrativa "No Bullsh*t" significa que queremos ajudar os clientes tanto quanto possível, mesmo que isso implique a perda de alguns negócios a curto prazo. O AI AutoTriage é um exemplo claro disso, uma vez que esta funcionalidade distingue a oferta da Aikido de outras no mercado.

Disponibilidade

Activámos esta funcionalidade para 50 regras SAST em diferentes linguagens, incluindo javascript/ typescript, python, java, .NET e php. Estão a ser adicionadas mais regras a um ritmo acelerado.

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

Controlo de IC

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

Imagine que você introduziu uma vulnerabilidade de path traversal em um pull request e aplicou um AutoFix. Essa correção normalmente usaria uma denylist de padrões antes de ler ou escrever o arquivo. Como as denylists são difíceis de interpretar com padrões codificados, mesmo a versão corrigida ainda seria sinalizada como um problema. Isto está agora resolvido graças à aplicação do nosso AutoTriage diretamente no pipeline de CI.

Conclusão

Lançámos uma poderosa funcionalidade para filtrar os falsos positivos do SAST e também para ajudar a dar prioridade às amostras verdadeiramente positivas. Está disponível para todos testarem, mesmo para contas gratuitas. Esta funcionalidade é um grande passo em frente na redução do efeito "Cry Wolf" na cibersegurança, ajudando os programadores a concentrarem-se no que realmente importa: resolver vulnerabilidades reais e ter mais tempo para criar funcionalidades para os seus clientes.

‍