Ferramentas de segurança determinísticas, a esta altura, tornaram-se uma parte tão regular da segurança que, por muito tempo, não questionávamos as alternativas. Com a IA se tornando um componente central da segurança com modelos probabilísticos, é hora de revisitar o determinismo e esclarecer para que ele é necessário. Caso contrário, por que não deveríamos simplesmente começar a substituir tudo por IA?
Em suma, precisamos do determinismo por sua previsibilidade e eficiência. Ferramentas determinísticas como SAST fornecem o mesmo resultado toda vez que você as executa na mesma coisa, de forma eficiente. Assim, são úteis em um pipeline de CI/CD, defensáveis em uma auditoria de conformidade e constroem uma base para todo o resto. A IA é ótima para raciocínio lógico, mas, devido à sua imprevisibilidade, é melhor reservada para casos em que você não precisa de resultados repetíveis.
À medida que mais ferramentas probabilísticas surgem no mercado, queremos detalhar como o determinismo cria práticas de segurança sustentáveis, como a IA oferece novas possibilidades e como as duas podem ser combinadas para o máximo impacto.
Quando as ferramentas de segurança precisam ser previsíveis
Algumas tarefas de segurança exigem consistência e auditabilidade acima de tudo. Vemos essa necessidade de previsibilidade aparecer em todo o fluxo de trabalho de segurança.
Quando um scanner sinaliza um achado, um desenvolvedor precisa confiar nele o suficiente para agir às 23h. Quando um pipeline de CI/CD bloqueia uma implantação, esse bloqueio precisa resistir ao escrutínio. Em um pipeline, seu scanner é executado em cada commit ou pull request. Se ele sinalizar 12 problemas na segunda-feira e 9 na terça-feira contra um código idêntico, isso não é bom. Os resultados do seu pipeline não são mais confiáveis. Os desenvolvedores começam a ignorar alertas porque o sinal é inconsistente, e você não pode usar a saída da varredura como um portão significativo para merges.
Da mesma forma, o teste de regressão depende da reprodutibilidade. Quando você corrige uma vulnerabilidade e reescaneia, um resultado limpo precisa significar que ela foi realmente corrigida, e não que o modelo a perdeu nesta execução. A detecção de linha de base e desvio também depende disso, pois precisam saber se um novo achado reflete uma mudança real na base de código ou apenas variação no scanner.
A previsibilidade também é necessária para a conformidade. Auditores desejam achados consistentes e explicáveis ao longo do tempo, com um registro claro do que foi detectado, quando e por quê. Um scanner que produz resultados diferentes em diferentes execuções não pode fornecer isso.
O custo prático da falta de confiabilidade na segurança degrada lentamente a confiança nas próprias ferramentas até que ninguém leve os achados a sério. Reprodutibilidade, auditabilidade e baixas taxas de falsos positivos precisam ser a linha de base na qual uma equipe de segurança pode confiar.
Ferramentas de segurança determinísticas
SAST é uma ferramenta de segurança determinística por excelência que busca padrões e vulnerabilidades conhecidos. Pense em Secrets hardcoded, CVEs conhecidas, vulnerabilidades de dependência e padrões de injeção. Ele funciona analisando o código em uma árvore de sintaxe abstrata e rastreando como os dados controlados pelo usuário se movem através da aplicação, desde os pontos de entrada até onde são usados. Um achado remonta a uma regra específica que um humano escreveu e revisou, e a regra ou corresponde ou não. Execute o mesmo scanner no mesmo código mil vezes, e você obterá os mesmos achados.
A repetibilidade é o que torna as ferramentas determinísticas bem adequadas para o início de um pipeline (elas são consistentes). Elas são auditáveis porque um humano escreveu as regras, e você pode executá-las em cada commit sem se preocupar com o custo excessivo.
DAST também se encontra no extremo determinístico do espectro. Ele executa um conjunto definido de simulação de ataques contra uma aplicação em tempo real e retorna resultados consistentes e repetíveis. É uma verificação de linha de base útil, já que é mais rápido e barato do que pentest de IA (por enquanto). Como qualquer ferramenta determinística, no entanto, ele só encontra o que tem um teste para.
Certamente não estamos dizendo que a segurança determinística, ou mesmo apenas a saída previsível, é sempre melhor. O outro lado do que torna as ferramentas determinísticas confiáveis é também onde elas são limitadas. Elas só encontram o que têm uma regra para, então padrões de ataque inovadores, falhas lógicas sutis e vulnerabilidades que exigem a compreensão do contexto de negócios ficam fora do que um scanner determinístico pode detectar.
Ferramentas determinísticas por si só também não serão capazes de dizer quais problemas são mais importantes no contexto. Algumas ferramentas determinísticas incluem Reachability analysis básica (essencialmente rastreamento de grafo de chamadas estático) que pode confirmar se uma função vulnerável é realmente chamada. Mas se quisermos saber se este achado é explorável em nossa aplicação específica, dados nossos fluxos de dados e lógica de negócios? Bem, esse tipo de Reachability analysis e priorização requer uma camada de raciocínio adicional além da correspondência de padrões.
Ferramentas de segurança probabilísticas
Graças ao surgimento dos LLMs, agora temos novas ferramentas de segurança baseadas em IA, como scanners de IA, triagem automatizada e pentesting agentic, que são de natureza probabilística. Ferramentas probabilísticas (ou ferramentas "model-first") não operam com regras fixas. Em vez disso, elas tratam o código como texto e raciocinam sobre ele.
Como não estão vinculadas a padrões fixos, uma IA segue a lógica entre funções, infere intenções e pode revelar vulnerabilidades. Falhas na lógica de negócios exigem a compreensão do que o código está tentando fazer, não apenas o que ele literalmente diz. Ferramentas probabilísticas se destacam nisso, e a IA continua a melhorar. A IA pode encontrar novas classes de vulnerabilidades e bugs dependentes de contexto que antes teriam exigido uma revisão humana habilidosa para serem encontrados.
No entanto, por sua natureza, esses modelos probabilísticos são imprevisíveis e inconsistentes. As saídas podem (e provavelmente irão) variar entre as execuções. LLMs geram saídas prevendo o próximo token mais provável com base em distribuições de probabilidade sobre seus dados de treinamento, o que significa que o mesmo input pode produzir saídas diferentes dependendo da temperatura, comportamento de amostragem e o que mais estiver na janela de contexto. Essa variação é aceitável, até útil, para pentest e para encontrar novas vulnerabilidades. Mas para seus pipelines de CI/CD, não é.
Há também um problema de custo quando se tenta usar um modelo de raciocínio probabilístico como um scanner de código abrangente em cada commit. James Berthoty, da Latio, realizou alguns testes informais que mostraram um modelo de IA probabilístico gastando 17 minutos e 155.000 tokens para identificar um problema que o Opengrep, um motor SAST determinístico, encontrou em 30 segundos. Em cada pull request em uma base de código ativa, essa troca não faz sentido.
Por que precisamos de ambos
Quando você combina modelos determinísticos e probabilísticos, no entanto, e usa cada método em suas forças, obtemos um pipeline de segurança cujo todo é maior que a soma das partes. Na prática, você quer a varredura determinística sendo executada em cada commit, detectando classes de vulnerabilidades conhecidas de forma rápida e consistente, e então o raciocínio de IA fica por cima, lidando com triagem e contexto.
Juntos, eles cobrem o espectro de "o que sabemos ser perigoso" a "o que ainda não pensamos em procurar". Esperamos que esta última categoria cresça. À medida que a IA é incorporada em mais bases de código e os atacantes ganham acesso às mesmas capacidades de raciocínio, muitas vulnerabilidades ainda não terão uma regra escrita para elas, então precisaremos de ferramentas que possam acompanhar.
Outra razão pela qual você precisa de ambas as ferramentas é que elas cobrem os mesmos problemas em diferentes níveis. DAST e pentest de IA, por exemplo, funcionam em diferentes camadas do mesmo problema. DAST se destaca em verificações rápidas e determinísticas que precisam ser executadas continuamente. Você precisa saber o mais rápido possível se possui portas abertas óbvias ou páginas que não deveriam ser públicas. O pentest de IA é mais lento e custa mais por execução, mas opera em uma profundidade fundamentalmente diferente. Um IDOR que requer três etapas autenticadas para ser alcançado não aparecerá em uma varredura DAST, mas aparecerá em um bom pentest de IA. Você pode resolver as coisas fáceis rapidamente com DAST, e então o pentest de IA acompanha as coisas mais complexas.
Como o Aikido usa ambos
Construímos o Aikido com a premissa de que a varredura determinística e alimentada por IA resolve problemas diferentes em diferentes camadas da stack. Desde o primeiro dia, optamos por usar a ferramenta que produzia os melhores resultados em cada etapa.
A fundação determinística é o Opengrep, o motor de análise de código open-source que o Aikido ajuda a liderar e manter. Além disso, desenvolvemos análise de taint e conjuntos de regras curados e precisos o suficiente para integrar diretamente em pipelines de CI/CD sem gerar ruído.
Onde amamos a segurança probabilística é em dar sentido a esses dados. O raciocínio de IA fica em cima da fundação determinística, lidando com os problemas que as regras não conseguem mapear. No Aikido, isso acontece através do AutoTriage, que fica a jusante das varreduras SAST e faz determinações sobre explorabilidade e severidade que um motor de regras não consegue fazer sozinho.
O AutoTriage é executado em duas etapas. Primeiro, o motor de alcançabilidade do Aikido filtra falsos positivos antes que um LLM sequer olhe para o código. Ele verifica se os caminhos de código vulneráveis são realmente alcançáveis, se a sanitização existe entre a fonte e o sink, e se a dependência afetada é usada em produção ou apenas em ferramentas ou pipelines. Somente esta primeira etapa suprime uma porção significativa de alertas em comparação com o scanner SAST médio.
Para os casos complexos que sobrevivem a esse filtro, modelos de raciocínio entram em ação e avaliam os fluxos de controle e dados em contexto. Internamente, descobrimos que essa abordagem identifica corretamente aproximadamente o dobro de falsos positivos em casos complexos em comparação com abordagens não baseadas em raciocínio. Uma descoberta de SQL injection pode ser seguramente rebaixada porque a entrada se origina de uma fonte upstream confiável. Uma injeção NoSQL em um endpoint de login é elevada a crítica porque o caminho de ataque é trivial e o impacto é direto.
A razão pela qual isso funciona é o controle de contexto. Executar um LLM sobre uma base de código inteira e pedir para encontrar vulnerabilidades é o que produz resultados inconsistentes. O modelo perde o fio, amplia suas suposições e sua taxa de falsos positivos aumenta. A abordagem do Aikido restringe o que a IA vê antes de raciocinar. A análise de taint rastreia como os dados controlados pelo usuário se movem através da aplicação, e a consciência de endpoint dá ao modelo o rastreamento completo da pilha e a intenção do código. Isso é uma API web? Uma ferramenta de linha de comando? O que ela deveria fazer? Com esse contexto definido, a IA não está adivinhando. Ela está avaliando uma questão específica e delimitada. É assim que você obtém o poder de raciocínio da IA sem abrir mão da reprodutibilidade.
Finalmente, como os modelos de IA são bem adequados para encontrar padrões de ataque complexos e baseados em lógica, descobrimos que são altamente eficazes para pentest. O Aikido Attack é um pentest de IA que coloca o raciocínio probabilístico para funcionar na aplicação em tempo real. Agentes completam testes em horas em vez de semanas e regularmente encontram falhas lógicas mais profundas, incluindo IDORs, bypasses de autenticação e falsificação de assinatura eletrônica, algumas das quais até mesmo testadores humanos perdem. E agora, com o Aikido Infinite, os agentes podem fazer pentest em cada release.
Para verdadeiros positivos confirmados, de SAST ou pentest, o Aikido também usa IA para raciocinar sobre a solução. O AutoFix gera um patch direcionado e abre um pull request, outra capacidade de IA que requer raciocínio e contexto para ser realizada.
No Aikido, o determinismo lida com cobertura previsível em escala. A IA lida com as decisões que as regras não conseguem tomar.
O que vem a seguir?
A segurança precisa tanto da confiabilidade determinística quanto da criatividade da IA. O determinismo oferece resultados consistentes, auditáveis e confiáveis em escala, enquanto a IA oferece profundidade, criatividade, persistência e raciocínio para eliminar falsos positivos, reduzir ruído e encontrar vulnerabilidades incomuns. Ambas as ferramentas probabilísticas e determinísticas têm limitações, mas o verdadeiro problema é quando são usadas no lugar errado. As coisas vão falhar quando você coloca um motor de raciocínio em uma tarefa que precisa de um comparador de padrões (ou vice-versa).
A direção mais ampla é mais clara do que qualquer categoria de produto individual. Ferramentas determinísticas estão melhorando porque a IA agora está sobre elas, lidando com priorização, triagem e correções que as regras sozinhas não poderiam fazer. Ferramentas probabilísticas estão melhorando na detecção de falhas lógicas complexas e novos caminhos de ataque, e, com o tempo, também se tornarão mais eficientes em termos de custo. Mas para verificações de linha de base contínuas, a economia da varredura determinística não vai desaparecer. Você quer algo rápido, consistente e barato sendo executado em cada commit, e isso ainda é um comparador de padrões.
As equipes que constroem a postura de segurança mais durável são as que usam ferramentas determinísticas e probabilísticas na ordem e nos lugares certos, não apostando em uma só.
