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 agentes profundas. Essas análises com agentes podem ser sinais precoces (Deep PR Reviews), que avaliam como uma alteração interage com o código noutras partes do repositório; a Auditoria de Segurança de Código (o que o mercado costuma designar por«AI SAST»), que analisa a lógica de uma base de código sem necessidade de ser implementada em qualquer lugar; ou a Análise de Execução de Código ( pentest de IA), que funciona da mesma forma, mas em relação a um alvo ativo e em execução, e comprova o que encontra 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 em 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», a «Code Security Audit» e o «AI Pentest» analisam a lógica e a 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: Auditoria de Segurança de Código. O mesmo raciocínio da Revisão Aprofundada de Relações Públicas, aplicado a todo o repositório em vez de uma alteração de cada vez. Este alcance torna-a a camada adequada para alterações significativas e alvos difíceis de testar, revelando falhas lógicas reais muito antes de existir sequer um alvo ativo para 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.
A Auditoria de Segurança de Código testa a intenção e a lógica, sem recorrer a um ambiente de produção
Em vez de comparar padrões, o Code Security Audit (o que o mercado costuma chamar de « SAST o com IA») lê o seu código-fonte e analisa-o 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. Basta ter 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 pull em relação à base de código mais ampla. A «Code Security Audit», por outro lado, 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 para «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 faz uma análise genérica, mais próxima de um programador a dar uma vista de olhos em busca de falhas óbvias do que de uma revisão exaustiva. A Auditoria de Segurança de Código integra esse mesmo modelo numa estrutura que realiza 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 a análise de segurança de código tradicional ( SAST ) e a Auditoria de Segurança de Código (Code Security Audit) não se resume apenas ao custo. A análise 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 explorar, as detecções são priorizadas com base na probabilidade de serem reais, em vez de serem confirmadas através da execução. SAST A velocidade e o determinismo da são o que permitem integrá-la diretamente na CI/CD, razão pela qual a Code Security Audit se adequa melhor a alterações significativas e lançamentos importantes, em vez de ser aplicada 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 a «Code Security Audit». No entanto, o pentesting vai um passo além, ao ser executado numa aplicação em funcionamento. Isto significa que pode 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). A Auditoria de Segurança de Código 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 é necessário para a Auditoria de Segurança de Código, uma vez que esta lê diretamente a partir do código-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 da « SAST » como da «Auditoria de Segurança de Código» 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. A auditoria de segurança de código não pode substituir um teste de penetração em tempo real quando a conformidade o exige, mas a sua realizaçã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 esse processo). 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 de gravidade elevada e crítica 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 revelar uma única vulnerabilidade, contra 15 no caso do «whitebox». Assim, ao combinar eficazmente os dois (a análise do código-fonte fornecida na «Auditoria de Segurança de Código») com a exploração em tempo real d pentest de IA, obtém-se uma visão mais abrangente do que com qualquer um deles a funcionar isoladamente. Esta é uma escolha fácil ao selecionar «whitebox» na interface do 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
O Code Security Audit analisa o 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, assinalando isso como vulnerável. Como funciona a partir do código-fonte, em vez de um alvo em produção, 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 ambas as operações colmata as lacunas em ambas as direções. A Auditoria de Segurança de Código alcança partes do código que um teste de penetração nunca aborda, como tudo o que se encontra por trás de um «feature flag» ou de uma rota de administração sem credenciais. Um teste de penetração confirma o que a Auditoria de Segurança de Código 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 a Auditoria de Segurança de Código, ao aplicá-la ao código existente para detetar o que até agora passou despercebido. Não é necessário criar nenhum ambiente inicialmente, 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 medida estar em vigor. A integração da «Deep PR Review» a partir daí garante que essa base de referência não 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 reside na definição do âmbito: quais os repositórios e lançamentos que justificam um teste de penetração programado e quais os que podem ser abrangidos, no dia a dia, pela auditoria de segurança do código e pela revisão aprofundada das PR. Aplicar primeiro as camadas de raciocínio 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. A « SAST » abrange todos os commits e pull requests e funciona de forma contínua. A «Deep PR Review» analisa a lógica de negócio em cada alteração à medida que esta é submetida, antes da sua integração. A «Code Security Audit» alarga essa mesma análise a todo o repositório em alterações significativas, antes mesmo de qualquer coisa ser implementada, e consegue detetar configurações erradas ou definições específicas do ambiente que um teste em produção possa deixar escapar. 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.
