As ferramentas de segurança determinísticas, neste momento, tornaram-se uma parte tão comum da segurança que, durante muito tempo, não questionámos as alternativas. Com a IA a tornar-se 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 devemos simplesmente começar a substituir tudo pela IA?
Em suma, precisamos do determinismo pela sua previsibilidade e eficiência. Ferramentas determinísticas como SAST o mesmo resultado sempre que são executadas na mesma coisa, de forma eficiente. Portanto, elas são úteis num pipeline de CI/CD, defensáveis numa auditoria de conformidade e constituem uma base para tudo o resto. A IA é excelente no raciocínio lógico, mas, devido à sua imprevisibilidade, é melhor reservá-la para casos em que não são necessários resultados repetíveis.
À medida que mais ferramentas probabilísticas aparecem no mercado, queremos analisar como o determinismo cria práticas de segurança sustentáveis, como a IA oferece novas possibilidades e como os dois podem ser combinados para obter 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 uma descoberta, um programador precisa confiar nela o suficiente para agir às 23h. Quando um pipeline de CI/CD bloqueia uma implementação, esse bloqueio precisa resistir a um escrutínio rigoroso. Em um pipeline, o scanner é executado em cada commit ou pull request. Se ele sinalizar 12 problemas na segunda-feira e 9 na terça-feira em um código idêntico, isso não é bom. Os resultados do seu pipeline deixam de ser confiáveis. Os programadores começam a ignorar os alertas porque o sinal é inconsistente e você não pode usar a saída da verificação como um gate significativo nas mesclagens.
Da mesma forma, os testes de regressão dependem da reprodutibilidade. Quando se corrige uma vulnerabilidade e se faz uma nova verificação, um resultado limpo precisa significar que ela foi realmente corrigida, e não que o modelo não a detectou nesta execução. A deteção de linha de base e desvio também dependem disso, pois precisam saber se uma nova descoberta reflete uma mudança real na base de código ou apenas uma variação no scanner.
A previsibilidade também é necessária para a conformidade. Os auditores querem resultados consistentes e explicáveis ao longo do tempo, com um registo claro do que foi detetado, quando e porquê. Um scanner que produz resultados diferentes em execuções diferentes 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 mais leve os resultados a sério. Reprodutibilidade, auditabilidade e baixas taxas de falsos positivos precisam ser a base na qual uma equipa de segurança pode confiar.
Ferramentas de segurança determinísticas
SAST uma ferramenta de segurança determinística por excelência que procura padrões e vulnerabilidades conhecidos. Pense em secrets codificados, CVEs conhecidos, 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 utilizador se movem pelo aplicativo, desde os pontos de entrada até onde são usados. Uma descoberta remete a uma regra específica que um ser humano escreveu e revisou, e a regra corresponde ou não. Execute o mesmo scanner no mesmo código mil vezes e você obterá as mesmas descobertas.
A repetibilidade é o que torna as ferramentas determinísticas adequadas para a parte inicial de um pipeline (elas são consistentes). Elas são auditáveis porque as regras foram escritas por humanos, e você pode executá-las em cada commit sem se preocupar com custos excessivos.
DAST também DAST na extremidade determinística do espectro. Ele executa um conjunto definido de simulações de ataque contra uma aplicação ativa e retorna resultados consistentes e repetíveis. É uma verificação de base útil, pois é mais rápida e barata do que pentest de IA por enquanto). Como qualquer ferramenta determinística, porém, ela só encontra aquilo para o qual tem um teste.
Certamente não estamos a dizer que a segurança determinística, ou mesmo apenas resultados previsíveis, sejam sempre melhores. O reverso da moeda do que torna as ferramentas determinísticas confiáveis é também onde elas são limitadas. Elas só encontram aquilo para o qual têm uma regra, portanto, novos padrões de ataque, falhas lógicas sutis e vulnerabilidades que exigem a compreensão do contexto empresarial estão fora do alcance de um scanner determinístico.
Ferramentas determinísticas por si só também não serão capazes de indicar quais questões são mais importantes no contexto. Algumas ferramentas determinísticas incluem reachability analysis básica reachability analysis essencialmente rastreamento estático de gráficos de chamadas) que pode confirmar se uma função vulnerável é realmente chamada. Mas se quisermos saber se essa descoberta é explorável na nossa aplicação específica, considerando os nossos fluxos de dados e lógica de negócios? Bem, esse tipo de reachability analysis priorização requer uma camada de raciocínio além da correspondência de padrões.
Ferramentas de segurança probabilística
Graças ao surgimento dos LLMs, agora temos novas ferramentas de segurança baseadas em IA, como scanners de IA, triagem automatizada e testes de penetração agênicos, que são probabilísticos por natureza. Ferramentas probabilísticas (ou ferramentas model-first) não operam com regras fixas. Em vez disso, tratam o código como texto e raciocinam sobre ele.
Como não estão vinculadas a padrões fixos, as IAs seguem a lógica entre funções, inferem intenções e podem revelar vulnerabilidades. As falhas na lógica de negócios exigem a compreensão do que o código está a tentar fazer, não apenas o que ele diz literalmente. As ferramentas probabilísticas se destacam nisso, e a IA continua a melhorar. A IA pode encontrar novas classes de vulnerabilidades e bugs dependentes do contexto que antes exigiriam uma revisão humana habilidosa para serem encontrados.
No entanto, por sua natureza, esses modelos probabilísticos são imprevisíveis e inconsistentes. Os resultados podem (e provavelmente irão) variar entre as execuções. Os LLMs geram resultados prevendo o próximo token mais provável com base nas distribuições de probabilidade sobre os seus dados de treino, o que significa que a mesma entrada pode produzir resultados diferentes dependendo da temperatura, do comportamento de amostragem e do que mais estiver na janela de contexto. Essa variação é aceitável, e até útil, para testes de penetração e para encontrar novas vulnerabilidades. Mas para os 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 geral em cada commit. James Berthoty, da Latio, fez alguns testes informais que mostraram que um modelo de IA probabilístico levou 17 minutos e 155.000 tokens para detectar um problema que o Opengrep, um SAST determinístico, encontrou em 30 segundos. Em todas as solicitações de pull em uma base de código ativa, essa troca não faz sentido.
Por que precisamos dos dois
No entanto, quando se combinam modelos determinísticos e probabilísticos e se utiliza cada método de acordo com os seus pontos fortes, obtém-se um pipeline de segurança cujo todo é maior do que as partes. Na prática, é desejável que a verificação determinística seja executada em cada commit, detectando classes de vulnerabilidades conhecidas de forma rápida e consistente, e que o raciocínio da IA fique no topo, lidando com a triagem e o contexto.
Juntas, elas cobrem o espectro que vai de «o que sabemos ser perigoso» a «o que ainda não pensámos em procurar». Esperamos que a última categoria cresça. À medida que a IA é incorporada em mais bases de código e os invasores ganham acesso às mesmas capacidades de raciocínio, muitas vulnerabilidades ainda não terão uma regra escrita para elas, por isso precisaremos de ferramentas que possam acompanhar essa evolução.
Outra razão pela qual precisa das duas ferramentas é que elas cobrem as mesmas questões em níveis diferentes. DAST pentest de IA, por exemplo, trabalham em camadas diferentes do mesmo problema. DAST em verificações rápidas e determinísticas que precisam ser executadas continuamente. Precisa saber o mais rápido possível se tem portas abertas óbvias ou páginas que não deveriam ser públicas. 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á numa DAST , mas aparecerá num bom pentest de IA. Pode resolver rapidamente as coisas fáceis com DAST e, em seguida, pentest de IA continuidade com as coisas mais complexas.
Como Aikido ambos
Criámos Aikido premissa de que a análise determinística e a análise baseada em IA resolvem problemas diferentes em diferentes camadas da pilha. Desde o primeiro dia, optámos por utilizar a ferramenta que produzia os melhores resultados em cada etapa.
A base determinística é o Opengrep, o mecanismo de análise de código aberto que Aikido liderar e manter. Além disso, desenvolvemos análises de contaminação e conjuntos de regras selecionados com precisão suficiente para serem integrados diretamente em pipelines de CI/CD sem gerar ruído.
Onde adoramos a segurança probabilística é na compreensão desses dados. O raciocínio da IA assenta sobre uma base 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 SAST e toma decisões sobre a explorabilidade e a gravidade que um motor de regras não consegue tomar sozinho.
O AutoTriage funciona em duas etapas. Primeiro, o mecanismo de acessibilidade Aikido filtra os falsos positivos antes que um LLM analise o código. Ele verifica se os caminhos de código vulneráveis são realmente acessíveis, se existe sanitização entre a fonte e o destino e se a dependência afetada é usada na produção ou apenas em ferramentas ou pipelines. Só esta primeira etapa suprime uma parte significativa dos alertas em comparação com o SAST médio.
Para os casos complexos que sobrevivem a esse filtro, os modelos de raciocínio entram em ação e avaliam os fluxos de controlo e dados no contexto. Internamente, descobrimos que essa abordagem identifica corretamente cerca de duas vezes mais falsos positivos em casos complexos em comparação com abordagens sem raciocínio. Uma descoberta de injeção SQL pode ser rebaixada com segurança porque a entrada se origina de uma fonte upstream confiável. Uma injeção NoSQL em um ponto final de login é atualizada para crítica porque o caminho do ataque é trivial e o impacto é direto.
A razão pela qual isso funciona é o controlo do contexto. Executar um LLM em toda a base de código e pedir que ele encontre vulnerabilidades é o que produz resultados inconsistentes. O modelo perde o fio da meada, amplia as suas suposições e a sua taxa de falsos positivos aumenta. A abordagem Aikido restringe o que a IA vê antes mesmo de raciocinar. A análise de contaminação rastreia como os dados controlados pelo utilizador se movem pelo aplicativo, e o reconhecimento de endpoint fornece ao modelo o rastreamento completo da pilha e a intenção do código. É uma API da web? Uma ferramenta de linha de comando? O que ela deve fazer? Com esse contexto definido, a IA não fica adivinhando. Ela avalia 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.
Por fim, como os modelos de IA são adequados para encontrar padrões de ataque complexos e baseados em lógica, descobrimos que eles são altamente eficazes para testes de penetração. Aikido é pentest de IA aplica o raciocínio probabilístico à aplicação ao vivo. Os agentes concluem os testes em horas, em vez de semanas, e encontram regularmente falhas lógicas mais profundas, incluindo IDORs, contornamentos de autenticação e falsificação de assinaturas eletrónicas, algumas das quais até mesmo os testadores humanos deixam passar. E agora, com Aikido , os agentes podem realizar testes de penetração em cada lançamento.
Para verdadeiros positivos confirmados, provenientes SAST do pentesting, Aikido usa IA para raciocinar sobre a solução. O AutoFix gera um patch direcionado e abre uma solicitação pull, outra capacidade da IA que requer raciocínio e contexto para ser executada.
No Aikido, o determinismo lida com a cobertura previsível em escala. A IA lida com as decisões que as regras não podem tomar.
O que vem a seguir?
A segurança precisa tanto de confiabilidade determinística quanto de 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ídos e encontrar vulnerabilidades incomuns. Tanto as ferramentas probabilísticas quanto as determinísticas têm limitações, mas o verdadeiro problema é quando elas são usadas no lugar errado. As coisas vão dar errado quando você coloca um mecanismo 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. As ferramentas determinísticas estão a melhorar porque agora a IA está acima delas, lidando com priorização, triagem e correções que as regras sozinhas não poderiam fazer. As ferramentas probabilísticas estão a melhorar na deteção de falhas lógicas complexas e novos caminhos de ataque e, com o tempo, também se tornarão mais econômicas. Mas, para verificações contínuas da linha de base, a economia da verificação determinística não vai desaparecer. Você quer algo rápido, consistente e barato a funcionar em cada commit, e isso ainda é um comparador de padrões.
As equipas que constroem a postura de segurança mais duradoura são aquelas que utilizam ferramentas determinísticas e probabilísticas na ordem certa e nos locais certos, sem apostar apenas numa delas.
