IA na Segurança da Informação do RuStore: Da Revisão de Tarefas e Código ao AI-DAST
Explore como a RuStore está utilizando inteligência artificial para otimizar processos de segurança, desde a triagem de tarefas até a análise de código e testes dinâmicos, liberando especialistas para focarem em desafios mais complexos e estratégicos.
MundiX News·16 de abril de 2026·25 min de leitura·👁 11 views
A segurança da informação no desenvolvimento de produtos não se resume apenas à busca por vulnerabilidades complexas e cenários de ataque raros. Uma parte significativa consiste em uma carga operacional regular: analisar novas tarefas, revisar alterações no código, verificar releases, coletar contexto e identificar riscos potenciais em tempo hábil.
É nesse nível que surge o principal volume de rotina. Um engenheiro de segurança executa repetidamente as mesmas ações básicas: lê a tarefa, analisa o contexto, verifica padrões típicos e filtra problemas óbvios. Esse trabalho é necessário, mas consome muito tempo que deveria ser gasto em análises e tomadas de decisão mais complexas.
Aumentar a equipe para lidar com essa carga nem sempre é o melhor caminho, pois, juntamente com a expertise, a rotina também se expande. Portanto, para nós, o próximo passo lógico foi usar a IA – não como um substituto para o engenheiro, mas como uma ferramenta que assume a camada primária de verificação.
Analisamos o processo de segurança da informação dentro do ciclo de lançamento e identificamos as áreas com maior repetibilidade. Havia três pontos principais: análise primária de tarefas de Security Check, análise de código em merge requests e testes dinâmicos de aplicativos. Em todos esses cenários, o trabalho típico é realizado primeiro e, somente depois, começa a parte realmente especializada.
É essa camada que decidimos automatizar com três ferramentas práticas:
Um serviço para a revisão primária de tarefas de Security Check, que ajuda a processar o fluxo de entrada mais rapidamente e destacar os riscos potenciais.
AI Code Review, integrado ao processo de verificação de código e ajudando a encontrar vulnerabilidades e erros típicos.
AI DAST – um sistema multiagente para automatizar testes dinâmicos, que funciona como um "robô-pentester" no nível de um especialista júnior.
É importante esclarecer que, em todos esses cenários, a IA não toma decisões finais. Ela remove a carga rotineira, acelera a coleta de contexto e ajuda o engenheiro a passar mais rapidamente para o que realmente exige expertise: avaliação de riscos, análise de casos não triviais e seleção de soluções.
Primeiro instrumento: IA para revisão de tarefas de Security Check
Dentro do ciclo de produto, temos o Security Check – um circuito obrigatório que permite avaliar as mudanças do ponto de vista da segurança ainda na fase de trabalho com a tarefa. A ideia é simples: qualquer tarefa de produção pode potencialmente afetar a segurança e, portanto, precisa ser filtrada de forma rápida e adequada.
O problema é que nem toda tarefa realmente requer um envolvimento profundo da equipe de segurança da informação. No fluxo de lançamento, sempre há muitas mudanças que não representam um risco significativo: correções de interface, alterações de texto, feature flags, ajustes técnicos irrelevantes, refatorações secundárias sem impacto na funcionalidade e acessos. Mas, para entender que uma tarefa é irrelevante, o engenheiro ainda gasta tempo.
É essa etapa que decidimos automatizar.
Como funciona o serviço
Desenvolvemos o serviço RuStore Security Check Review, que se conecta à tarefa após o aparecimento do Merge Request e funciona nos estágios de code review até ready for deploy. Ele coleta contexto de várias fontes: descrição da tarefa, artefatos relacionados, código do Merge Request, registros de arquitetura, especificações de API e outros dados disponíveis que ajudam a entender o significado das mudanças.
Depois disso, o serviço gera dois resultados principais.
O primeiro é um resumo das mudanças com foco na segurança. Essencialmente, é uma análise concisa do que mudou no código e quais classes de risco são relevantes aqui. Por exemplo: há alterações na lógica de autorização, novos endpoints estão aparecendo, os cenários de acesso a dados estão mudando, operações potencialmente confidenciais estão sendo adicionadas, consultas SQL ou mecanismos de filtragem estão sendo afetados?
O segundo é um veredicto preliminar sobre a relevância da tarefa para a equipe de segurança da informação. Se o conteúdo do MR mostrar que a tarefa não afeta a funcionalidade, a segurança e o modelo de acesso, o serviço pode marcá-la como irrelevante e fechá-la automaticamente. Se as mudanças forem significativas, ele não substitui a decisão do engenheiro, mas, ao contrário, ajuda a iniciar uma análise significativa mais rapidamente: mostra onde procurar primeiro e quais riscos são mais prováveis.
É aqui que a IA tem um efeito notável. Anteriormente, essa análise primária levava de 5 minutos a uma hora – dependendo do volume de mudanças, da qualidade da descrição e da necessidade de esclarecer detalhes com os desenvolvedores. Agora, a análise básica ocorre em segundos.
O que isso deu na prática
Nos 4 meses desde o lançamento, o serviço processou 2.538 tarefas. Destas, 617 foram fechadas automaticamente como irrelevantes para a segurança da informação. Isso deu um aumento de produtividade de cerca de 24% apenas cortando o fluxo desnecessário.
É importante esclarecer: não se trata de "a rede neural começou a fazer o trabalho dos profissionais de segurança". Trata-se de outra coisa. A equipe parou de gastar uma parte significativa do tempo em tarefas que inicialmente não exigiam verificação manual. O recurso liberado foi para onde realmente era necessário: análise arquitetural, novas integrações, mudanças controversas, um estudo mais aprofundado de casos complexos.
O que foi difícil
Externamente, essas histórias costumam parecer muito suaves: criamos um serviço, conectamos um modelo, tudo começou a funcionar imediatamente. Na realidade, é claro, não foi assim.
Um dos problemas não estava relacionado à infraestrutura, mas à qualidade das respostas do modelo. Nos estágios iniciais, demos a ele instruções muito rígidas e excessivamente complicadas. Isso levou a um efeito previsível: o serviço começou a fornecer respostas muito médias, estéreis e de baixo valor. Formalmente, tudo parecia correto, mas havia pouco benefício prático – em vez de comentários relevantes, o modelo retornava consistentemente a "temperatura média no hospital".
Tivemos que ir na direção oposta: não tornar os prompts ainda mais rígidos, mas, ao contrário, ajustar as regras de forma sutil, dar ao modelo mais espaço para raciocinar e mais autonomia na escolha dos focos. Depois disso, a qualidade aumentou visivelmente: as respostas se tornaram menos padronizadas e muito mais vinculadas a mudanças específicas.
Essa é geralmente uma das conclusões mais úteis de todo o trabalho: se você estiver incorporando um LLM aos processos de segurança, não pense apenas nas categorias de "proibir tudo o que for desnecessário" e "apertar ao máximo o prompt". Às vezes, um excesso de restrições reduz a qualidade mais do que a falta delas.
O que é importante lembrar
Security Check Review não é uma máquina para tomar decisões. É uma ferramenta de análise preliminar.
Observamos regularmente quais tarefas ele fecha, verificamos seus veredictos e monitoramos se o sistema começa a cometer erros ou a desviar para o excesso de confiança. É por isso que não estamos falando de "automação completa", mas de controle de IA calibrável e observável.
Para a segurança da informação, isso é fundamental. Você não pode simplesmente ver um belo número de fechamentos automáticos e decidir que tudo está funcionando sozinho agora. Qualquer controle de IA requer feedback, validação periódica e registro normal dos resultados.
Segundo instrumento: AI Code Review como controle obrigatório no pipeline
A próxima etapa é analisar a segurança não das tarefas, mas diretamente do código.
A equipe de desenvolvimento da RuStore já tinha seu próprio sistema multiagente AI Code Review, integrado ao processo de trabalho com Merge Request. Ele era usado para análise geral da qualidade do código, e nos conectamos a esse circuito com nossa parte – verificações de segurança. Assim, surgiu um agente de segurança separado dentro do AI Code Review, que analisa as mudanças em cada MR e procura vulnerabilidades que são difíceis ou inconvenientes de capturar com analisadores estáticos clássicos.
Essa é uma ressalva importante. Não estávamos tentando substituir o SAST. Os scanners clássicos são bons, mas têm um limite. Eles nem sempre entendem o contexto de negócios, as características arquitetônicas, os fluxos de autorização reais e os cenários de acesso não triviais. E, para a segurança da informação, são essas coisas que geralmente são as mais perigosas.
Quais verificações incorporamos
Em um nível básico, o agente analisa o código em busca de problemas de segurança típicos: correção de autenticação e autorização, emissão excessiva de dados, configurações de rate limiting, riscos de mass assignment, várias opções de injeções, CORS e restrições no formato e tamanho de solicitações e respostas.
Mas a principal direção para nós é o controle de violações de acesso, principalmente IDOR/ BOLA. Essas vulnerabilidades são particularmente desagradáveis porque geralmente estão escondidas em uma lógica "quase correta". O código pode parecer limpo, as solicitações podem ser parametrizadas, os testes podem passar, mas, na realidade, o usuário obtém acesso ao objeto de outra pessoa simplesmente porque, em algum lugar em um novo endpoint, eles se esqueceram de verificar a propriedade da entidade ou transferiram incorretamente a lógica de autorização ao mudar a arquitetura.
Em um produto grande que está sendo ativamente desenvolvido e refatorado, esse é um risco muito real.
Por que o IDOR se tornou uma prioridade
Em algum momento, a equipe da RuStore começou a transferir ativamente os serviços para uma nova arquitetura com uma abordagem de gateway: as comunicações externas e os pontos de entrada foram unificados, os padrões de processamento de solicitações foram alterados e os endpoints e o roteamento foram revisados.
Esse foi um movimento arquitetônico correto, mas essas mudanças são sempre perigosas do ponto de vista da degradação das antigas garantias de segurança. Você pode manter a lógica de negócios, não quebrar a funcionalidade e ainda perder imperceptivelmente parte do controle de acesso.
Na verdade, a hipótese sobre esse risco foi confirmada na prática: um dos relatórios de bug bounty trouxe um IDOR com uma violação de acesso entre projetos no console do desenvolvedor. Esse se tornou um sinal importante: essas coisas não podem ser deixadas apenas para verificações post-factum e análise manual. É necessário um controle obrigatório diretamente no estágio de code review.
Como isso está integrado ao processo
As verificações do AI Code Review são obrigatórias para iniciar: sem elas, a ramificação de lançamento não avança no pipeline. E isso por si só já muda a disciplina – cada Merge Request passa garantidamente por uma análise de IA do ponto de vista da segurança.
O próximo passo que a equipe está dando é não apenas bloquear a ausência de verificação, mas tornar as próprias descobertas bloqueadoras. Ou seja, se o agente de segurança destacar um problema crítico, o MR deve ser interrompido até que seja corrigido ou analisado conscientemente pelo líder da equipe e pelos engenheiros responsáveis.
Essa é uma diferença fundamental entre uma "dica útil" e um verdadeiro controle de proteção.
Onde o modelo teve que ser aprimorado
Aqui também não foi isento de irregularidades.
A primeira dificuldade foi que o modelo pronto inicialmente não entendia bem o contexto do nosso produto. Por exemplo, ele não levou em consideração as características da autorização interna, onde parte das verificações deve ocorrer no nível do gateway, e não em cada serviço interno. Por causa disso, muitos falsos positivos surgiram no início: o modelo reclamava de casos que eram permitidos em nossa arquitetura.
O problema teve que ser resolvido não "ajustando o modelo" como tal, mas adaptando os prompts e o contexto. Começamos a adicionar recursos de arquitetura às instruções, incluir exemplos do projeto real e gradualmente traduzir o agente do modo de "revisor universal de tudo" para o modo de assistente especializado especificamente para nossos repositórios e nossos padrões de desenvolvimento.
O segundo problema não era técnico, mas organizacional. Mesmo um bom sinal é inútil se os desenvolvedores o ignorarem ou lerem diagonalmente. Nos estágios iniciais, vimos que parte das conclusões do AI Code Review simplesmente se perde na interface: há um comentário, mas não parece algo que exija atenção imediata.
Daí duas conclusões. Primeiro, o sinal de segurança deve ser integrado ao caminho real do desenvolvedor, e não viver separadamente "em algum lugar nos logs". Em segundo lugar, para ferramentas internas de IA, o UX também é crítico. Se a saída estiver sobrecarregada, mal estruturada ou parecer apenas mais uma "conversa da rede neural", ela começará a ser ignorada.
Portanto, paralelamente à precisão da análise, também melhoramos a forma de saída dos resultados: tornamos a saída mais legível, mais específica e mais adequada para ação rápida.
O que obtivemos no final
Não gostamos de desenhar métricas artificiais onde elas não podem ser honestamente contadas. Para um agente de segurança dentro da revisão de código, outro indicador é muito mais importante: após a introdução desse controle, paramos de ver problemas repetíveis da classe para a qual ele foi criado – principalmente violações de controle de acesso e erros típicos que surgem em um contexto de mudanças arquitetônicas.
Isso não significa que o sistema se tornou perfeito. Isso significa que o controle foi incorporado à prática diária e começou a funcionar onde antes os erros escapavam para estágios posteriores.
E esse é um dos efeitos mais valiosos para a segurança da informação: encontrar um problema não em um bug bounty, não em um pentest após o lançamento e não em produção, mas no momento em que o desenvolvedor ainda está trabalhando com o MR.
Terceiro instrumento: AI DAST – quando o agente começa a se comportar como um pentester
Se o Security Check Review ajuda a filtrar tarefas e o AI Code Review ajuda a analisar o código, o próximo passo lógico é o teste dinâmico de segurança.
É isso que nosso AI DAST faz.
A solução está quase pronta para ser implementada em produção, e já podemos compartilhar o MVP e os cenários de trabalho. Essencialmente, estamos falando de um sistema multiagente para testes dinâmicos, que deve complementar o DAST clássico e remover uma de suas principais limitações: a incapacidade de testar qualitativamente APIs de produtos complexos sem um contexto real.
Por que o DAST clássico não é suficiente
Já tínhamos e temos nosso próprio circuito DAST. Ele rastreia as especificações da API, vê as mudanças e executa um conjunto de ferramentas como Nuclei, sqlmap, ZAP e outros scanners nos endpoints correspondentes.
Mas a análise dinâmica clássica tem um problema fundamental. Para testar efetivamente os endpoints de produtos reais, não basta apenas conhecer o URL e o método de solicitação. Você precisa ser capaz de coletar dados válidos: userId, appId, companyId, tokens de autorização, conexões corretas entre entidades, formato de parâmetros, sequências de chamadas permitidas. E em grandes serviços, esses dados geralmente não podem ser obtidos "em uma etapa".
Como resultado, o DAST comum captura bem as coisas básicas, mas rapidamente atinge um teto se tiver um endpoint complexo com um contexto não trivial à sua frente.
É esse teto que queremos romper com a ajuda de agentes de IA.
O que o AI DAST faz
Dentro do sistema, existem vários agentes especializados que trabalham como uma pequena equipe.
A especificação OpenAPI e a tarefa são inseridas: qual endpoint testar e em qual classe de risco prestar atenção. Em seguida, o agente entra em ação, que chamamos de Request Builder Agent dentro da equipe.
Sua tarefa não é apenas gerar um comando curl, mas construir uma solicitação válida que realmente chegue ao endpoint de destino e retorne uma resposta 2xx. Ou seja, não formalmente "coletar uma string de solicitação", mas realmente seguir o caminho que um engenheiro ou pentester seguiria ao tentar chegar a um ponto de entrada de trabalho.
Se já houver dados suficientes para a solicitação, a tarefa é simples: o agente forma rapidamente uma chamada correta e a envia para o circuito de teste.
Se os dados forem insuficientes, um cenário mais interessante começa.
Primeiro, o OpenAPI Analyzer é conectado. Ele tem um mapa de serviços e endpoints disponíveis e começa a procurar quais APIs podem ser usadas para obter os valores ausentes. Por exemplo, quais endpoints permitem descobrir a lista de aplicativos associados a um usuário ou extrair os identificadores das entidades necessárias. Essencialmente, ele constrói uma cadeia de chamadas auxiliares para obter o contexto ausente.
Se isso ainda não for suficiente, o Repository Analyzer é conectado. Ele já vai para o código do monorepositório, encontra a implementação do endpoint, rastreia o fluxo de execução, entende o esquema de validação de parâmetros e observa quais tabelas e dados o endpoint específico acessa. Isso dá uma compreensão muito mais profunda de quais valores são geralmente permitidos e o que é necessário para uma passagem bem-sucedida do cenário.
O próximo nível é o Database Analyzer. Se o sistema já entendeu quais dados estão em um banco de dados específico e em qual tabela procurá-los, o agente pode obter valores reais dos dev-stands por meio dos mecanismos fornecidos. Não "appId aproximados" abstratos, mas identificadores ativos associados a um usuário de teste ou, ao contrário, a entidades de outras pessoas.
Isso é importante porque a análise não se limita à resposta HTTP. Em vários cenários (por exemplo, ao tentar injeções – SQL, NoSQL, command, stored XSS ou race condition), externamente tudo pode parecer correto: o serviço retornará 200 OK sem alterações explícitas. Mas, ao mesmo tempo, uma gravação no banco de dados ou uma alteração nos dados pode ocorrer nos bastidores.
O Database Analyzer permite que o AI DAST verifique isso diretamente:
se erros ou anomalias apareceram nos logs do BD;
se os dados nas tabelas de destino foram alterados;
se a carga maliciosa foi processada de forma assíncrona.
Por causa disso, o sistema começa a ver vulnerabilidades cegas que os scanners DAST clássicos geralmente perdem devido à falta de contexto de execução.
E aqui começa a parte pela qual tudo foi iniciado.
Como isso se parece no exemplo do IDOR
Imagine um endpoint do tipo
GET /api/users/{userId}/apps/{appId}.
A tarefa é verificar se é possível obter acesso aos dados de outra pessoa por meio dele.
Para fazer isso manualmente, você precisa primeiro entender quais userId e appId são geralmente válidos, quais deles pertencem ao usuário atual, quais pertencem a outros, como é o token correto, quais combinações são permitidas e como o serviço se comporta ao substituir valores "próprios" e "alheios".
Para uma pessoa, esse é o trabalho normal de um pentester. Para o DAST clássico – quase um beco sem saída. E para o AI DAST – este é apenas um cenário típico.
O sistema encontra uma maneira de obter seus próprios dados, então encontra ou extrai valores de outras pessoas do banco de dados e, em seguida, constrói dois conjuntos de solicitações: um de referência, que deve funcionar, e um de ataque, que não deve passar. Se a solicitação de ataque retornar uma resposta bem-sucedida, receberemos um sinal completo de violação de controle de acesso.
Ou seja, o AI DAST não apenas executa um scanner na API. Ele coleta contexto, entende conexões, constrói cenários de trabalho e começa a agir mais perto de como um pentester real agiria.
Ajustando o equilíbrio: universalidade vs gerenciabilidade
A principal tarefa ao desenvolver o AI DAST, como no caso do Security Check Review, é encontrar um equilíbrio nas instruções para o agente. Se você defini-los muito rigidamente, ele chegará rapidamente a um resultado, mas perderá a flexibilidade e começará a funcionar pior em serviços com outra lógica. Se, ao contrário, você deixar muita liberdade, o agente pode ir para a iteração de cenários e perder tempo em pesquisas ineficientes.
Esse problema se torna especialmente perceptível se você levar em consideração o contexto do produto: temos uma arquitetura diferente e muitos serviços. Configurar o agente para cada um deles separadamente não é aconselhável. Portanto, um dos principais objetivos é criar uma ferramenta universal que possa ser aplicada sem retrabalho manual para um serviço específico.
Daí a abordagem de compromisso escolhida. Por um lado, deixamos as instruções flexíveis o suficiente para que o agente possa encontrar pontos de entrada e construir cenários por conta própria. Por outro lado, restringimos seu comportamento por meio de um conjunto de ferramentas especializadas no MCP (Model Context Protocol). Cada ferramenta resolve uma tarefa específica e torna o trabalho do agente gerenciável: obtenção e normalização de contexto, chamadas para test stands, trabalho com logs e auditoria, geração e execução de payload, verificação de direitos de acesso, reprodução de cenários e fixação de artefatos. Por causa disso, não criptografamos toda a lógica nas instruções, mas a transferimos para as ferramentas. Isso também simplifica o desenvolvimento do sistema. Quando aparece um novo tipo de descoberta manual, não reescrevemos o agente inteiro, mas adicionamos ou ajustamos a ferramenta MCP necessária e a vinculamos ao cenário correspondente.
Além disso, introduzimos um estágio de pesquisa primária. Antes de iniciar o teste, o agente recebe a especificação da API, documentação e outras fontes, coleta o contexto geral do serviço e o salva na memória de longo prazo. Isso permite que ele não comece do zero todas as vezes, mas confie na compreensão já coletada.
Paralelamente, treinamos constantemente o sistema em casos reais. Cada bug exclusivo encontrado manualmente é analisado em uma retrospectiva e transformado em melhorias do AI DAST: atualizamos as regras de prompt, adicionamos novas cadeias de ações para obter contexto e expandimos as ferramentas MCP. Como resultado, com o tempo, fechamos classes de vulnerabilidades que antes eram encontradas apenas por humanos.
O que isso dá para a empresa e a equipe
Aqui, o efeito é mais amplo do que apenas "mais uma automação".
Primeiro, é uma redução na carga sobre uma pequena equipe de segurança da informação. Cenários básicos de verificação que antes levavam muito tempo podem ser transferidos para uma ferramenta autônoma.
Em segundo lugar, é uma economia na detecção precoce de vulnerabilidades. Encontrar um problema antes do lançamento é quase sempre mais barato do que pegá-lo mais tarde por meio de bug bounty, pentest externo ou, mais ainda, por meio de um incidente.
Em terceiro lugar, é a capacidade de cobrir mais profundamente o que o DAST clássico não alcança sem participação manual. E é aqui que a IA se torna um verdadeiro amplificador de proteção.
O que tudo isso muda no trabalho da equipe de segurança da informação
Existe uma frase banal de que "a IA tira a rotina e libera tempo para tarefas interessantes". Ela já está desgastada e por si só explica pouco. Na prática, para a segurança da informação, outra formulação é mais importante: a IA tira a rotina e libera tempo para tarefas importantes.
Não se trata de os profissionais de segurança agora se sentarem e se dedicarem apenas a algo emocionante. Trata-se de que, em vez de visualizar mecanicamente centenas de tarefas que não afetam a segurança, a equipe pode analisar mais profundamente novas integrações, mudanças arquitetônicas, cenários de acesso não triviais, riscos de negócios complexos e classes de vulnerabilidades realmente perigosas.
É assim que vemos isso: tudo o que pode ser dado a um "júnior condicional na forma de uma rede neural" pode e deve ser dado. Mas a decisão sobre questões significativas, especialmente arquitetônicas e arriscadas, ainda permanece com o engenheiro.
O que a implementação da IA nos processos de segurança nos ensinou
Durante o tempo que trabalhamos nessas ferramentas, formamos várias conclusões que, como nos parece, são úteis para qualquer equipe de produto.
Primeiro:
não tente construir um controle de IA universal do zero.
Outra abordagem funciona muito melhor – pegar um processo existente e incorporar a IA como uma camada adicional. Onde já existe Security Check, code review ou DAST, a implementação se torna muito mais realista e eficaz.
Segundo:
os modelos não entendem seu produto automaticamente.
Eles terão que ser calibrados para a arquitetura, padrões de autorização, regras internas e cenários reais. Quanto mais próximo o controle de IA estiver do seu domínio, maior a chance de que ele seja realmente útil.
Terceiro:
instruções muito rígidas podem piorar o resultado.
Às vezes, uma resposta de qualidade não aparece quando você regulamentou ao máximo o modelo, mas quando deu a ele contexto suficiente e liberdade suficiente para uma conclusão significativa.
Quarto:
a IA na segurança não pode ser deixada sem supervisão.
São necessários logs, painéis, verificação manual seletiva, calibração regular. Se você parar de olhar para seus resultados, poderá perder muito rapidamente a confiança na ferramenta ou em seu próprio processo.
E quinto:
o controle de bloqueio é quase sempre mais útil do que o recomendatório
se estivermos falando de riscos realmente significativos. Mas é importante implementá-lo gradualmente – paralelamente a melhorias e aumento da confiança na qualidade das próprias verificações. Caso contrário, mesmo os controles úteis podem causar resistência ao desenvolvimento e aos negócios.
Em vez de uma conclusão
Hoje, existem muitos extremos em torno da IA na segurança. Alguns acreditam que as redes neurais em breve substituirão metade dos processos de segurança da informação. Outros, ao contrário, estão certos de que tudo isso são brinquedos e ruído da moda. Nossa experiência até agora fala de uma coisa mais realista e, como nos parece, mais útil.
A IA funciona bem onde a equipe já tem um processo maduro e uma tarefa clara. Ela não substitui a expertise, mas amplifica perfeitamente os circuitos nos quais as pessoas costumavam gastar muito tempo em ações do mesmo tipo: coleta de contexto, filtragem primária, busca de problemas típicos, preparação de cenários válidos para testes.
É neste lugar que o valor real aparece. Na RuStore, já usamos a IA para revisar tarefas de Security Check e para analisar Merge Requests no pipeline. O próximo passo é levar o AI DAST ao uso industrial e fechar outra grande camada de trabalho rotineiro, mas caro em termos de tempo.
A principal conclusão para nós é muito simples: na segurança da informação, você não precisa escolher entre "fazer tudo manualmente" e "confiar totalmente na IA". O caminho de trabalho é construir ferramentas que ajudem a equipe a ver o importante mais rapidamente, encontrar riscos mais cedo e gastar expertise humana onde ela é realmente insubstituível.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
A segurança da informação no desenvolvimento de produtos não se resume apenas à busca por vulnerabilidades complexas e cenários de ataque raros. Uma parte significativa consiste em uma carga operacional regular: analisar novas tarefas, revisar alterações no código, verificar releases, coletar contexto e identificar riscos potenciais em tempo hábil.
É nesse nível que surge o principal volume de rotina. Um engenheiro de segurança executa repetidamente as mesmas ações básicas: lê a tarefa, analisa o contexto, verifica padrões típicos e filtra problemas óbvios. Esse trabalho é necessário, mas consome muito tempo que deveria ser gasto em análises e tomadas de decisão mais complexas.
Aumentar a equipe para lidar com essa carga nem sempre é o melhor caminho, pois, juntamente com a expertise, a rotina também se expande. Portanto, para nós, o próximo passo lógico foi usar a IA – não como um substituto para o engenheiro, mas como uma ferramenta que assume a camada primária de verificação.
Analisamos o processo de segurança da informação dentro do ciclo de lançamento e identificamos as áreas com maior repetibilidade. Havia três pontos principais: análise primária de tarefas de Security Check, análise de código em merge requests e testes dinâmicos de aplicativos. Em todos esses cenários, o trabalho típico é realizado primeiro e, somente depois, começa a parte realmente especializada.
É essa camada que decidimos automatizar com três ferramentas práticas:
Um serviço para a revisão primária de tarefas de Security Check, que ajuda a processar o fluxo de entrada mais rapidamente e destacar os riscos potenciais.
AI Code Review, integrado ao processo de verificação de código e ajudando a encontrar vulnerabilidades e erros típicos.
AI DAST – um sistema multiagente para automatizar testes dinâmicos, que funciona como um "robô-pentester" no nível de um especialista júnior.
É importante esclarecer que, em todos esses cenários, a IA não toma decisões finais. Ela remove a carga rotineira, acelera a coleta de contexto e ajuda o engenheiro a passar mais rapidamente para o que realmente exige expertise: avaliação de riscos, análise de casos não triviais e seleção de soluções.
Primeiro instrumento: IA para revisão de tarefas de Security Check
Dentro do ciclo de produto, temos o Security Check – um circuito obrigatório que permite avaliar as mudanças do ponto de vista da segurança ainda na fase de trabalho com a tarefa. A ideia é simples: qualquer tarefa de produção pode potencialmente afetar a segurança e, portanto, precisa ser filtrada de forma rápida e adequada.
O problema é que nem toda tarefa realmente requer um envolvimento profundo da equipe de segurança da informação. No fluxo de lançamento, sempre há muitas mudanças que não representam um risco significativo: correções de interface, alterações de texto, feature flags, ajustes técnicos irrelevantes, refatorações secundárias sem impacto na funcionalidade e acessos. Mas, para entender que uma tarefa é irrelevante, o engenheiro ainda gasta tempo.
É essa etapa que decidimos automatizar.
Como funciona o serviço
Desenvolvemos o serviço RuStore Security Check Review, que se conecta à tarefa após o aparecimento do Merge Request e funciona nos estágios de code review até ready for deploy. Ele coleta contexto de várias fontes: descrição da tarefa, artefatos relacionados, código do Merge Request, registros de arquitetura, especificações de API e outros dados disponíveis que ajudam a entender o significado das mudanças.
Depois disso, o serviço gera dois resultados principais.
O primeiro é um resumo das mudanças com foco na segurança. Essencialmente, é uma análise concisa do que mudou no código e quais classes de risco são relevantes aqui. Por exemplo: há alterações na lógica de autorização, novos endpoints estão aparecendo, os cenários de acesso a dados estão mudando, operações potencialmente confidenciais estão sendo adicionadas, consultas SQL ou mecanismos de filtragem estão sendo afetados?
O segundo é um veredicto preliminar sobre a relevância da tarefa para a equipe de segurança da informação. Se o conteúdo do MR mostrar que a tarefa não afeta a funcionalidade, a segurança e o modelo de acesso, o serviço pode marcá-la como irrelevante e fechá-la automaticamente. Se as mudanças forem significativas, ele não substitui a decisão do engenheiro, mas, ao contrário, ajuda a iniciar uma análise significativa mais rapidamente: mostra onde procurar primeiro e quais riscos são mais prováveis.
É aqui que a IA tem um efeito notável. Anteriormente, essa análise primária levava de 5 minutos a uma hora – dependendo do volume de mudanças, da qualidade da descrição e da necessidade de esclarecer detalhes com os desenvolvedores. Agora, a análise básica ocorre em segundos.
O que isso deu na prática
Nos 4 meses desde o lançamento, o serviço processou 2.538 tarefas. Destas, 617 foram fechadas automaticamente como irrelevantes para a segurança da informação. Isso deu um aumento de produtividade de cerca de 24% apenas cortando o fluxo desnecessário.
É importante esclarecer: não se trata de "a rede neural começou a fazer o trabalho dos profissionais de segurança". Trata-se de outra coisa. A equipe parou de gastar uma parte significativa do tempo em tarefas que inicialmente não exigiam verificação manual. O recurso liberado foi para onde realmente era necessário: análise arquitetural, novas integrações, mudanças controversas, um estudo mais aprofundado de casos complexos.
O que foi difícil
Externamente, essas histórias costumam parecer muito suaves: criamos um serviço, conectamos um modelo, tudo começou a funcionar imediatamente. Na realidade, é claro, não foi assim.
Um dos problemas não estava relacionado à infraestrutura, mas à qualidade das respostas do modelo. Nos estágios iniciais, demos a ele instruções muito rígidas e excessivamente complicadas. Isso levou a um efeito previsível: o serviço começou a fornecer respostas muito médias, estéreis e de baixo valor. Formalmente, tudo parecia correto, mas havia pouco benefício prático – em vez de comentários relevantes, o modelo retornava consistentemente a "temperatura média no hospital".
Tivemos que ir na direção oposta: não tornar os prompts ainda mais rígidos, mas, ao contrário, ajustar as regras de forma sutil, dar ao modelo mais espaço para raciocinar e mais autonomia na escolha dos focos. Depois disso, a qualidade aumentou visivelmente: as respostas se tornaram menos padronizadas e muito mais vinculadas a mudanças específicas.
Essa é geralmente uma das conclusões mais úteis de todo o trabalho: se você estiver incorporando um LLM aos processos de segurança, não pense apenas nas categorias de "proibir tudo o que for desnecessário" e "apertar ao máximo o prompt". Às vezes, um excesso de restrições reduz a qualidade mais do que a falta delas.
O que é importante lembrar
Security Check Review não é uma máquina para tomar decisões. É uma ferramenta de análise preliminar.
Observamos regularmente quais tarefas ele fecha, verificamos seus veredictos e monitoramos se o sistema começa a cometer erros ou a desviar para o excesso de confiança. É por isso que não estamos falando de "automação completa", mas de controle de IA calibrável e observável.
Para a segurança da informação, isso é fundamental. Você não pode simplesmente ver um belo número de fechamentos automáticos e decidir que tudo está funcionando sozinho agora. Qualquer controle de IA requer feedback, validação periódica e registro normal dos resultados.
Segundo instrumento: AI Code Review como controle obrigatório no pipeline
A próxima etapa é analisar a segurança não das tarefas, mas diretamente do código.
A equipe de desenvolvimento da RuStore já tinha seu próprio sistema multiagente AI Code Review, integrado ao processo de trabalho com Merge Request. Ele era usado para análise geral da qualidade do código, e nos conectamos a esse circuito com nossa parte – verificações de segurança. Assim, surgiu um agente de segurança separado dentro do AI Code Review, que analisa as mudanças em cada MR e procura vulnerabilidades que são difíceis ou inconvenientes de capturar com analisadores estáticos clássicos.
Essa é uma ressalva importante. Não estávamos tentando substituir o SAST. Os scanners clássicos são bons, mas têm um limite. Eles nem sempre entendem o contexto de negócios, as características arquitetônicas, os fluxos de autorização reais e os cenários de acesso não triviais. E, para a segurança da informação, são essas coisas que geralmente são as mais perigosas.
Quais verificações incorporamos
Em um nível básico, o agente analisa o código em busca de problemas de segurança típicos: correção de autenticação e autorização, emissão excessiva de dados, configurações de rate limiting, riscos de mass assignment, várias opções de injeções, CORS e restrições no formato e tamanho de solicitações e respostas.
Mas a principal direção para nós é o controle de violações de acesso, principalmente IDOR/ BOLA. Essas vulnerabilidades são particularmente desagradáveis porque geralmente estão escondidas em uma lógica "quase correta". O código pode parecer limpo, as solicitações podem ser parametrizadas, os testes podem passar, mas, na realidade, o usuário obtém acesso ao objeto de outra pessoa simplesmente porque, em algum lugar em um novo endpoint, eles se esqueceram de verificar a propriedade da entidade ou transferiram incorretamente a lógica de autorização ao mudar a arquitetura.
Em um produto grande que está sendo ativamente desenvolvido e refatorado, esse é um risco muito real.
Por que o IDOR se tornou uma prioridade
Em algum momento, a equipe da RuStore começou a transferir ativamente os serviços para uma nova arquitetura com uma abordagem de gateway: as comunicações externas e os pontos de entrada foram unificados, os padrões de processamento de solicitações foram alterados e os endpoints e o roteamento foram revisados.
Esse foi um movimento arquitetônico correto, mas essas mudanças são sempre perigosas do ponto de vista da degradação das antigas garantias de segurança. Você pode manter a lógica de negócios, não quebrar a funcionalidade e ainda perder imperceptivelmente parte do controle de acesso.
Na verdade, a hipótese sobre esse risco foi confirmada na prática: um dos relatórios de bug bounty trouxe um IDOR com uma violação de acesso entre projetos no console do desenvolvedor. Esse se tornou um sinal importante: essas coisas não podem ser deixadas apenas para verificações post-factum e análise manual. É necessário um controle obrigatório diretamente no estágio de code review.
Como isso está integrado ao processo
As verificações do AI Code Review são obrigatórias para iniciar: sem elas, a ramificação de lançamento não avança no pipeline. E isso por si só já muda a disciplina – cada Merge Request passa garantidamente por uma análise de IA do ponto de vista da segurança.
O próximo passo que a equipe está dando é não apenas bloquear a ausência de verificação, mas tornar as próprias descobertas bloqueadoras. Ou seja, se o agente de segurança destacar um problema crítico, o MR deve ser interrompido até que seja corrigido ou analisado conscientemente pelo líder da equipe e pelos engenheiros responsáveis.
Essa é uma diferença fundamental entre uma "dica útil" e um verdadeiro controle de proteção.
Onde o modelo teve que ser aprimorado
Aqui também não foi isento de irregularidades.
A primeira dificuldade foi que o modelo pronto inicialmente não entendia bem o contexto do nosso produto. Por exemplo, ele não levou em consideração as características da autorização interna, onde parte das verificações deve ocorrer no nível do gateway, e não em cada serviço interno. Por causa disso, muitos falsos positivos surgiram no início: o modelo reclamava de casos que eram permitidos em nossa arquitetura.
O problema teve que ser resolvido não "ajustando o modelo" como tal, mas adaptando os prompts e o contexto. Começamos a adicionar recursos de arquitetura às instruções, incluir exemplos do projeto real e gradualmente traduzir o agente do modo de "revisor universal de tudo" para o modo de assistente especializado especificamente para nossos repositórios e nossos padrões de desenvolvimento.
O segundo problema não era técnico, mas organizacional. Mesmo um bom sinal é inútil se os desenvolvedores o ignorarem ou lerem diagonalmente. Nos estágios iniciais, vimos que parte das conclusões do AI Code Review simplesmente se perde na interface: há um comentário, mas não parece algo que exija atenção imediata.
Daí duas conclusões. Primeiro, o sinal de segurança deve ser integrado ao caminho real do desenvolvedor, e não viver separadamente "em algum lugar nos logs". Em segundo lugar, para ferramentas internas de IA, o UX também é crítico. Se a saída estiver sobrecarregada, mal estruturada ou parecer apenas mais uma "conversa da rede neural", ela começará a ser ignorada.
Portanto, paralelamente à precisão da análise, também melhoramos a forma de saída dos resultados: tornamos a saída mais legível, mais específica e mais adequada para ação rápida.
O que obtivemos no final
Não gostamos de desenhar métricas artificiais onde elas não podem ser honestamente contadas. Para um agente de segurança dentro da revisão de código, outro indicador é muito mais importante: após a introdução desse controle, paramos de ver problemas repetíveis da classe para a qual ele foi criado – principalmente violações de controle de acesso e erros típicos que surgem em um contexto de mudanças arquitetônicas.
Isso não significa que o sistema se tornou perfeito. Isso significa que o controle foi incorporado à prática diária e começou a funcionar onde antes os erros escapavam para estágios posteriores.
E esse é um dos efeitos mais valiosos para a segurança da informação: encontrar um problema não em um bug bounty, não em um pentest após o lançamento e não em produção, mas no momento em que o desenvolvedor ainda está trabalhando com o MR.
Terceiro instrumento: AI DAST – quando o agente começa a se comportar como um pentester
Se o Security Check Review ajuda a filtrar tarefas e o AI Code Review ajuda a analisar o código, o próximo passo lógico é o teste dinâmico de segurança.
É isso que nosso AI DAST faz.
A solução está quase pronta para ser implementada em produção, e já podemos compartilhar o MVP e os cenários de trabalho. Essencialmente, estamos falando de um sistema multiagente para testes dinâmicos, que deve complementar o DAST clássico e remover uma de suas principais limitações: a incapacidade de testar qualitativamente APIs de produtos complexos sem um contexto real.
Por que o DAST clássico não é suficiente
Já tínhamos e temos nosso próprio circuito DAST. Ele rastreia as especificações da API, vê as mudanças e executa um conjunto de ferramentas como Nuclei, sqlmap, ZAP e outros scanners nos endpoints correspondentes.
Mas a análise dinâmica clássica tem um problema fundamental. Para testar efetivamente os endpoints de produtos reais, não basta apenas conhecer o URL e o método de solicitação. Você precisa ser capaz de coletar dados válidos: userId, appId, companyId, tokens de autorização, conexões corretas entre entidades, formato de parâmetros, sequências de chamadas permitidas. E em grandes serviços, esses dados geralmente não podem ser obtidos "em uma etapa".
Como resultado, o DAST comum captura bem as coisas básicas, mas rapidamente atinge um teto se tiver um endpoint complexo com um contexto não trivial à sua frente.
É esse teto que queremos romper com a ajuda de agentes de IA.
O que o AI DAST faz
Dentro do sistema, existem vários agentes especializados que trabalham como uma pequena equipe.
A especificação OpenAPI e a tarefa são inseridas: qual endpoint testar e em qual classe de risco prestar atenção. Em seguida, o agente entra em ação, que chamamos de Request Builder Agent dentro da equipe.
Sua tarefa não é apenas gerar um comando curl, mas construir uma solicitação válida que realmente chegue ao endpoint de destino e retorne uma resposta 2xx. Ou seja, não formalmente "coletar uma string de solicitação", mas realmente seguir o caminho que um engenheiro ou pentester seguiria ao tentar chegar a um ponto de entrada de trabalho.
Se já houver dados suficientes para a solicitação, a tarefa é simples: o agente forma rapidamente uma chamada correta e a envia para o circuito de teste.
Se os dados forem insuficientes, um cenário mais interessante começa.
Primeiro, o OpenAPI Analyzer é conectado. Ele tem um mapa de serviços e endpoints disponíveis e começa a procurar quais APIs podem ser usadas para obter os valores ausentes. Por exemplo, quais endpoints permitem descobrir a lista de aplicativos associados a um usuário ou extrair os identificadores das entidades necessárias. Essencialmente, ele constrói uma cadeia de chamadas auxiliares para obter o contexto ausente.
Se isso ainda não for suficiente, o Repository Analyzer é conectado. Ele já vai para o código do monorepositório, encontra a implementação do endpoint, rastreia o fluxo de execução, entende o esquema de validação de parâmetros e observa quais tabelas e dados o endpoint específico acessa. Isso dá uma compreensão muito mais profunda de quais valores são geralmente permitidos e o que é necessário para uma passagem bem-sucedida do cenário.
O próximo nível é o Database Analyzer. Se o sistema já entendeu quais dados estão em um banco de dados específico e em qual tabela procurá-los, o agente pode obter valores reais dos dev-stands por meio dos mecanismos fornecidos. Não "appId aproximados" abstratos, mas identificadores ativos associados a um usuário de teste ou, ao contrário, a entidades de outras pessoas.
Isso é importante porque a análise não se limita à resposta HTTP. Em vários cenários (por exemplo, ao tentar injeções – SQL, NoSQL, command, stored XSS ou race condition), externamente tudo pode parecer correto: o serviço retornará 200 OK sem alterações explícitas. Mas, ao mesmo tempo, uma gravação no banco de dados ou uma alteração nos dados pode ocorrer nos bastidores.
O Database Analyzer permite que o AI DAST verifique isso diretamente:
se erros ou anomalias apareceram nos logs do BD;
se os dados nas tabelas de destino foram alterados;
se a carga maliciosa foi processada de forma assíncrona.
Por causa disso, o sistema começa a ver vulnerabilidades cegas que os scanners DAST clássicos geralmente perdem devido à falta de contexto de execução.
E aqui começa a parte pela qual tudo foi iniciado.
Como isso se parece no exemplo do IDOR
Imagine um endpoint do tipo
GET /api/users/{userId}/apps/{appId}.
A tarefa é verificar se é possível obter acesso aos dados de outra pessoa por meio dele.
Para fazer isso manualmente, você precisa primeiro entender quais userId e appId são geralmente válidos, quais deles pertencem ao usuário atual, quais pertencem a outros, como é o token correto, quais combinações são permitidas e como o serviço se comporta ao substituir valores "próprios" e "alheios".
Para uma pessoa, esse é o trabalho normal de um pentester. Para o DAST clássico – quase um beco sem saída. E para o AI DAST – este é apenas um cenário típico.
O sistema encontra uma maneira de obter seus próprios dados, então encontra ou extrai valores de outras pessoas do banco de dados e, em seguida, constrói dois conjuntos de solicitações: um de referência, que deve funcionar, e um de ataque, que não deve passar. Se a solicitação de ataque retornar uma resposta bem-sucedida, receberemos um sinal completo de violação de controle de acesso.
Ou seja, o AI DAST não apenas executa um scanner na API. Ele coleta contexto, entende conexões, constrói cenários de trabalho e começa a agir mais perto de como um pentester real agiria.
Ajustando o equilíbrio: universalidade vs gerenciabilidade
A principal tarefa ao desenvolver o AI DAST, como no caso do Security Check Review, é encontrar um equilíbrio nas instruções para o agente. Se você defini-los muito rigidamente, ele chegará rapidamente a um resultado, mas perderá a flexibilidade e começará a funcionar pior em serviços com outra lógica. Se, ao contrário, você deixar muita liberdade, o agente pode ir para a iteração de cenários e perder tempo em pesquisas ineficientes.
Esse problema se torna especialmente perceptível se você levar em consideração o contexto do produto: temos uma arquitetura diferente e muitos serviços. Configurar o agente para cada um deles separadamente não é aconselhável. Portanto, um dos principais objetivos é criar uma ferramenta universal que possa ser aplicada sem retrabalho manual para um serviço específico.
Daí a abordagem de compromisso escolhida. Por um lado, deixamos as instruções flexíveis o suficiente para que o agente possa encontrar pontos de entrada e construir cenários por conta própria. Por outro lado, restringimos seu comportamento por meio de um conjunto de ferramentas especializadas no MCP (Model Context Protocol). Cada ferramenta resolve uma tarefa específica e torna o trabalho do agente gerenciável: obtenção e normalização de contexto, chamadas para test stands, trabalho com logs e auditoria, geração e execução de payload, verificação de direitos de acesso, reprodução de cenários e fixação de artefatos. Por causa disso, não criptografamos toda a lógica nas instruções, mas a transferimos para as ferramentas. Isso também simplifica o desenvolvimento do sistema. Quando aparece um novo tipo de descoberta manual, não reescrevemos o agente inteiro, mas adicionamos ou ajustamos a ferramenta MCP necessária e a vinculamos ao cenário correspondente.
Além disso, introduzimos um estágio de pesquisa primária. Antes de iniciar o teste, o agente recebe a especificação da API, documentação e outras fontes, coleta o contexto geral do serviço e o salva na memória de longo prazo. Isso permite que ele não comece do zero todas as vezes, mas confie na compreensão já coletada.
Paralelamente, treinamos constantemente o sistema em casos reais. Cada bug exclusivo encontrado manualmente é analisado em uma retrospectiva e transformado em melhorias do AI DAST: atualizamos as regras de prompt, adicionamos novas cadeias de ações para obter contexto e expandimos as ferramentas MCP. Como resultado, com o tempo, fechamos classes de vulnerabilidades que antes eram encontradas apenas por humanos.
O que isso dá para a empresa e a equipe
Aqui, o efeito é mais amplo do que apenas "mais uma automação".
Primeiro, é uma redução na carga sobre uma pequena equipe de segurança da informação. Cenários básicos de verificação que antes levavam muito tempo podem ser transferidos para uma ferramenta autônoma.
Em segundo lugar, é uma economia na detecção precoce de vulnerabilidades. Encontrar um problema antes do lançamento é quase sempre mais barato do que pegá-lo mais tarde por meio de bug bounty, pentest externo ou, mais ainda, por meio de um incidente.
Em terceiro lugar, é a capacidade de cobrir mais profundamente o que o DAST clássico não alcança sem participação manual. E é aqui que a IA se torna um verdadeiro amplificador de proteção.
O que tudo isso muda no trabalho da equipe de segurança da informação
Existe uma frase banal de que "a IA tira a rotina e libera tempo para tarefas interessantes". Ela já está desgastada e por si só explica pouco. Na prática, para a segurança da informação, outra formulação é mais importante: a IA tira a rotina e libera tempo para tarefas importantes.
Não se trata de os profissionais de segurança agora se sentarem e se dedicarem apenas a algo emocionante. Trata-se de que, em vez de visualizar mecanicamente centenas de tarefas que não afetam a segurança, a equipe pode analisar mais profundamente novas integrações, mudanças arquitetônicas, cenários de acesso não triviais, riscos de negócios complexos e classes de vulnerabilidades realmente perigosas.
É assim que vemos isso: tudo o que pode ser dado a um "júnior condicional na forma de uma rede neural" pode e deve ser dado. Mas a decisão sobre questões significativas, especialmente arquitetônicas e arriscadas, ainda permanece com o engenheiro.
O que a implementação da IA nos processos de segurança nos ensinou
Durante o tempo que trabalhamos nessas ferramentas, formamos várias conclusões que, como nos parece, são úteis para qualquer equipe de produto.
Primeiro:
não tente construir um controle de IA universal do zero.
Outra abordagem funciona muito melhor – pegar um processo existente e incorporar a IA como uma camada adicional. Onde já existe Security Check, code review ou DAST, a implementação se torna muito mais realista e eficaz.
Segundo:
os modelos não entendem seu produto automaticamente.
Eles terão que ser calibrados para a arquitetura, padrões de autorização, regras internas e cenários reais. Quanto mais próximo o controle de IA estiver do seu domínio, maior a chance de que ele seja realmente útil.
Terceiro:
instruções muito rígidas podem piorar o resultado.
Às vezes, uma resposta de qualidade não aparece quando você regulamentou ao máximo o modelo, mas quando deu a ele contexto suficiente e liberdade suficiente para uma conclusão significativa.
Quarto:
a IA na segurança não pode ser deixada sem supervisão.
São necessários logs, painéis, verificação manual seletiva, calibração regular. Se você parar de olhar para seus resultados, poderá perder muito rapidamente a confiança na ferramenta ou em seu próprio processo.
E quinto:
o controle de bloqueio é quase sempre mais útil do que o recomendatório
se estivermos falando de riscos realmente significativos. Mas é importante implementá-lo gradualmente – paralelamente a melhorias e aumento da confiança na qualidade das próprias verificações. Caso contrário, mesmo os controles úteis podem causar resistência ao desenvolvimento e aos negócios.
Em vez de uma conclusão
Hoje, existem muitos extremos em torno da IA na segurança. Alguns acreditam que as redes neurais em breve substituirão metade dos processos de segurança da informação. Outros, ao contrário, estão certos de que tudo isso são brinquedos e ruído da moda. Nossa experiência até agora fala de uma coisa mais realista e, como nos parece, mais útil.
A IA funciona bem onde a equipe já tem um processo maduro e uma tarefa clara. Ela não substitui a expertise, mas amplifica perfeitamente os circuitos nos quais as pessoas costumavam gastar muito tempo em ações do mesmo tipo: coleta de contexto, filtragem primária, busca de problemas típicos, preparação de cenários válidos para testes.
É neste lugar que o valor real aparece. Na RuStore, já usamos a IA para revisar tarefas de Security Check e para analisar Merge Requests no pipeline. O próximo passo é levar o AI DAST ao uso industrial e fechar outra grande camada de trabalho rotineiro, mas caro em termos de tempo.
A principal conclusão para nós é muito simples: na segurança da informação, você não precisa escolher entre "fazer tudo manualmente" e "confiar totalmente na IA". O caminho de trabalho é construir ferramentas que ajudem a equipe a ver o importante mais rapidamente, encontrar riscos mais cedo e gastar expertise humana onde ela é realmente insubstituível.
📤 Compartilhar & Baixar
📩 Newsletter MundiX
Receba novidades de cibersegurança + um checklist de pentest grátis. Sem spam.
Ao assinar você concorda em receber e-mails. Cancele quando quiser.
