A IA muda a construção de software, não quem garante sua segurança

Mais código implica mais vulnerabilidades, mesmo com ferramentas melhores

Existe uma suposição tentadora por trás de cada avanço em segurança automatizada: a de que uma detecção melhor acabará por fechar a lacuna. Mas as proporções não fecham. À medida que a IA acelera o desenvolvimento, o volume total de código produzido cresce mais rápido do que qualquer melhoria na detecção consegue compensar.

Isso significa que o desafio de segurança não está diminuindo; está se acumulando. E está se acumulando num ambiente onde a maioria das equipes começa a pensar em segurança depois da ida para a produção, não antes. Volta-se ao padrão de construir primeiro e avaliar o risco depois, o que implica que as vulnerabilidades chegam à produção antes que alguém as tenha avaliado. Quando se combina esse hábito com a velocidade sem precedentes com que o código agora vai da saída de um agente a um deploy em produção, os testes em produção se tornam essenciais.

Existe também uma suposição perigosa se formando em torno da remediação assistida por IA. Como os agentes de IA já conseguem detectar uma vulnerabilidade e propor uma remediação no mesmo fluxo de trabalho, alguns vão concluir que o ciclo está fechado: o agente escreve o código, encontra os bugs e os corrige. O código deve ser seguro. Mas não será. Um agente que remedia o próprio output não garante um resultado seguro, e sim um ciclo mais rápido que ainda precisa de validação.

A IA muda o processo, não o responsável

Na Fluid Attacks, enquadramos a mudança atual da seguinte forma: "A IA constrói. Os humano lidera. Nós seguramos". A ênfase em "lidera" é proposital. Os agentes de IA estão transformando cada etapa do desenvolvimento de software, desde a escrita de código até os testes e as propostas de remediação; no entanto, a responsabilidade pela segurança não se transfere ao agente. Os humanos continuam no controle. São eles que definem o que será construído, que estabelecem a tolerância ao risco e que respondem quando algo dá errado.

Se o agente pode codificar, escanear e remediar, por que envolver humanos? A resposta é que a segurança é uma decisão de julgamento que depende de um contexto que o agente não possui por completo: a lógica de negócio da aplicação, o modelo de ameaças da organização, os requisitos regulatórios da indústria, a tolerância ao risco. Essas são decisões humanas.

Além disso, há o caso dos falsos negativos. Sabemos que os falsos positivos, por sua vez, perderão um pouco de seu impacto num mundo em que a velocidade de desenvolvimento torna a remediação mais barata e ágil, mesmo quando se trata de alarmes falsos. Mas um falso negativo, uma vulnerabilidade real que passa despercebida, é sempre relevante. Ele representa risco não gerenciado e um vetor aberto de ataque. É por isso que os testes em camadas, que combinam raciocínio com IA, análise determinística de código-fonte, testes dinâmicos e revisão humana, não são um luxo: são a única abordagem que minimiza os pontos cegos que qualquer método isolado inevitavelmente apresenta.

Os nossos pentesters já experimentaram ferramentas de IA para ampliar o próprio trabalho, e nós resumimos essa sinergia assim: Os humanos pensam estrategicamente; os agentes executam em larga escala. O agente escala a execução, roda testes em paralelos, analisa repositórios inteiros e gera candidatos de vulnerabilidades. O humano traz o pensamento estratégico, a criatividade para encontrar caminhos que nenhum modelo antecipa e o julgamento para confirmar se uma vulnerabilidade é explorável no contexto do sistema real em operação.

Um cenário em transformação exige uma visão mais ampla

Embora seja tentador se concentrar no que o Claude Code Security faz e não faz, a conversa mais importante diz respeito às mudanças mais amplas que estão reconfigurando o desenvolvimento de software e, por consequência, a segurança de aplicações.

O papel do desenvolvedor está evoluindo de escrever código a instruir agentes, definir requisitos e validar resultados. Acreditamos que as ferramentas também estão se mudando, é bem provável que os ambientes de desenvolvimento integrados (IDEs) cedam espaço a interfaces de linha de comando com agentes e eventualmente a ambientes onde os grandes modelos de linguagem (LLMs) funcionem como um cérebro com acesso à área de trabalho do desenvolvedor. As próprias máquinas dos desenvolvedores podem se tornar os sandboxes onde as aplicações são testadas. Não se trata de cenários distantes, mas da direção para a qual os primeiros adotantes já estão caminhando.

Ao mesmo tempo, as arquiteturas das aplicações estão se tornando mais distribuídas. As APIs proliferam. Os servidores de protocolo de contexto de modelo (MCP) surgem como novos componentes na forma como os sistemas se interconectam. Os LLMs e os modelos de IA se tornam atores na cadeia de suprimentos de software, com um papel cada vez mais crítico tanto no desenvolvimento quanto na produção. Novas interfaces de usuário, como chat e voz, introduzem categorias de fraquezas que não existiam há poucos anos.

Tudo isso gera superfícies de ataque mais dinâmicas e difíceis de gerenciar. E uma ferramenta que lê código-fonte, por mais inteligentemente que seja, trata de apenas uma das camadas desse cenário. Um código com sintaxe perfeita ainda pode ser vulnerável. Uma aplicação cujo código-fonte passa em todas as verificações de análise estática ainda pode ser explorável se o seu ambiente de execução estiver mal configurado, se a sua infraestrutura tiver lacunas ou se as interações entre os seus componentes introduzirem falhas que só se manifestam quando o sistema está realmente em execução.

Testando o sistema como um todo

É isto que acreditamos que a conversa precisa colocar no centro, e é o princípio que guia nosso trabalho na Fluid Attacks: a segurança exige testar o sistema coerente como um todo, abrangendo a camada de código, o ambiente de execução e a infraestrutura.

A análise estática, mesmo a impulsionada por IA, examina o código sem executá-lo. Muitas das vulnerabilidades que acabam nos relatórios de incidentes não são problemas que podem ser encontrados lendo o código-fonte com mais atenção. São comportamentos que emergem quando uma aplicação roda no seu ambiente real, as requisições passam pela pilha de APIs, os middlewares de autenticação se encadeiam e os componentes interagem entre serviços. Essas vulnerabilidades exigem executar a aplicação e testá-la em condições que se assemelhem às que um atacante usaria para sondá-la.

O Claude Code Security não faz isso. Nenhuma ferramenta de análise estática faz isso, seja ela tradicional ou impulsionada por IA. Isso não é um defeito no projeto do Claude Code Security, mas apenas o reflexo do escopo ao qual ele se propôs. A pergunta para as equipes de segurança é se os seus programas cobrem as camadas que o escaneamento de código, por mais sofisticado que seja, não alcança.

A mesma lógica se aplica à exploração de vulnerabilidades. Confirmar que um achado é genuinamente explorável num ambiente específico exige mais do que ler código e raciocinar sobre ele; exige testar o sistema em funcionamento. Esse é o domínio dos testes de penetração, em que a expertise humana segue sendo valiosa. Na Fluid Attacks, combinamos ferramentas automatizadas, incluindo o nosso AI SAST, com pentesting manual especializado, já que cada um tem vantagens e limitações que o outro compensa. A análise automatizada com IA cobre amplitude, escaneando repositórios inteiros em alta velocidade e gerando contexto sobre a superfície de ataque que os pentesters usam para direcionar os testes. O pentester traz a profundidade: a capacidade de verificar se uma falha é genuinamente explorável no ambiente implantado e de explorar o comportamento do sistema de formas que nenhuma ferramenta automatizada consegue.

O risco de terceiros se expande para além dos pacotes

A conversa sobre segurança da cadeia de suprimentos tem se concentrado historicamente nas dependências de código aberto: escanear pacotes em busca de Vulnerabilidades e Exposições Comuns (CVEs) conhecidas, gerar listas de materiais de software (SBOMs) e verificar licenças. Isso continua sendo importante, mas a cadeia de suprimentos de uma aplicação moderna agora inclui componentes que não se consegue avaliar com a análise de composição de software (SCA) tradicional.

Quando uma aplicação depende de um LLM para a tomada de decisões, esse modelo é uma dependência de terceiros. Quando ela se conecta a serviços externos por meio de servidores MCP, esses servidores passam a fazer parte da superfície de ataque. Quando os agentes de IA usam skills e plugins para estender as suas capacidades, cada skill é um componente que pode introduzir risco. Os tested de componentes de terceiros já não se resumem ao SCA sobre pacotes; precisam se estender a modelos, skills e servidores MCP. As ferramentas e a metodologia para esse tipo de teste ainda estão em desenvolvimento e representam uma das fronteiras mais importantes da segurança de aplicações.

O que os programas empresariais de AppSec realmente gerenciam

O software empresarial não vive num único repositório mantido por uma única equipe. Ele é um ecossistema extenso: centenas de aplicações, equipes distribuídas por diferentes geografias e fusos horários, uma mistura de sistemas legados e microsserviços modernos, shadow IT que as equipes de segurança talvez nem saibam que existe, e serviços cuja criticidade varia de ferramentas internas a sistemas que afetam o dia a dia de milhões de pessoas. Uma vulnerabilidade num serviço de processamento de pagamentos não é a mesma coisa que uma vulnerabilidade numa wiki interna, e o programa de segurança precisa entender essa diferença.

Essa complexidade é o que torna um escâner de código, por mais inteligente que seja, insuficiente como pilar de um programa de segurança empresarial. O desafio não é apenas detectar vulnerabilidades, mas garantir que os testes sejam executados de maneira consistente e abrangente em todo um ecossistema que muda constantemente.

Pense nos pontos de controle que uma empresa precisa governar. O código é escrito no ambiente do desenvolvedor, revisado num pull request, integrado num pipeline de integração contínua (CI) e implantado em produção. Cada uma dessas etapas é uma oportunidade de testar mas também é uma oportunidade para que uma vulnerabilidade passe se os testes não forem executados. Os escaneamentos estão rodando na interface de linha de comando (CLI) durante o desenvolvimento? São obrigatórios no pull request antes de o código ser mesclado? O pipeline de CI está configurado para bloquear builds que não atendam aos critérios de segurança? A aplicação está sendo testada após o deploy, no ambiente de execução onde os ataques reais acontecem? Um programa de segurança empresarial deve garantir que os testes sejam executados em múltiplos pontos de controle, porque cada ponto ignorado é uma janela que se deixa aberta.

E nesse contexto, um falso negativo pode ser catastrófico. Estamos falando de sistemas que processam transações financeiras, gerenciam dados de saúde, controlam infraestrutura crítica e medeiam o acesso a serviços dos quais as pessoas dependem todos os dias. Uma vulnerabilidade que passa desapercebida, um risco real cuja existência ninguém conhece, é um vetor aberto para ataque contra sistemas cujo comprometimento tem consequências que vão muito além da própria organização. É por isso que as empresas precisam da garantia não apenas de que boas ferramentas existem, mas de que essas ferramentas estão rodando, de que os seus resultados são rastreáveis e de que nada fica sem ser verificado.

O sistema de registro perdura

As ferramentas que os desenvolvedores usam para escrever código estão mudando em ritmo acelerado; algumas delas, como as IDEs tradicionais, podem não sobreviver à transição para o desenvolvimento orientado por agentes. Os sistemas de criação são transitórios por natureza: evoluem, são substituídos e acompanham as preferências de ferramentas do momento.

Uma plataforma para a gestão de postura de segurança de aplicações (ASPM), por outro lado, está se posicionando para ser a fonte oficial de verdade sobre a postura de segurança do portfólio de software de uma organização. É nela que cada achado de cada método de teste converge num único conjunto de dados governado e rastreável. É nela que vivem os fluxos de remediação, que as políticas são aplicadas, que a evidência de conformidade é gerada e que as equipes de desenvolvimento e segurança se encontram em torno de informação compartilhada e completa.

Enquanto os sistemas de criação continuam mudando, o sistema de registro persiste. E as organizações que gerenciam riscos de forma eficaz serão aquelas que ancoram seus programas de segurança não nas ferramentas de varredura mais novas, mas em uma plataforma que persiste, integra e governa em todas as camadas da aplicação.

A nossa plataforma é construída sobre essa convicção. Ela é a fonte única de verdade onde convergem os resultados de todos os métodos de teste, onde os fluxos organizacionais em torno desses resultados (atribuição, remediação, verificação, aplicação de políticas, relatórios de conformidade) fazem parte do mesmo sistema, e onde as pessoas certas em cada equipe têm a informação de que precisam para tomar decisões de segurança em conjunto.

Avançando juntos

Celebramos o Claude Code Security como um sinal de que a indústria está convergindo para uma verdade que, na Fluid Attacks, sustentamos há bastante tempo: o raciocínio com IA pertence à segurança de aplicações, e melhora de forma significativa o que a análise de código estático pode alcançar. A tecnologia vai amadurecer, o seu alcance vai se expandir e as ferramentas construídas sobre ela passarão a fazer parte de como cada organização pensa a segurança do seu código.

Mas também acreditamos que o futuro da segurança de aplicações não se definer por una única capacidade de escaneamento, por mais poderosa que seja. Ele se define por testar os sistemas de maneira integral, abrangendo código, ambiente e infraestrutura; por reunir as equipes de desenvolvimento e segurança em torno de informações compartilhadas e completas; e por ancorar os programas de segurança a um sistema de registro que perdure enquanto as ferramentas ao redor evoluem.

A IA muda a construção de software, não quem garante sua segurança. Esse é o princípio sobre o qual construímos na Fluid Attacks, e a chegada do Claude Code Security reforça a nossa convicção de que é o princípio certo.