A segurança da IA precisa de uma segunda opinião

A IA está escrevendo software mais rápido do que conseguimos protegê-lo. Você está acompanhando esse ritmo?

Até você terminar de ler esta frase, desenvolvedores e seus agentes de IA terão enviado alguns milhares de commits de código. Nesta mesma época do ano passado, seriam cerca de 150.

No último ano, o desenvolvimento de software gerado por IA avançou a um ritmo impressionante. O GitHub registrou 7,38 bilhões de commits somente em setembro de 2026, mais de cinco vezes o total de um ano antes. As implicações dessa explosão para a segurança são profundas. Cada um desses commits contém código que alguém deveria compreender, manter e proteger. A Cloud Security Alliance constatou que desenvolvedores que usam IA em empresas da Fortune 50 enviam código a uma taxa três a quatro vezes maior que a de seus colegas, enquanto o número mensal de achados de segurança aumentou cerca de dez vezes.

Agora, pense em quem terá de lidar com esse aumento. A equipe do CISO tem o mesmo tamanho que tinha há um ano, mas o acúmulo de tarefas, não. O número de vulnerabilidades reportadas está aumentando, as correções mensais estão diminuindo e os problemas críticos ainda não resolvidos estão se acumulando. Não é de surpreender que, segundo a Gartner, o esgotamento dos CISOs esteja se tornando um risco operacional crítico.

A tentação de usar o modelo mais recente

Quando o número é tão alto, a tendência é perseguir um número ainda maior: mais achados, maior cobertura, mais varreduras. Mas isso é como tentar esvaziar um barco que está afundando e pedir um balde maior, quando o que você precisa é encontrar o vazamento. O sucesso de um programa de segurança não se mede pela quantidade de problemas que encontra. Mede-se pela proporção dos achados que são reais e por quantos dos mais críticos são de fato corrigidos.

Os modelos de IA de ponta são extraordinários para encontrar explorações inéditas e falhas ainda não catalogadas por meio de raciocínio probabilístico. Mas os resultados variam. Segundo uma pesquisa da Checkmarx, ao executar a mesma varredura no mesmo código cinco vezes, os achados coincidem em apenas cerca de um terço das vezes.

É por causa dessa inconsistência que a análise baseada em regras continua sendo importante. Ela é menos flexível que a IA de ponta, mas aplica uma lógica comprovada da mesma maneira todas as vezes, permitindo que as equipes confiem nos resultados e os verifiquem. A IA detecta o que as regras não percebem, como fragilidades conhecidas que aparecem de formas inesperadas ou falhas que só se tornam exploráveis quando diferentes partes do código interagem. Juntas, a IA e a análise baseada em regras revelam mais problemas relevantes e geram menos falsos alarmes.

Nada disso é um argumento contra a IA. É um argumento a favor de uma segunda opinião na segurança. Seja qual for o mecanismo escolhido, avalie-o com base em três perguntas.

Primeira pergunta: fidelidade

Quando o scanner aponta um problema, vale a pena dedicar tempo a ele?

Fidelidade significa confiança. Um achado que não é real custa uma tarde de trabalho a um desenvolvedor e reduz ainda mais a credibilidade da equipe de segurança. Em grande escala, os falsos positivos fazem as equipes deixarem de prestar atenção. Os alertas passam a ser vistos como alguém que “grita lobo” e acabam se perdendo no ruído de fundo.

É aqui que a consistência importa. A análise determinística fornece sempre a mesma resposta para o mesmo código, o que gera confiança e permite auditar os resultados.

Segunda pergunta: precisão

Você está encontrando o conjunto completo dos problemas mais importantes?

A fidelidade indica se vale a pena dedicar tempo a um achado, mas não revela o que o scanner deixou passar. Usamos uma métrica prática, originada na ciência de dados, chamada pontuação F1. A pontuação F1 avalia o desempenho em uma escala de 1 a 0, com base em dois fatores:

• Precisão: a proporção dos achados reportados que são reais. Uma precisão alta significa menos falsos alarmes.
• Revocação: a proporção das vulnerabilidades reais que o scanner efetivamente encontra. Uma revocação alta significa que poucos problemas passam despercebidos.

Um scanner pode parecer preciso ao sinalizar quase nada ou minucioso ao sinalizar tudo; em ambos os casos, a pontuação F1 será baixa. A média do setor é de aproximadamente 0,20. Temos trabalhado muito para enfrentar esse desafio e obtivemos resultados com uma precisão três a quatro vezes maior que a de um scanner padrão.

Uma precisão maior facilita todas as etapas seguintes para os desenvolvedores. Sua equipe passa menos tempo validando e mais tempo corrigindo problemas.

Terceira pergunta: retorno sobre o investimento (ROI)

Como podemos maximizar o investimento e os recursos?

Essa é a pergunta que mais costuma ser ignorada durante o projeto-piloto e cuja resposta é mais dolorosa em produção.

Os modelos de ponta cobram por token, e os tokens são consumidos independentemente de a varredura encontrar algo. Analisar um repositório com um milhão de linhas custa mais de mil dólares, com base nos preços atualmente divulgados. Além disso, há uma grande diferença no consumo de tokens entre os modelos: o preço varia conforme o modelo escolhido e a quantidade de raciocínio necessária para concluir a tarefa.

Multiplique esse custo por todos os commits, pull requests e repositórios de uma empresa. A Uber, que gasta US$ 3,4 bilhões por ano em P&D, teria esgotado todo o seu orçamento de IA para 2026 poucos meses após implementar ferramentas de programação com IA.

Chamamos isso de imposto sobre tokens. É como usar uma Ferrari para fazer compras: você paga por uma potência de que a viagem não precisa. Credenciais codificadas diretamente e injeção de SQL são padrões previsíveis que a análise determinística identifica com confiabilidade.

A segurança de aplicações precisa evoluir

Essa é a lógica por trás da arquitetura do Checkmarx Fusion. Mecanismos baseados em regras estabelecem uma verdade de referência de forma reproduzível e a um custo menor do que a análise baseada em tokens. Os modelos de ponta são direcionados ao que as regras não conseguem prever: padrões inéditos, lógica complexa e explorabilidade no contexto. Em seguida, uma camada de análise dos achados combina os resultados em um único conjunto confiável.

A análise determinística oferece certeza. A IA amplia o alcance. Cobertura e confiabilidade aumentam juntas. Em comparação com um LLM trabalhando sozinho, observamos até quatro vezes mais fidelidade, de duas a quatro vezes mais precisão e cerca de um terço do custo.

Encontrar problemas é apenas o começo. A mesma lógica se aplica à prevenção. Vejamos um exemplo. Ao capacitar os desenvolvedores no momento da criação, no IDE em que escrevem o código, podemos impedir que os problemas surjam. Da mesma forma, quando se trata das vulnerabilidades que passam pelas defesas, por que não oferecer aos desenvolvedores correções prontas para serem incorporadas, priorizando as mais importantes? É para resolver esses desafios que estamos trabalhando, com o objetivo de reduzir gradualmente o acúmulo de pendências e gerar o impacto mais rápido possível com o mínimo de esforço.

O código está em execução. Você consegue acompanhar?

A IA deu aos atacantes o presente da velocidade. Para fechar essa lacuna, não basta adicionar mais uma ferramenta. É preciso decidir como toda a sua organização desenvolve e protege software. O código escrito hoje conduzirá seus negócios por anos. Para os líderes de segurança, a questão já não é quanto a IA acelera o desenvolvimento, mas se seus programas conseguem acompanhar o ritmo do que ela cria.

Portanto, não se perca nos números. Faça três perguntas sobre qualquer programa: posso confiar no que ele encontra? Ele encontra o suficiente do que realmente importa? É viável implementá-lo em toda a minha organização? Combinar a precisão determinística com o raciocínio dos modelos de ponta oferece a melhor chance de responder sim às três perguntas.

O desenvolvimento de software não está desacelerando. Nossa tarefa agora é reduzir a lacuna de risco: a distância entre a velocidade com que o software é criado e a velocidade com que os riscos são encontrados e corrigidos.