Como é ser um hacker hoje em dia?

Em poucos anos, o desenvolvimento assistido por Inteligência Artificial deixou de ser experimental para se tornar parte do dia a dia de times de produto, freelancers e criadores de conteúdo. Ferramentas como ChatGPT, Copilot, Gemini e modelos open source agora escrevem desde pequenos scripts até aplicações web completas, muitas vezes implantadas quase sem revisão humana. Relatórios recentes mostram que isso está abrindo uma nova frente para atacantes: a combinação entre a explosão de novas aplicações expostas na internet e um volume preocupante de vulnerabilidades em código gerado por IA. Segundo pesquisa da Veracode, cerca de 45% dos trechos de código produzidos por modelos de linguagem contêm falhas de segurança identificáveis, com taxas ainda piores em linguagens como Java, enquanto outros estudos apontam que modelos populares produzem código vulnerável por padrão quando recebem prompts ingênuos, sem preocupação explícita com segurança.

Ao mesmo tempo, relatórios como o Verizon Data Breach Investigations Report (DBIR) 2024 e análises subsequentes mostram um crescimento acentuado no uso de exploração de vulnerabilidades em aplicações web como vetor inicial de ataque, com aumento próximo de 180% nesse tipo de exploração em alguns recortes de dados. Para muitas organizações, especialmente pequenas empresas e criadores que usam geradores de código para lançar rapidamente sites, bots e painéis, isso significa que estão publicando superfícies de ataque novas, frágeis e com pouca ou nenhuma observabilidade. Hackers, por outro lado, contam com automação madura, scanners e até próprios modelos de IA para identificar falhas triviais em massa, desde injeção de SQL e XSS até problemas de autenticação e autorização.

Cenários práticos: quando IA vira atalho também para atacantes

Um dos sinais mais claros dessa mudança vem de pesquisas com desenvolvedores e times de AppSec. O relatório “State of AI in Security & Development 2026”, da Aikido Security, identificou que quase um quarto de todo o código em produção já é escrito por ferramentas de IA, e que cerca de 70% dos entrevistados encontraram vulnerabilidades introduzidas diretamente por esse código. Em aproximadamente 20% das organizações ouvidas, esses problemas já resultaram em incidentes graves com impacto material no negócio, como indisponibilidade significativa ou vazamento de dados. Em paralelo, a própria Veracode observou que, quando modelos de IA podem escolher entre uma implementação segura e outra insegura, eles optam pela versão vulnerável em cerca de 45% dos casos.

Outro estudo, conduzido pela Backslash Security e divulgado em 2025, mostrou que alguns dos modelos mais populares de larga escala geram código inseguro por padrão na maioria das respostas quando recebem apenas um pedido simples do tipo “construa uma API de login” ou “crie um formulário de upload de arquivo”, sem qualquer menção a requisitos de segurança. Mesmo quando o prompt reforça que o código deve seguir boas práticas OWASP ou ser “seguro”, cinco de sete modelos ainda produzem implementações com vulnerabilidades mapeadas em categorias críticas do Common Weakness Enumeration (CWE), incluindo injeção de comandos, XSS em frontend e backend, upload de arquivos inseguros e traversal de diretório. Em um dos piores casos, apenas 10% das saídas geradas eram consideradas livres de falhas sob prompts ingênuos.

Do lado dos atacantes, a mesma lógica de automação se aplica. Relatórios recentes do DBIR e de provedores de segurança de nuvem apontam para um crescimento forte no número de incidentes em que o vetor inicial é a exploração automatizada de vulnerabilidades em aplicações web recém-expostas, muitas vezes rodando em plataformas de nuvem. Há menções a aumentos na casa de 180% em brechas iniciadas por exploração de falhas conhecidas em serviços na borda e VPNs, e análises que indicam que algo em torno de 40% das explorações bem-sucedidas recaem sobre aplicações web. Em paralelo, estudos acadêmicos sobre geração segura de código mostram taxas de vulnerabilidades em blocos gerados por LLMs variando de cerca de 10% até mais de 40%, dependendo da tarefa, do modelo e do conjunto de avaliação, reforçando que não se trata de casos isolados, mas de um padrão estatístico preocupante.

Na prática, o que isso significa para um site ou aplicação gerada rapidamente com IA? Significa que aquele painel administrativo criado em um fim de semana, o formulário de captura de leads colado diretamente de uma resposta do modelo, ou o bot de atendimento com backend improvisado em um serviço serverless podem carregar combinações extremamente previsíveis de erros: ausência de validação de entrada, autenticação frágil, tokens expostos em código, logs que gravam informações sensíveis em claro, entre outros padrões clássicos do OWASP Top 10. Em ambientes de teste, esses problemas são incômodos. Em produção, expostos à internet, viram um convite aberto para exploração automatizada por scanners e kits de ataque.

Por que isso está acontecendo: velocidade, confiança excessiva e contexto ausente

Existem alguns fatores estruturais que explicam por que hackers estão achando cada vez mais fácil comprometer sites e aplicações geradas com ajuda de IA. O primeiro é o descompasso entre velocidade de desenvolvimento e maturidade de segurança: modelos generativos tornaram trivial produzir grandes quantidades de código funcional em minutos, mas o processo de revisão, teste, threat modeling e correção continua essencialmente manual e lento. Pesquisas como as da Veracode e de outros grupos mostram que, embora a qualidade sintática do código gerado por IA tenha melhorado, o desempenho em termos de segurança permanece praticamente estagnado ao longo do tempo, mesmo em modelos mais novos e maiores.

O segundo fator é a natureza dos dados de treinamento e do próprio problema que os modelos tentam resolver. Estudos acadêmicos recentes apontam que LLMs treinados em grandes quantidades de código de repositórios públicos, que por si só contêm volumes consideráveis de exemplos inseguros, tendem a replicar esses padrões em suas respostas, inclusive para tarefas de segurança crítica. Em benchmarks específicos de geração de código seguro, muitos modelos apresentam taxas de vulnerabilidade que variam de aproximadamente 9,8% a mais de 40% conforme o cenário de teste e o tipo de vulnerabilidade avaliado, com alguns modelos recentes inclusive se saindo pior do que versões anteriores em determinados conjuntos. Isso sugere que melhorias em capacidade geral nem sempre se traduzem em melhorias em segurança.

Há ainda um terceiro elemento, mais humano: a forma como desenvolvedores, criadores de conteúdo e gestores interpretam a saída da IA. Estudos sobre uso de assistentes de código em contexto educacional e profissional indicam uma tendência a superestimar a segurança de trechos gerados, especialmente quando eles funcionam corretamente do ponto de vista funcional. Quando o código “roda” e entrega o resultado esperado, é comum que seja aceito sem a devida revisão de segurança, principalmente em equipes pequenas ou em cenários de pressão por prazos curtos. Esse viés de confiança excessiva, somado à percepção equivocada de que “se veio da IA deve estar seguindo boas práticas modernas”, cria um espaço ideal para falhas triviais passarem para produção.

Do lado ofensivo, a própria IA também está sendo usada para atacar. Ferramentas de varredura automática já incorporam modelos de linguagem para analisar respostas de aplicações, gerar payloads ligeiramente modificados e contornar filtros simples, enquanto agentes automatizados conseguem encadear etapas de reconhecimento, exploração e movimento lateral com intervenção humana mínima. O resultado é um cenário em que um erro “simples” em um formulário gerado por IA pode ser localizado e explorado em minutos, enquanto a correção pode levar dias ou semanas, especialmente em organizações que não têm esteiras de CI/CD com testes de segurança automatizados.

Recomendações técnicas e não técnicas para reduzir o risco

Diante desse cenário, não faz sentido assumir que um site ou aplicação gerada com IA está segura “por padrão”. Ao contrário: a postura saudável é presumir que o código está vulnerável até que se prove o contrário. Sob essa premissa, algumas medidas técnicas passam a ser praticamente obrigatórias para qualquer coisa que vá enfrentar a internet mesmo que seja “só um MVP” ou uma landing page. Isso inclui o uso sistemático de análise estática (SAST) e dinâmica (DAST) na pipeline, scanners de dependências para bibliotecas de terceiros, configuração de WAF ou outros controles de filtragem na borda, e monitoramento básico de logs e eventos suspeitos.

• Trate IA como estagiário, não como arquiteto:

• • use modelos para acelerar rascunhos de código, mas mantenha a revisão humana obrigatória, especialmente em pontos que lidam com autenticação, autorização, criptografia, pagamentos ou dados sensíveis.
  
  
  Padronize prompts “seguros”:

• • crie templates de prompts internos que sempre incluam requisitos mínimos de segurança (por exemplo, validação de entrada, tratamento de erros, logs sem dados sensíveis, proteção contra CSRF/XSS) e treine o time a usá-los de forma consistente. 
  
  
  Automatize o mínimo viável de AppSec:

• • mesmo times pequenos podem integrar scanners open source, testes de segurança em pull requests e checklists automáticos na pipeline de CI/CD para evitar que código obviamente inseguro chegue à produção. 
  
  
  Implemente segmentação e princípio do menor privilégio:

• • não exponha diretamente à internet serviços internos gerados rapidamente com IA; coloque-os atrás de camadas intermediárias, limite o acesso e use credenciais específicas com escopo restrito para cada componente. 
  
  
  Documente decisões de risco:
  
  se algo precisar ir ao ar com uma vulnerabilidade conhecida (por exemplo, por causa de uma dependência ainda sem correção), registre esse risco, as medidas de mitigação temporária e um prazo claro para resolução.

Mas nem todas as recomendações são técnicas. Talvez a mudança mais importante seja cultural: abandonar de vez a ideia de que “se ninguém está atacando o meu site, então está tudo bem”. A realidade descrita por relatórios como o DBIR é de varredura contínua e automatizada: se a sua aplicação estiver na internet, ela será testada por bots e ferramentas maliciosas em algum momento. Por isso, é prudente partir do princípio de que sua aplicação está vulnerável até que auditorias e testes indiquem o contrário — e, ainda assim, manter a desconfiança saudável de que novos bugs podem surgir a qualquer atualização.

Outra recomendação não técnica, mas extremamente prática, é repensar que tipo de dado você aceita armazenar nesses sistemas. Mesmo que a aplicação pareça simples, se ela coleta informações altamente sensíveis (como dados financeiros, documentos oficiais, dados de saúde ou credenciais de acesso a outros sistemas), o impacto potencial de um vazamento é desproporcional ao valor do produto. Em muitos casos, é mais seguro e juridicamente adequado delegar esse armazenamento para provedores especializados com certificações de segurança e controles de conformidade robustos, usando integrações bem projetadas em vez de manter bases sensíveis em um backend improvisado.

O papel do controlador de dados perante a ANPD (e o risco para você)

No contexto da Lei Geral de Proteção de Dados (LGPD), quem decide sobre as finalidades e os meios de tratamento de dados pessoais atua como controlador e isso vale tanto para grandes empresas quanto para pequenos negócios e profissionais individuais que mantêm um site ou aplicação com coleta de dados. A LGPD exige que agentes de tratamento adotem medidas técnicas e administrativas adequadas para proteger dados pessoais contra acessos não autorizados e incidentes como destruição, perda, alteração ou vazamento, conforme previsto, por exemplo, no artigo 46 da lei e em análises jurídicas especializadas. Em outras palavras: ao optar por lançar um site ou app gerado por IA, você continua responsável pela segurança dos dados que coleta, independentemente de quem escreveu o código.

Quando um incidente de segurança envolve dados pessoais e pode gerar riscos ou danos relevantes aos titulares, o artigo 48 da LGPD e os regulamentos recentes da Autoridade Nacional de Proteção de Dados (ANPD), como a Resolução nº 15/2024, impõem ao controlador o dever de comunicar o incidente tanto à própria ANPD quanto aos titulares afetados, em prazo curto e com nível de detalhamento significativo. Isso inclui descrever a natureza dos dados impactados, os titulares envolvidos, os riscos decorrentes, as medidas de segurança existentes e as ações tomadas para mitigar o dano. Há inclusive guias oficiais que tratam desse procedimento de Comunicação de Incidente de Segurança (CIS), reforçando que não se trata de uma formalidade opcional, mas de uma obrigação legal com potencial de fiscalização e sanções.

Ignorar esse cenário pode sair caro. Além de multas administrativas e outras sanções da ANPD, como determinações de suspensão de tratamento ou ampla divulgação do incidente, um vazamento decorrente de uma aplicação gerada às pressas com IA pode causar danos reputacionais duradouros, perda de confiança de clientes e parceiros, litígios civis e custos operacionais altos para resposta a incidentes. Do ponto de vista prático, isso significa que a decisão de “confiar” em um site ou app construído rapidamente por modelos de IA sem uma estratégia séria de segurança não é apenas um risco técnico; é um risco jurídico e de negócio que recai diretamente sobre o controlador de dados. Assumir desde o início que sua aplicação está vulnerável, limitar ao máximo o volume e a sensibilidade dos dados armazenados e estruturar um plano mínimo de segurança e resposta a incidentes deixa de ser boa prática para se tornar, na prática, uma linha de defesa entre você e um problema sério perante a ANPD.

Pesquisa e adaptação: N00TROPX1C — NULLTROPIC, 2026. Fontes utilizadas incluem o Verizon Data Breach Investigations Report (2024–2025), estudos da Veracode sobre código gerado por IA, pesquisas acadêmicas sobre geração segura de código com LLMs, análises da Backslash Security e documentos oficiais da ANPD sobre incidentes de segurança e deveres do controlador de dados.