Existem agora quatro formas genuinamente diferentes de procurar vulnerabilidades numa aplicação, e cada uma delas testa algo que as outras, por natureza, não conseguem. Isto abrange um espectro que vai desde a correspondência baseada em padrões (conhecida como « SAST » tradicional, que compara o código com padrões conhecidos) até às análises agentivas aprofundadas. Essas análises por agentes podem ser sinais precoces (Deep PR Reviews), que avaliam como uma alteração interage com o código noutras partes do repositório; análise de código com IA (o que o mercado costuma designar por«AI SAST»), que analisam a lógica de uma base de código sem necessidade de implementação em qualquer lugar; ou pentest de IA, que funcionam da mesma forma, mas em relação a um alvo ativo e em execução, e comprovam o que encontram ao tentar explorá-lo. Este artigo ajuda-o a compreender qual a ferramenta mais adequada para cada caso de utilização.
TL:DR
Estes quatro não são concorrentes. Cada um funciona de forma diferente, não apenas a diferentes níveis de profundidade. O « SAST » é determinístico: o mesmo código produz sempre o mesmo resultado, mas apenas para padrões que já conhece. Por sua vez, o «Deep PR Review», o « análise de código com IA » e o «AI Pentest» baseiam-se na lógica e na intenção, detetando o que o « SAST » não consegue detetar estruturalmente, em diferentes âmbitos e em diferentes fases do ciclo de vida.
Cobertura: SAST. Abrangente, contínua e económica. É executada em cada commit, pedido de pull e padrão conhecido. Esta é a vossa porta de entrada. É também muito valiosa no IDE, onde pode ser executada enquanto o programador ou agente está a criar código, para que obtenham feedback antes mesmo de qualquer código ser submetido.
Sinal precoce: Análise aprofundada de PR. Análise da lógica de negócio em cada pedido de integração, detetando IDORs, controle de acesso quebrado e outras falhas que tanto o SAST como uma revisão humana rápida podem deixar escapar. Analisa cada alteração à medida que é aberta, avaliando o impacto dessa alteração noutras partes da base de código.
Confiança: análise de código com IA. O mesmo raciocínio da Deep PR Review, aplicado a todo o repositório em vez de uma alteração de cada vez. Este alcance torna-a a camada ideal para alterações significativas e alvos difíceis de testar, revelando falhas lógicas reais muito antes de existir sequer um alvo ativo contra o qual se possa testar.
Prova: Teste de penetração com IA. O mesmo raciocínio, validado num sistema em funcionamento através de explorações reais. Isto fornece provas claras, em vez de uma estimativa, razão pela qual também satisfaz os requisitos de conformidade.
Em conjunto, abrangem todo o ciclo de vida: cada commit, cada alteração significativa e cada lançamento que necessite de verificação. Eis o que cada um abrange na prática, começando pela camada base.
O que o ` SAST ` verifica: padrões conhecidos, de forma determinística
Testes de segurança de aplicações estáticas funciona ao detetar padrões, por exemplo, um parâmetro corrompido que é passado para uma chamada à base de dados. Se executares o mesmo código duas vezes através desta ferramenta, obterás exatamente o mesmo resultado.
A limitação reside no facto de não possuir capacidade de raciocínio. Um motor de regras não dispõe de um modelo do que a aplicação está efetivamente a fazer. Em vez disso, lê o código linha a linha, comparando-o com padrões que já conhece, e não consegue distinguir dados fiáveis de dados não fiáveis à medida que estes circulam pela aplicação.
Tomemos como exemplo a clássica injeção SQL: uma entrada do utilizador inserida diretamente numa consulta. Isso ainda acontece, mas em código maduro raramente se apresenta de forma tão simples. Os dados não confiáveis geralmente entram num ponto inofensivo, como um cabeçalho de pedido , e depois percorrem várias funções não relacionadas antes de chegarem a um destino final e se tornarem perigosos, muitas vezes várias camadas mais a jusante. Um scanner de correspondência de padrões não consegue seguir esse percurso. Não consegue separar os dados confiáveis dos não confiáveis à medida que estes se deslocam, pelo que sinaliza tudo o que se assemelhe a uma injeção, independentemente de um atacante poder ou não chegar a esse ponto. Essas sinalizações inacessíveis são a origem do ruído e são a razão pela qual a correspondência de padrões conferiu a SAST a a sua reputação de falsos positivos.
Mas isso não significa que o SAST não deva ser utilizado. Se o SAST detetar doze problemas na segunda-feira e nove na terça-feira num código idêntico, os programadores deixam de confiar nele. Estudos revelam que 65% das equipas afirmam que os falsos positivos as obrigam a adotar comportamentos de risco, seja adiar correções, ignorar alertas ou contornar verificações, embora o AutoTriage do Aikido tenha sido concebido especificamente para filtrar esse ruído antes que chegue a um programador. Mesmo com esse custo, o SAST continua a funcionar de forma suficientemente económica para controlar cada commit, o que é exatamente o que a CI/CD, os testes de regressão e a conformidade necessitam.
A Deep PR analisa os motivos de uma alteração antes de a incorporar
A análise de um diff por si só não permite perceber como essa alteração se comporta quando se integra com o resto da aplicação. A Deep PR Review (frequentemente designada por «AI Code Review» no setor) foi concebida para ir além do diff. Em vez de avaliar uma alteração de forma isolada, analisa a forma como essa alteração interage com o código noutras partes do repositório, incluindo bibliotecas partilhadas e serviços em repositórios ligados. É essencialmente o que se pediria a um engenheiro sénior para fazer, se este tivesse capacidade para rastrear efetivamente todas as dependências antes de aprovar um PR (um desejo). Como resultado, é possível detetar erros como fugas de dados cruzadas ou « controle de acesso quebrado » — falhas na lógica de negócio que nem uma revisão humana rápida nem uma ferramenta de correspondência de padrões seriam capazes de detetar, porque nada disso é visível apenas a partir das linhas alteradas.
Normalmente, este é o tipo de problema que, de outra forma, só seria detetado num teste de penetração ou em ambiente de produção, semanas ou meses após a escrita do código, quando a pessoa que o escreveu já não está na equipa e já não dispõe do contexto necessário para explicar a decisão. O Deep Review antecipa a deteção destes problemas, levando-os para a própria solicitação de integração, para que a pessoa que escreveu a alteração ainda se lembre da razão pela qual a escreveu dessa forma. É possível dar feedback diretamente no PR, pelo que frases como «isto é intencional» ou «isto é um falso positivo» proporcionam clareza sem ter de mudar de ferramenta ou sair da revisão.
análise de código com IA testa a intenção e a lógica, sem um ambiente de produção
Em vez de comparar padrões, o análise de código com IA (o que o mercado costuma chamar de «IA SAST ») analisa o seu código-fonte e raciocina sobre ele da mesma forma que um engenheiro sénior faria durante uma revisão. Segue as referências entre ficheiros, rastreia um pedido desde o manipulador de rotas até à consulta à base de dados e verifica se o código faz o que é suposto fazer. Pode fazer isto num repositório ou em vários repositórios interligados, incluindo monorepos que abrangem front-end, back-end e infraestrutura como código. Tudo o que precisa é de acesso ao repositório.
O raciocínio permite detetar falhas na lógica de negócio, algo que um teste de « SAST » não consegue fazer. As falhas de tipo IDOR são um bom exemplo disso, porque é necessário raciocínio para determinar se um ponto de extremidade deve ou não estar restrito ao utilizador que efetua o pedido. Alterar um ID de utilizador para visualizar o perfil público de alguém pode ser um comportamento esperado. Alterá-lo para visualizar as suas mensagens privadas ou definições de conta constitui uma violação. Essa distinção depende do que o ponto final deve impor, e não do próprio recurso, o que não é algo para o qual se possa escrever uma regra estática.
Além disso, não é necessário um alvo em produção para o fazer. Não é preciso configurar um ambiente de teste (ou seja, sem fluxo de autenticação configurado), porque a análise é executada diretamente no repositório de código, o que significa que consegue aceder a elementos que um teste de penetração em produção não consegue, tais como código protegido por um «feature flag», rotas exclusivas para administradores sem credenciais fornecidas e padrões de negação de serviço que não seriam seguros de executar num sistema de produção. O mesmo raciocínio pode ser aplicado a aplicações móveis, contratos inteligentes, aplicações de secretária e, essencialmente, a qualquer linguagem de programação, incluindo as mais antigas ou de nicho para as quais nunca foi desenvolvido um scanner baseado em regras.
Este é o mesmo tipo de raciocínio que a Deep PR Review aplica ao nível dos PR, mas a diferença reside no facto de a Deep PR Review detetar problemas em cada alteração, verificando um pedido de integração (pull request) em relação à base de código mais ampla. Por outro lado, o análise de código com IA analisa toda a base de código de uma só vez, razão pela qual se adequa melhor a alterações significativas e lançamentos completos (é o passo recomendado na secção «Começar»), enquanto a Deep PR Review abrange a análise contínua ao nível dos PR que se segue.
Vale a pena esclarecer por que razão isto não é o mesmo que pedir diretamente a um modelo para rever o seu código. Um modelo a quem se pede diretamente fornece uma análise de uso geral, mais próxima de um programador a dar uma vista de olhos à procura de falhas óbvias do que de uma revisão exaustiva. O análise de código com IA integra esse mesmo modelo numa estrutura que executa a reconhecimento, procura em paralelo e valida de forma independente em todos os repositórios, e é essa orquestração que explica a maior parte da diferença, na prática, no número de erros detetados.
A escolha entre o « SAST » tradicional e o « análise de código com IA » não se resume apenas ao custo. O raciocínio ao longo de toda uma base de código requer mais recursos computacionais e mais tempo do que a correspondência de padrões e, como não existe uma aplicação ativa para testar, os resultados são priorizados com base na probabilidade de serem reais, em vez de serem confirmados através da execução. A velocidade e o determinismo do « SAST » são o que permitem integrá-lo diretamente no CI/CD, razão pela qual o « análise de código com IA » se adequa melhor a alterações significativas e lançamentos importantes, em vez de ser aplicado a cada commit. No entanto, o custo e a eficiência das funcionalidades baseadas em agentes estão a melhorar continuamente, pelo que veremos todas estas capacidades de IA tornarem-se comuns nas organizações.
pentest de IA analisa o seu código e executa-o na sua aplicação
pentest de IA, que é o que constitui um « Aikido Attack», utiliza a mesma abordagem lógica subjacente que análise de código com IA. No entanto, os testes de penetração vão um passo além, ao serem realizados numa aplicação em funcionamento. Isto significa que podem tentar uma exploração real através de agentes que enviam pedidos reais e mapeiam uma superfície de ataque real.
É essa validação em tempo real que elimina grande parte do problema dos falsos positivos (que abordaremos com mais pormenor na próxima secção). O « análise de código com IA » pode concluir, com base no código, que existe uma falha na lógica de negócio, como o IDOR; um teste de penetração pode tentar a exploração contra o sistema em execução e confirmar se esta funciona efetivamente.
Um teste de penetração requer um ambiente estável, um sistema de autenticação funcional e funções de utilizador reais já configuradas, nada disso é exigido pelo análise de código com IA , uma vez que este lê diretamente a partir da fonte. Assim que esse ambiente existe, o teste em si é executado rapidamente, mas processar tráfego em tempo real e determinar o que uma determinada interação realmente faz ainda custa mais por execução do que a análise de texto; é por isso que um teste de penetração se situa acima tanto do SAST como do análise de código com IA em termos de custos de computação.
Um teste de penetração com IA é também o único destes três que cumpre os requisitos de conformidade de normas como a SOC2 e a ISO 27001 para um teste de penetração em tempo real. O « análise de código com IA » não pode substituir um teste de penetração em tempo real quando a conformidade o exige, mas a sua execução prévia pode, ainda assim, ser benéfica. Corrigir falhas lógicas antes do teste de penetração auditado significa menos falhas a detetar no teste em tempo real, a um custo mais baixo por intervenção.
Vale também a pena referir que conceder a um agente de testes de penetração acesso ao código-fonte (denominado «teste whitebox») altera significativamente o que este descobre (e o custo associado a tal). Em mais de 1 000 testes de penetração com IA realizados na plataforma Aikido, os testes com acesso ao código (whitebox) revelaram, em média, sete vezes mais falhas graves e críticas do que os testes sem esse acesso (greybox), com cerca de metade do custo computacional por falha detetada. O teste «greybox» necessitou de 31 execuções do agente para identificar uma única vulnerabilidade, contra 15 no caso do «whitebox». Assim, ao combinar eficazmente os dois (a análise do código-fonte disponibilizada em análise de código com IA) com a exploração em tempo real de pentest de IA, obtém-se uma visão mais abrangente do que com qualquer um deles executado isoladamente. Esta é uma escolha fácil ao selecionar «whitebox» na interface de utilizador para o Aikido Attack.
Se não souber bem como avaliar produtos de testes de penetração baseados em IA, consulte o nosso guia do comprador.
Por que razão um deles produz mais falsos positivos
análise de código com IA identificar problemas no seu código sem o executar. Consegue detetar que um pedido chega a uma operação perigosa e que nada ao longo do percurso o impede, e assinala isso como vulnerável. Como funciona a partir do código-fonte, em vez de um alvo ativo, algumas das vulnerabilidades que assinala acabarão por estar protegidas por algo que o modelo não conseguiu detetar apenas a partir do repositório.
Um teste de penetração acrescenta a exploração em tempo real a esse mesmo raciocínio. Testa a vulnerabilidade suspeita na aplicação em execução e relata o que realmente resultou, razão pela qual as suas conclusões vêm acompanhadas de provas, em vez de uma estimativa.
A execução de ambos colmata a lacuna em ambas as direções. O análise de código com IA acede a código que um teste de penetração nunca atinge, como, por exemplo, qualquer elemento por trás de um «feature flag» ou de uma rota de administração sem credenciais. Um teste de penetração confirma o que o análise de código com IA identifica, assim que exista um alvo ativo para testar.
Qual deles precisas?
Equilibrar as despesas com o risco
O orçamento e a tolerância ao risco determinam que parte do seu património cada instrumento de gestão deve abranger.
Uma equipa pequena obtém uma base de referência sólida e económica apenas com o « análise de código com IA », executando-o no código existente para detetar o que até agora passou despercebido. Não é necessário criar primeiro nenhum ambiente, nem configurar qualquer autenticação, o que faz com que esta seja a camada que pode começar a cobrir os riscos antes de qualquer outra coisa estar implementada. A integração da «Deep PR Review» a partir daí evita que essa base de referência seja ignorada à medida que novo código é lançado, detetando problemas de lógica de negócio em cada pedido de integração sem necessidade de um ambiente de produção ou de um ciclo programado de testes de penetração.
Um teste de penetração com IA (Aikido ) situa-se acima das camadas de raciocínio, funcionando como uma validação periódica e em tempo real, normalmente anual ou aquando de lançamentos importantes, verificando todo o ambiente e a configuração, em vez de apenas o código. A maioria das organizações realiza testes de penetração com IA com essa periodicidade, muitas vezes para cumprir requisitos de conformidade como o SOC 2 ou a ISO 27001. A « pentest de IA » (Aikido Infinite) contínua situa-se acima disso como um nível separado, destinado a equipas cuja postura de segurança exige que a vulnerabilidade seja verificada de forma contínua, em vez de em intervalos programados, independentemente da dimensão da empresa.
A maioria das equipas encontra-se algures nesta progressão, em que a verdadeira questão é a definição do âmbito: quais os repositórios e lançamentos que justificam um teste de penetração programado e quais os que o « análise de código com IA » e a «Deep PR Review» podem cobrir, em conjunto, no dia-a-dia. Executar primeiro as camadas de análise e corrigir as falhas antes do teste de penetração é uma forma de rentabilizar melhor esse investimento, uma vez que um alvo mais limpo significa menos resultados do teste de penetração dedicados a aspetos que poderiam ter sido detetados a um custo menor numa fase anterior.
Considere isto como um valor predefinido inicial que as equipas devem ajustar de acordo com o seu próprio perfil de risco.
Em resumo
Na prática, a cobertura de todo o ciclo de vida significa executar as quatro funcionalidades em conjunto, consoante as suas necessidades num determinado momento. O « SAST » abrange todos os commits e pull requests e funciona de forma contínua. O «Deep PR Review» analisa a lógica de negócio em cada alteração à medida que esta é submetida, antes da sua integração. O « análise de código com IA » alarga essa mesma análise a todo o repositório em alterações significativas, antes mesmo de qualquer coisa ser implementada, e pode detetar configurações incorretas ou definições específicas do ambiente que um teste em ambiente de produção possa não identificar. O AI Pentest abrange a validação periódica em tempo real, a verificação mais exaustiva disponível e aquela que os quadros de conformidade exigem, com o Continuous Pentest disponível para equipas cuja postura de segurança exija essa validação de forma contínua, em vez de em intervalos programados. Os programas de segurança mais robustos executam os quatro, em camadas, em vez de escolherem entre eles.
