Os riscos de segurança da programação não são como riscos de segurança comuns

Era provavelmente inevitável que a programação intuitiva (vibe coding) causasse uma série de mudanças complexas nas práticas de programação e no desenvolvimento de software. À medida que o código gerado por IA continua representando uma parcela maior das bases de código do mundo real, uma das mudanças mais significativas tem sido uma grande alteração na quantidade de riscos de cibersegurança, e na natureza desses riscos.

A programação intuitiva, em resumo, é a noção de construir produtos com nada além de ferramentas de IA e prompts em linguagem natural. Deve ser entendida como distinta da programação agêntica ou engenharia agêntica, que envolve o uso mais deliberado de ferramentas de programação com IA por um programador experiente. O termo foi cunhado em um tweet de Andrej Karpathy, um estimado desenvolvedor e veterano em IA, no qual ele descreveu um estilo livre de programação com IA que se baseia inteiramente em sugestões de grandes modelos de linguagem (LLM), permitindo que o usuário "se entregue completamente à intuição" e "esqueça que o código sequer existe".

Ele descreveu isso como uma abordagem divertida para "projetos descartáveis de fim de semana", mas a proliferação de poderosas ferramentas de programação com IA abriu as portas para a programação intuitiva no ambiente de trabalho, até mesmo em softwares de produção que lidam com dados sensíveis. No final de 2025, pesquisas do setor indicavam que o código gerado por IA representava 22% de todo o código incorporado.¹ No GitHub, estima-se que 46% de todo o código escrito foi gerado pelo Copilot.²

Isso gerou uma expansão significativa nas vulnerabilidades e problemas de segurança, muito além do que poderia ser explicado pelo aumento natural no volume e na velocidade de novos códigos gerados pelos assistentes de programação. Uma análise de bases de código do mundo real descobriu que, embora as equipes assistidas por IA enviassem códigos 4 vezes mais rápido, elas enviavam 10 vezes mais falhas de segurança.³

Abandonar a programação intuitiva completamente sacrificaria ganhos significativos de produtividade com a automação e o aumento da participação, mas é claro que as práticas de programação seguras precisam evoluir em resposta a isso. As verificações de segurança tradicionais são projetadas para lidar com a maneira como os desenvolvedores, mais especificamente, desenvolvedores humanos treinados, normalmente cometem erros. As organizações agora precisam de uma postura de segurança atualizada e de ferramentas de segurança atualizadas, adaptadas à nova realidade impulsionada por agentes de IA e programadores iniciantes.

Em diferentes plataformas, ambientes e LLMs, pesquisas do setor indicam consistentemente que o aumento na geração de código de IA é acompanhado por um aumento nas vulnerabilidades de segurança de aplicação (AppSec).

Por exemplo:

• Um estudo de dezembro de 2025 sobre repositórios de código aberto descobriu que os códigos gerados por IA introduziram vulnerabilidades de segurança em 45% das tarefas de desenvolvimento. Comparando pull requests (PRs) assistidos por IA com PRs exclusivos de humanos, os pesquisadores descobriram que PRs impulsionados por IA geravam 2,74 vezes mais problemas de segurança (e 1,7 vezes mais problemas no total) do que códigos criados por humanos.⁴

• Um relatório da GitGuardian de 2026 sobre a proliferação de segredos afirma que nos commits assistidos por Claude Code, a exposição de segredos mais do que dobrou em comparação com os commits feitos apenas por humanos. No total, segredos codificados no código (como senhas e chaves API) expostos em commits públicos do GitHub aumentaram 34% em 2025 em comparação com o ano anterior, representando o maior aumento anual já registrado.⁵

• Um relatório de outubro de 2025 observou que vulnerabilidades críticas e exposições de dados em aplicações programadas por intuição, como APIs mal configuradas e outros problemas de autenticação, frequentemente estavam “abertas”, acessíveis diretamente por meio de endpoints públicos.⁶

As equipes de segurança também devem considerar que os repositórios públicos no GitHub (e serviços semelhantes) são apenas a ponta visível do iceberg. O GitGuardian sugere que repositórios internos têm seis vezes mais probabilidade de conter segredos codificados no código do que repositórios públicos.

Igualmente preocupante é o fato de que, credenciais sensíveis expostas por meio de programação intuitiva, são aparentemente menos propensas a serem abordadas e remediadas do que problemas de segurança que surgem através de fluxos de trabalho de programação tradicionais. O relatório do GitGuardian observou que quase 70% das credenciais expostas que foram validadas como legítimas em 2022 permaneceram válidas até janeiro de 2025. 64% ainda estavam expostas e não revogadas em janeiro de 2026. Em um incidente notável, a Football Australia inadvertidamente expôs suas chaves de acesso AWS no código-fonte do site, elas permaneceram expostas por mais de 700 dias.

Juntos, esses padrões sugerem que os riscos de segurança da programação intuitiva estão se acumulando em uma taxa maior do que os programas tradicionais de remediação foram projetados para lidar.

A frequência e a magnitude das falhas de segurança derivadas da IA parecem persistir, mesmo à medida que a funcionalidade do LLM continua melhorando. Portanto, observadores do setor sugeriram que os pipelines de treinamento e os benchmarks usados para otimizar e validar o desempenho do modelo nem sempre estão naturalmente alinhados com a geração segura de código no mundo real.⁴ A maioria dos estudos avalia o código gerado por IA isoladamente, com foco na correção, se ele simplesmente compila, executa e realiza sua tarefa, e no desempenho em benchmarks sintéticos.⁷

Mas em ambientes de desenvolvimento empresarial, os modelos não operam isoladamente. O relatório da GitGuardian constatou que a infraestrutura relacionada ao LLM, como serviços de orquestração, geração aumentada de recuperação (RAG) ou armazenamento vetorial, expôs segredos a uma taxa cinco vezes maior do que a dos fornecedores de modelos principais.⁵

Em outras palavras, muitos riscos de segurança da programação não são derivados dos LLMs: eles são derivados do ecossistema em que os modelos são usados. Novos provedores de inferência, gateways, registros e camadas de integração entram nos fluxos de trabalho de produção muito rápido, muitas vezes rápido demais para que a postura de segurança (ou programadores inexperientes) consigam acompanhar.

A IA agêntica adiciona ainda mais complexidade às considerações de segurança: quando um agente de IA recebe acesso local a arquivos, credenciais armazenadas e terminais, o próprio computador pode se tornar outra superfície de ataque. Ataques de injeção de prompt e à cadeia de suprimentos que aproveitam as credenciais locais expostas podem se transformar em riscos organizacionais. No notório worm Shai-Hulud, que comprometeu o maior registro de JavaScript do mundo no final de 2025, quase 60% das máquinas comprometidas não eram estações de trabalho pessoais – eram executores de integração contínua/entrega contínua (CI/CD)⁴ (cujo propósito, ironicamente, é automatizar testes de segurança e garantir a qualidade do código).

Um fator importante que agrava os riscos de segurança da programação intuitiva é a forma como as alterações de código orientadas por IA são normalmente agrupadas: em média, os desenvolvedores que utilizam IA produzem mais de três vezes mais commits do que seus colegas que trabalham de forma analógica, mas agrupam esses commits em um número significativamente menor de pull requests (PRs) – e muito maiores. Esses PRs programados intuitivamente geralmente são maiores em escopo, alterando vários arquivos e serviços.

O “Developer Habits Report” da Cursor, divulgado na primavera de 2026, observou que o número médio de linhas de código por PR havia aumentado em cerca de 250% em relação ao ano anterior (e que a própria taxa de crescimento estava acelerando). Os “Mega PRs”, definidos pela Cursor como PRs contendo alterações em pelo menos 1.000 linhas de código, aumentaram de 8% do total de PRs em janeiro de 2025 para 13,9% em maio de 2026.⁸

PRs grandes e extensos que abrangem muitas partes da base de código são muito mais difíceis de fazer avaliações exaustivas do que PRs menores e mais direcionados. Alterações isoladas em um serviço ou bloco de código podem exigir alterações adicionais em outros locais para evitar problemas subsequentes, mas esses efeitos colaterais têm menos probabilidade de serem detectados na revisão, se a solicitação de pull request em análise adotar uma abordagem genérica que dilua a atenção do revisor. Uma pesquisa da Apiiro, uma plataforma AppSec, descobriu que, embora o volume de PRs das equipes assistidas por IA tenha caído quase um terço, essas equipes introduziram 10 vezes mais vulnerabilidades de segurança.³

Resumindo, a IA acelera todas as etapas da criação de código, inclusive o mau hábito de implementar muitas alterações de uma só vez. Concentrar e acelerar as mudanças também pode concentrar e acelerar o risco de cada fusão.

Um estudo em grande escala com 500.000 exemplos de código, apresentado no 36th IEEE International Symposium on Software Reliability Engineering (ISSRE 2025), determinou que “o código gerado por IA difere do código escrito por humanos não apenas no número de vulnerabilidades de segurança, mas também em sua natureza e distribuição”.

Isso levanta uma preocupação: os frameworks existentes para avaliar a qualidade do código e as vulnerabilidades de segurança são "centradas no ser humano, projetadas em torno de suposições sobre a cognição humana, os modos de erro e os processos de avaliação". O código gerado por IA demonstra características e tendências marcadamente diferentes, tornando os frameworks centrados no ser humano inadequados para sua avaliação.⁷

Para agravar o problema, pesquisas sobre os riscos de segurança da programação intuitiva também revelaram vários tipos emergentes de ataques que não têm equivalente em softwares programados por humanos.

LLMs, e as ferramentas de programação com IA que eles alimentam, tendem a recomendar pacotes que na verdade não existem – e pesquisas descobriram que esses nomes alucinados de pacotes às vezes se repetem em diferentes cenários e até modelos distintos. O slopsquatting, um tipo de ataque de alucinação de pacotes, explora essa tendência.

Os invasores de slopsquatting observam os nomes dos pacotes alucinados que os LLMs geram repetidamente e pré-registram esses nomes de pacotes fictícios em registros públicos. Quando programadores intuitivos, muitas vezes totalmente desconhecedores de pacotes comumente usados (e, portanto, com pouca probabilidade de identificar um pacote falso), enviam código contendo esses nomes de pacotes, eles estão instalando, sem saber, código malicioso.

Isso não tem analogia no desenvolvimento de software tradicional. É improvável que um programador humano alucine um pacote que não existe, e mesmo que isso acontecesse, seria impossível e impraticável para um potencial invasor prever isso, adivinhar o nome do pacote alucinado e registrar código malicioso com esse nome.

Os ataques de backdoor em arquivos de regras usam a exploração dos arquivos de configuração ("regras") usados para personalizar o comportamento de agentes de IA ao gerar ou modificar código em plataformas como Cursor, GitHub Copilot e Claude Code. 

Os invasores normalmente modificam arquivos de regras populares de código aberto, incorporando instruções maliciosas na forma de caracteres unicode ocultos que são quase impossíveis de detectar. Uma vez que essas alterações tenham sido aceitas, esse código malicioso será ativado em todas as sessões subsequentes de programação com IA que fizerem referência ao arquivo de regras infectado. Como resultado, qualquer código gerado durante essas sessões será comprometido, mas como a saída comprometida é composta por caracteres unicode que são essencialmente invisíveis, ela parece limpa na avaliação de código.

O objetivo do invasor geralmente é introduzir vulnerabilidades e "backdoors" no código gerado posteriormente (e nas aplicações que usam esse código) para que possam ser exploradas mais tarde.

Com o entendimento desses padrões específicos, as organizações devem atualizar suas melhores práticas de segurança para aproveitar as vantagens do código gerado por IA sem serem vítimas dos tipos de vulnerabilidades que surgem da programação intuitiva indiscriminada.

Embora o potencial desses defeitos de segurança possa surgir das imperfeições das ferramentas de programação com IA, a percepção desses riscos é uma falha da supervisão humana. Os desenvolvedores, em última análise, ainda estão no controle de quais adições e alterações são aceitas, revisadas ou ignoradas. Os assistentes de programação continuam expandindo e aprimorando suas barreiras integradas, mas a análise humana continua sendo a barreira final para que as vulnerabilidades de segurança não se tornem realidade, e é por isso que as configurações padrão do IBM Bob integram revisões manuais e aprovação humana em cada estágio.

Dito isso, existem maneiras de melhorar a eficácia da avaliação humana.

• Falhas ocultas em solicitações de pull requests enormes e dispersas são significativamente mais difíceis de detectar em uma verificação de segurança do que aquelas localizadas em PRs mais específicas. As equipes de segurança devem implementar diretrizes para o tamanho da PR de acordo com isso.

• Os pacotes devem passar por um exame minucioso especial para minimizar o risco de ataques slopsquatting. As equipes de segurança devem observar que, com cada nova iteração de um determinado modelo de IA, podem surgir novos padrões de alucinação de pacotes.

• Tanto os desenvolvedores quanto as equipes de segurança devem se familiarizar com as diferenças entre defeitos de código escritos por humanos e defeitos gerados por IA.

As organizações devem considerar o código gerado por IA como uma categoria de input distinta que exige controles de segurança distintos e dedicados (em vez de simplesmente integrar a produção da IA em processos de revisão padrão orientados por humanos).

Como princípio geral, a organização deve tratar qualquer código ou módulo derivado de IA como input não confiável, da mesma forma que trataria o código de biblioteca externa. Os testes de segurança e análise estática (SAST) devem ser uma porta obrigatória pela qual todas as contribuições de IA devem passar antes de entrar na base de código. Arquivos de regras de terceiros, como as regras pré-configuradas e de código aberto do Cursor, arquivosClaude.md , instruções do Copilot ou Bob Modes— devem ser cuidadosamente examinados e adicionados seletivamente a uma lista de permissões, antes de serem permitidos por padrão.

O aprimoramento contínuo das plataformas de engenharia agêntica apresenta uma oportunidade de combater fogo com fogo por meio da detecção de segredos impulsionada por IA, na qual credenciais específicas de IA, como chaves de API de LLMs ou tokens de bancos de dados de vetores, possuem assinaturas de detecção dedicadas.

 O IBM Bob, por exemplo, possui ferramentas integradas para impor programação segura e controle de acesso em escala por meio de uma combinação de modos personalizados do Bob, integração com o Hashicorp Vault e IBM MCP Gateway. Da mesma forma, ele faz avaliações de código em tempo real, escaneando o código em busca de problemas de complexidade, vulnerabilidades potenciais e oportunidades de refatoração que podem ser abordadas em linha ou avaliadas posteriormente no painel Bob Findings.

A capacidade de detectar defeitos recém-introduzidos em uma base de código depende em grande parte da legibilidade dessa base de código. Estabelecer e aplicar padrões de qualidade de código é, portanto, essencial para facilitar avaliações de segurança produtivas. Padrões compartilhados e refatoração rotineira maximizarão as chances de que códigos inseguros sejam identificados e corrigidos.