{"id":24906,"date":"2026-04-16T09:00:42","date_gmt":"2026-04-16T12:00:42","guid":{"rendered":"https:\/\/www.kaspersky.com.br\/blog\/?p=24906"},"modified":"2026-04-16T10:01:26","modified_gmt":"2026-04-16T13:01:26","slug":"open-source-vulnerabilities-in-ai-era","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.br\/blog\/open-source-vulnerabilities-in-ai-era\/24906\/","title":{"rendered":"Vulnerabilidades no c\u00f3digo aberto: agora, um problema para todas as empresas"},"content":{"rendered":"

At\u00e9 bem pouco tempo, somente as empresas especializadas em software e as gigantes em tecnologia precisavam se preocupar com as vulnerabilidades de c\u00f3digo aberto e os ataques direcionados contra a cadeia de suprimentos. Por\u00e9m, os tempos mudaram. Hoje, at\u00e9 mesmo as pequenas empresas est\u00e3o mantendo suas pr\u00f3prias lojas de desenvolvimento, e isso torna o problema significativo para todo mundo. De maneira ininterrupta<\/a>, as equipes internas de TI das empresas est\u00e3o ocupadas escrevendo c\u00f3digo, configurando integra\u00e7\u00f5es e automatizando fluxos de trabalho, mesmo que o neg\u00f3cio principal n\u00e3o tenha absolutamente nada a ver com software. \u00c9 o que a efici\u00eancia empresarial moderna exige. No entanto, como consequ\u00eancia disso, surge uma nova gera\u00e7\u00e3o de vulnerabilidades de software, o tipo muito mais complicado de corrigir do que apenas instalar a atualiza\u00e7\u00e3o mais recente do Windows.<\/p>\n

O desenvolvimento de software moderno \u00e9 insepar\u00e1vel dos componentes de c\u00f3digo aberto. Por\u00e9m, os riscos associados proliferaram nos \u00faltimos anos, al\u00e9m de terem aumentado em variedade e sofistica\u00e7\u00e3o. Estamos testemunhado a inje\u00e7\u00e3o de c\u00f3digo malicioso em reposit\u00f3rios populares, dados de vulnerabilidade fragmentados e com falhas, o uso sistem\u00e1tico de componentes desatualizados e vulner\u00e1veis e as cadeias de depend\u00eancia cada vez mais complexas.<\/p>\n

A escassez de dados de vulnerabilidade para c\u00f3digo aberto<\/h2>\n

Mesmo que sua organiza\u00e7\u00e3o tenha um processo de gerenciamento de vulnerabilidades<\/a> s\u00f3lido para software comercial de terceiros, \u00e9 poss\u00edvel constatar que o c\u00f3digo aberto requer uma revis\u00e3o completa desse processo. Os bancos de dados p\u00fablicos mais usados geralmente s\u00e3o incompletos, imprecisos ou simplesmente lentos para obter atualiza\u00e7\u00f5es quando se trata de c\u00f3digo aberto. Isso transforma a prioriza\u00e7\u00e3o de vulnerabilidades em um jogo de adivinha\u00e7\u00e3o. Por mais automa\u00e7\u00e3o que possa existir, ela ser\u00e1 in\u00fatil se os dados de refer\u00eancia estiverem cheios de falhas.<\/p>\n

De acordo com os dados da Sonatype, cerca de 65% das vulnerabilidades de c\u00f3digo aberto<\/a> atribu\u00eddas a um CVE ID n\u00e3o possuem uma pontua\u00e7\u00e3o de vulnerabilidade<\/a> (CVSS) no NVD, a base de conhecimento de vulnerabilidades mais usada. Dessas vulnerabilidades n\u00e3o pontuadas, quase 46% seriam classificadas como alta, se analisadas adequadamente.<\/p>\n

Mesmo quando uma pontua\u00e7\u00e3o CVSS est\u00e1 dispon\u00edvel, fontes diferentes est\u00e3o de acordo apenas no que se refere \u00e0 gravidade em cerca de 55% das vezes. Um banco de dados pode sinalizar uma vulnerabilidade como cr\u00edtica, enquanto outro recebe uma pontua\u00e7\u00e3o m\u00e9dia para ela. Metadados mais detalhados, como as vers\u00f5es de pacotes afetadas, tamb\u00e9m costumam estar repletos de erros e inconsist\u00eancias. Seus verificadores de vulnerabilidades que comparam vers\u00f5es de software acabam gerando falsos positivos ou fornecendo falsamente um atestado de integridade.<\/p>\n

O d\u00e9ficit nos dados de vulnerabilidade est\u00e1 crescendo e o processo de gera\u00e7\u00e3o de relat\u00f3rios est\u00e1 ficando mais lento. Nos \u00faltimos cinco anos, o n\u00famero total de CVEs dobrou, mas o n\u00famero de CVEs sem uma pontua\u00e7\u00e3o de gravidade explodiu por um fator de 37. De acordo com a Tenable, at\u00e9 2025, o c\u00f3digo de explora\u00e7\u00e3o de prova de conceito (PoC) esteve normalmente dispon\u00edvel dentro de uma semana<\/a> ap\u00f3s a descoberta de uma vulnerabilidade, mas obter a mesma vulnerabilidade listada no NVD levou em m\u00e9dia 15 dias. Os processos de aprimoramento, como atribuir uma pontua\u00e7\u00e3o CVSS, s\u00e3o ainda mais lentos, a Sonatype no mesmo estudo<\/a> estima que o tempo m\u00e9dio para atribuir uma pontua\u00e7\u00e3o CVSS \u00e9 de 41 dias, com alguns defeitos permanecendo sem classifica\u00e7\u00e3o por at\u00e9 um ano.<\/p>\n

O problema do c\u00f3digo aberto legado<\/h2>\n

Bibliotecas, aplicativos e servi\u00e7os que n\u00e3o s\u00e3o mais mantidos, que foram abandonados ou que atingiram seu fim de vida \u00fatil (EOL), podem ser encontrados em 5 a 15% dos projetos corporativos<\/a>, de acordo com a HeroDevs. Em cinco registros populares de c\u00f3digo aberto, h\u00e1 pelo menos 81 mil pacotes que cont\u00eam vulnerabilidades conhecidas, mas pertencem a vers\u00f5es desatualizadas e sem suporte. Esses pacotes nunca ver\u00e3o os patches oficiais. Essa \u201cbagagem legada\u201d \u00e9 respons\u00e1vel por cerca de 10% dos pacotes no Maven Central e no PyPI, e impressionantes 25% no npm.<\/p>\n

Usar esse tipo de c\u00f3digo aberto quebra o ciclo de vida padr\u00e3o do gerenciamento de patches: n\u00e3o \u00e9 poss\u00edvel atualizar, autom\u00e1tica ou manualmente, uma depend\u00eancia que n\u00e3o \u00e9 mais compat\u00edvel. Al\u00e9m disso, quando as vers\u00f5es EOL s\u00e3o omitidas dos boletins de vulnerabilidades oficiais, os verificadores de seguran\u00e7a podem categoriz\u00e1-las como \u201cn\u00e3o afetadas\u201d por um defeito e ignor\u00e1-las.<\/p>\n

Um excelente exemplo disso \u00e9 o Log4Shell<\/a>, a vulnerabilidade cr\u00edtica (CVSS 10) na popular biblioteca Log4j descoberta em 2021. A vers\u00e3o vulner\u00e1vel foi respons\u00e1vel por 40 milh\u00f5es<\/a> dos 300 milh\u00f5es de downloads do Log4j em 2025. \u00c9 importante ressaltar que estamos falando de uma das vulnerabilidades mais infames e amplamente relatadas da hist\u00f3ria, uma que foi ativamente explorada, corrigida pelo desenvolvedor e tratada em todos os principais produtos derivados. A situa\u00e7\u00e3o para os defeitos menos divulgados \u00e9 significativamente pior.<\/p>\n

Para agravar esse problema, existe a lacuna de visibilidade. Muitas organiza\u00e7\u00f5es n\u00e3o t\u00eam as ferramentas necess\u00e1rias para mapear uma \u00e1rvore de depend\u00eancias completa ou obter visibilidade total dos pacotes e vers\u00f5es espec\u00edficos integrados em sua pilha de software. Desse modo, os componentes desatualizados geralmente permanecem invis\u00edveis e nunca entram na fila de corre\u00e7\u00e3o.<\/p>\n

Malware em registros de c\u00f3digo aberto<\/h2>\n

Os ataques que envolvem pacotes de c\u00f3digo aberto infectados ou inerentemente maliciosos se tornaram uma das amea\u00e7as de crescimento mais r\u00e1pida para a cadeia de fornecimento de software. De acordo com pesquisadores da Kaspersky<\/a>, aproximadamente 14 mil pacotes maliciosos foram descobertos em registros populares at\u00e9 o final de 2024, um aumento de 48% a cada ano. A Sonatype relatou um aumento ainda mais explosivo ao longo de 2025 e detectou mais de 450 mil pacotes maliciosos.<\/p>\n

A motiva\u00e7\u00e3o por tr\u00e1s desses ataques varia muito: roubo de criptomoedas, coleta de credenciais de desenvolvedor, espionagem industrial, obten\u00e7\u00e3o de acesso \u00e0 infraestrutura por meio de pipelines de CI\/CD ou comprometimento de servidores p\u00fablicos para hospedar campanhas de spam e phishing. Essas t\u00e1ticas s\u00e3o empregadas tanto por grupos APT de espionagem<\/a> quanto por criminosos virtuais motivados financeiramente<\/a>. \u00c9 cada vez mais comum a viola\u00e7\u00e3o de um pacote de c\u00f3digo aberto ser apenas o primeiro passo de uma viola\u00e7\u00e3o corporativa em v\u00e1rios est\u00e1gios.<\/p>\n

Cen\u00e1rios de ataque comuns incluem comprometer as credenciais de um mantenedor de pacote de c\u00f3digo aberto leg\u00edtimo, publicar uma biblioteca \u201c\u00fatil\u201d com c\u00f3digo malicioso integrado ou publicar uma biblioteca maliciosa com um nome quase id\u00eantico a um popular. Uma tend\u00eancia particularmente alarmante em 2025 foi o aumento de ataques automatizados semelhantes a worms. O exemplo mais not\u00f3rio \u00e9 a campanha Shai-Hulud<\/a>. Nesse caso, o c\u00f3digo malicioso roubou os tokens do GitHub e npm e continuou infectando novos pacotes, eventualmente se espalhando para mais de 700 pacotes npm e dezenas de milhares de reposit\u00f3rios. Ele vazou segredos de CI\/CD e chaves de acesso \u00e0 nuvem para o dom\u00ednio p\u00fablico no processo.<\/p>\n

Embora esse cen\u00e1rio n\u00e3o esteja tecnicamente relacionado a vulnerabilidades, as ferramentas de seguran\u00e7a e as pol\u00edticas necess\u00e1rias para seu gerenciamento s\u00e3o as mesmas usadas para o gerenciamento de vulnerabilidades.<\/p>\n

Como os agentes de IA aumentam os riscos do uso de c\u00f3digo aberto<\/h2>\n

A integra\u00e7\u00e3o apressada e onipresente de agentes de IA no desenvolvimento de software aumenta significativamente a velocidade do desenvolvedor, mas tamb\u00e9m amplifica qualquer erro. Sem supervis\u00e3o rigorosa e prote\u00e7\u00f5es claramente definidas, o c\u00f3digo gerado por IA fica excepcionalmente vulner\u00e1vel. A pesquisa mostra que 45% do c\u00f3digo gerado por IA cont\u00e9m falhas da lista OWASP Top 10<\/a>, enquanto 20% dos aplicativos orientados por IA implementados abrigam erros de configura\u00e7\u00e3o perigosos. Isso acontece porque os modelos de IA s\u00e3o treinados em grandes conjuntos de dados que incluem grandes volumes de c\u00f3digo desatualizado, demonstrativo ou puramente educacional. Esses problemas sist\u00eamicos ressurgem quando um modelo de IA decide quais componentes de c\u00f3digo aberto devem ser inclu\u00eddos em um projeto. O modelo costuma n\u00e3o saber quais vers\u00f5es do pacote existem no momento, nem quais foram sinalizadas como vulner\u00e1veis. Em vez disso, ele sugere uma vers\u00e3o de depend\u00eancia extra\u00edda de seus dados de treinamento, que, provavelmente, estar\u00e1 obsoleta. Em alguns casos, os modelos tentam chamar vers\u00f5es inexistentes ou bibliotecas totalmente alucinadas. Isso abre a porta para ataques de confus\u00e3o de depend\u00eancia<\/a>.<\/p>\n

Em 2025, mesmo os principais LLMs recomendaram vers\u00f5es de depend\u00eancia incorretas, simplesmente inventando uma resposta, em 27% dos casos<\/a>.<\/p>\n

A IA pode simplesmente corrigir tudo?<\/h2>\n

\u00c9 uma ideia simples e tentadora: basta apontar um agente de IA para sua base de c\u00f3digo para que ele procure e corrija todas as vulnerabilidades. Infelizmente, a IA n\u00e3o pode resolver totalmente esse problema. Os obst\u00e1culos fundamentais que discutimos prejudicam os agentes de IA tanto quanto os desenvolvedores humanos. Se os dados de vulnerabilidade estiverem ausentes ou n\u00e3o forem confi\u00e1veis, em vez de encontrar vulnerabilidades conhecidas, ser\u00e1 necess\u00e1rio redescobrir tudo do zero. Esse processo consome muitos recursos e requer conhecimento de nicho que permanece fora do alcance da maioria das empresas.<\/p>\n

Al\u00e9m disso, se uma vulnerabilidade for descoberta em um componente obsoleto ou sem suporte, um agente de IA n\u00e3o poder\u00e1 \u201ccorrigir automaticamente\u201d a vulnerabilidade. Ainda ser\u00e1 preciso desenvolver patches personalizados ou executar uma migra\u00e7\u00e3o complexa. Se uma falha estiver profundamente oculta em uma cadeia de depend\u00eancias, \u00e9 prov\u00e1vel que a IA ignore isso completamente.<\/p>\n

O que fazer?<\/h2>\n

Para minimizar os riscos descritos acima, ser\u00e1 necess\u00e1rio expandir o processo de gerenciamento de vulnerabilidades para incluir pol\u00edticas de download de pacotes de c\u00f3digo aberto, regras operacionais do assistente de IA e o processo de compila\u00e7\u00e3o do software. Isso inclui:<\/p>\n