O problema dos 89%: como os LLMs estão trazendo de volta a “maioria adormecida” do código aberto

Assistentes de programação com IA estão trazendo de volta, discretamente, milhões de pacotes de código aberto abandonados. Na última década, os desenvolvedores confiaram em uma heurística simples para a segurança do código aberto: Popularidade \= confiança. Se um pacote tinha milhões de downloads por semana (lodash, react, requests), presumíamos que era “seguro o bastante” porque milhares de pessoas o analisavam. Se era pouco conhecido, tínhamos cautela.

Desenvolvedores humanos seguem sinais sociais de confiança, como popularidade, atividade de manutenção e adoção pela comunidade. Esse modelo da “sabedoria das multidões” funcionava porque os desenvolvedores são, por natureza, sociais. Seguimos os “caminhos pavimentados” por nossos pares. Mas a IA generativa está começando a romper esse modelo.

Os sistemas de IA selecionam pacotes com base em padrões estatísticos nos dados de treinamento, que abrangem toda a história da internet, incluindo milhões de projetos abandonados e repositórios experimentais. Os LLMs são estocásticos: não entendem “popularidade” nem “saúde da manutenção” como um arquiteto ou engenheiro humano. Em vez disso, entendem probabilidades estatísticas com base em dados de treinamento que cobrem toda a história da internet — o que é bom, ruim e abandonado.

Criamos o Snyk Advisor e depois o incorporamos ao nosso Security DB para ajudar a preencher a lacuna entre inteligência de código aberto e saúde dos pacotes, oferecendo a desenvolvedores e agentes diversos dados sobre segurança, popularidade, manutenção e comunidade. Como a inteligência sobre a saúde dos pacotes da Snyk potencializa agentes de IA? Veja nossa perspectiva.

Os dados: visualização da “maioria adormecida”

Ao analisar o ecossistema de código aberto, surge um padrão impressionante. Um número muito pequeno de pacotes sustenta a maior parte da internet moderna, enquanto a grande maioria é pouco usada ou foi completamente abandonada.

Para entender o risco, precisamos revisitar a estrutura do ecossistema de código aberto. A Snyk contribuiu com dados importantes para o relatório Census II da Linux Foundation e de Harvard, que mapeia a realidade da cadeia de suprimentos. Quando sobrepomos os dados de saúde dos pacotes à prevalência, surge uma hierarquia clara:

Quase 90% do ecossistema de código aberto pertence à maioria adormecida: milhões de experimentos, forks e projetos abandonados sem manutenção. Desenvolvedores humanos raramente escolhem pacotes dessa faixa; sistemas de IA, porém, escolhem.

A desconexão da IA

Desenvolvedores humanos naturalmente permanecem nas faixas superiores do ecossistema: frameworks amplamente usados, bibliotecas de infraestrutura confiáveis e ferramentas maduras de domínio específico. Como os LLMs são treinados com vastos repositórios de código que abrangem toda a história da internet, podem indicar pacotes de qualquer parte do ecossistema, inclusive da maioria adormecida.

Como resultado, os LLMs podem recomendar pacotes dos 89,5% inferiores do ecossistema: projetos abandonados, forks sem manutenção e até experimentos simples de “Hello World”. Por exemplo, o pesquisador de segurança Luke Hinds compartilhou uma interação em que um LLM recomendou o pacote Go gorilla/sessions:

O problema com essa recomendação do LLM é que o gorilla/sessions foi arquivado. Como repositórios arquivados não recebem mais atualizações, usar esse pacote gera dívida de manutenção de longo prazo e riscos de cadeia de suprimentos sem correção.

Pior ainda: os LLMs têm alucinações (ou “alucinações de pacotes por IA”) e recomendam com confiança pacotes que nunca existiram. Isso cria dois novos vetores de ataque:

1. A ressurreição zumbi: um LLM sugere um pacote sem manutenção, com cinco anos de idade, da “maioria adormecida”, por resolver um problema de nicho específico. Ele não tem CVEs (porque ninguém procura), mas contém falhas críticas.

1. Slopsquatting (ataques por alucinação de IA): invasores preveem nomes comuns de pacotes que os LLMs alucinam (por exemplo, huggingface-cli-tool em vez do verdadeiro huggingface-cli) e os registram com código malicioso. Quando uma IA sugere esse pacote “lógico”, mas falso, o desenvolvedor instala malware.

A mudança estratégica: da “popularidade” à “procedência”

Como CISO, você não pode depender dos desenvolvedores para avaliar manualmente cada sugestão da IA. A velocidade é alta demais. É preciso mudar o foco do programa: em vez de “procurar o que é ruim”, “garantir o que é bom”. Em textos anteriores, explicamos as responsabilidades dos CISOs e como elas estão evoluindo.

Da mesma forma, como engenheiro, você simplesmente não pode depender de ponta a ponta de agentes de programação com IA para escolher e instalar pacotes do npm ou PyPI, devido aos riscos inerentes à cadeia de suprimentos de software. Um pacote malicioso pode introduzir malware ou coletar dados, por exemplo, usando os recursos do gerenciador de pacotes postinstall do npm.

Como fornecer aos agentes de programação com IA e aos engenheiros de software heurísticas de saúde dos pacotes para obter resultados mais seguros e autônomos? Com o caminho pavimentado da Snyk.

1. Encontre pacotes confiáveis em security.snyk.io

Antes de selecionar uma dependência, desenvolvedores e sistemas de IA precisam conhecer a reputação e a confiabilidade dos pacotes de código aberto. A nova experiência do Snyk Security Database oferece uma visão centralizada dos sinais de confiança dos pacotes, ajudando as equipes a identificar rapidamente projetos amplamente adotados, bem mantidos e confiáveis nos ecossistemas compatíveis.

Estratégia: incentive desenvolvedores e equipes de plataforma a consultar os insights do Snyk Security Database durante a busca por pacotes, priorizando dependências maduras e confiáveis desde o início do processo de seleção.

2. A Snyk Package Health API ajuda a verificar a saúde, não apenas as vulnerabilidades

Um pacote sem vulnerabilidades conhecidas não é necessariamente seguro. Ele pode estar abandonado, sem manutenção ou sem uma comunidade confiável. Para proteger a cadeia de suprimentos de software, é preciso avaliar a saúde dos pacotes além dos CVEs. A Snyk Package Health API oferece inteligência sobre pacotes e versões nos principais ecossistemas (npm, PyPI, Maven, NuGet e Go), com sinais como:

• Postura de segurança.

• Atividade de manutenção e indicadores de ciclo de vida.

• Métricas de popularidade e adoção.

• Sinais de participação da comunidade.

Assim, plataformas de engenharia, pipelines de CI/CD e ferramentas de desenvolvimento com IA podem avaliar automaticamente a qualidade, a sustentabilidade e o risco de uma dependência no ecossistema no momento em que ela está sendo considerada — sobretudo quando é selecionada ou adicionada.

Estratégia: integre a inteligência sobre a saúde dos pacotes diretamente aos fluxos de seleção de dependências e aos ambientes de desenvolvimento com assistência de IA. Assim, você avalia se um pacote é adequado antes de adicioná-lo, e não depois da instalação.

Ferramentas: use a Snyk Package Health API para orientar a seleção de pacotes, o planejamento de atualizações e a governança automatizada de dependências. Consulte o endpoint em nível de pacote e o endpoint em nível de versão do pacote para ver detalhes de implementação.

Se você integrar uma solução de SCA via CLI, CI ou verificações de CI do GitHub, a Snyk Open Source também identificará essas recomendações ruins de programação feitas por LLMs durante e antes da compilação (imagine o agente de programação planejando executar um npm install … para instalar um pacote malicioso).

3. Garanta a segurança das dependências desde o momento em que são adicionadas com Snyk Studio

Mesmo quando há inteligência disponível, desenvolvedores e assistentes de programação com IA ainda podem adicionar dependências automaticamente. A segurança também precisa ser garantida no momento em que uma dependência é selecionada, e não apenas durante as verificações de CI/CD.

O fluxo de saúde de pacotes do Snyk Studio integra inteligência sobre a saúde dos pacotes diretamente aos fluxos de desenvolvimento com assistência de IA. Quando um assistente de programação com IA propõe adicionar ou atualizar uma dependência, o Snyk Studio pode executar automaticamente uma verificação de saúde do pacote antes da instalação, avaliando os sinais de risco em tempo real. Assim, as organizações podem impedir que pacotes sem saúde, sem manutenção ou arriscados entrem na base de código desde o estágio mais inicial possível: o momento de “proteger desde a origem”.

Estratégia: configure os assistentes de programação com IA para executar automaticamente verificações de saúde dos pacotes antes de adicionar novas dependências, pausando ou bloqueando a instalação quando houver sinais de risco e exigindo a aprovação explícita do usuário para prosseguir.

4. Proteja-se contra alucinações

Às vezes, assistentes de programação com IA recomendam pacotes que não existem em registros públicos. Esses eventos de “pacote não encontrado” devem ser tratados como possíveis sinais de segurança da cadeia de suprimentos, e não como simples erros do desenvolvedor, pois invasores podem registrar posteriormente pacotes com nomes semelhantes para explorar essas falhas.

Estratégia: trate falhas na resolução de dependências (por exemplo, “pacote não encontrado”) como eventos relevantes para a segurança. Investigue a origem da sugestão da dependência e confirme se o nome do pacote é legítimo antes de prosseguir.

Na imagem a seguir, você pode ver como o Snyk Studio é acionado pelo agente de programação Windusrf para analisar a saúde do pacote por meio da ferramenta snyk_package_health_check, que faz parte de outras ferramentas de segurança no Snyk MCP Server. Com o Snyk Studio instalado, o agente de IA pode confirmar que o pacote tem manutenção ativa, não apresenta problemas de segurança e não é malicioso.

A missão da Snyk: proteger o código gerado por IA

Criamos a Snyk com a convicção de que a segurança que prioriza os desenvolvedores é a única forma de ganhar escala. No mundo dos agentes de programação com IA, isso é ainda mais verdadeiro. Os dados do Census II mostram que o ecossistema de código aberto é vasto e, em sua maior parte, está adormecido.

Nosso trabalho é manter sua IA e seus desenvolvedores concentrados nas faixas superiores, saudáveis e vibrantes: os 10% que movem o mundo, e automatizar as defesas contra os 90% caóticos. Não deixe a IA verificar a confiança. Verifique a confiança da IA.

Quer saber mais sobre como os assistentes de programação com IA estão transformando os riscos da cadeia de suprimentos de software? Confira nosso guia sobre como proteger Python na era da IA.