Em 2024, os especialistas em segurança cibernética começaram a alertar sobre uma nova ameaça à cadeia de suprimentos de software. Nomeado ‘Slopsquatting’, é um tipo de ataque cibernético em que os maus atores criam pacotes falsos contendo código malicioso que é inadvertidamente adicionado ao código legítimo.
No entanto, diferentemente de outras formas de agachamento digital, neste caso, os invasores usam pacotes que são alucinados por grandes modelos de idiomas (LLMS). Isso significa maior riscos de ataque, pois basta um programador de código gerado por um LLM sem primeiro avaliá -lo e validá -lo.
Para se proteger da nova geração de cybers invasores, as empresas precisam entender o que são alucinações de pacotes e o que pode ser feito sobre eles.
Chefe de gerenciamento de riscos na Oxylabs.
O que são alucinações de pacotes?
Línguas de codificação como Python e JavaScript se baseiam fortemente em dependências-código pré-escrito que é agrupado em pacotes como bibliotecas e módulos. Os desenvolvedores importam esses pacotes de repositórios de código público (como o Registro NPM para Node e Pypi para Python).
Com o aumento do uso da IA para codificação, programadores e pesquisadores começaram a identificar uma nova ameaça: alucinação de pacotes. É quando as ferramentas criadas no LLMS, como ChatGPT, Claude, Mistral ou Deepseek, adicionam referências ao código para pacotes que não existem.
Essas alucinações, de acordo com pesquisas recentes, estão ocorrendo com mais frequência do que se poderia esperar. Pesquisadores da Universidade de Oklahoma, Virginia Tech e Universidade do Texas em San Antonio, analisaram mais de meio milhão de fragmentos de código gerados pela LLMS. Surpreendentemente, 19,7% dos pacotes mencionados neste código eram alucinações.
Essas amostras de código, totalizando 576.000, foram geradas em duas linguagens de programação (Python e JavaScript) usando modelos como ChatGPT-4, Claude, Mistral, Deepseek e Codellama. Enquanto modelos comerciais, como Claude e ChatGPT-4, geraram menos alucinações de pacotes em seu código do que os modelos de código aberto, todos enfrentaram o problema da alucinação de pacotes em graus variados.
Abrindo a porta para uma nova forma de ataque – “Slopsquatting”
Em relação, 43% das alucinações do pacote no estudo foram recorrentes, continuando a aparecer quando os mesmos avisos foram usados. Além disso, 38% deles tinham nomes semelhantes aos pacotes reais ou com o mesmo nome que os pacotes usados em outros idiomas de codificação. São esses dois fatores – recorrência e similaridade – que criam o potencial de uma nova forma de ataque cibernético, apelidado de “desleixo”.
O nome é derivado do Typosquatting, que se originou como uma forma de fraude, onde os maus atores registram domínios com um nome semelhante aos sites legítimos, por exemplo, aqueles relacionados ao software livre. Em seguida, os usuários da Internet inserindo URLs ou prompts de pesquisa contendo erros de digitação são expostos a sites maliciosos.
A mesma idéia pode ser ajustada para explorar os erros de digitação dos desenvolvedores ao instalar pacotes de código aberto. Os hackers do White Hat usaram táticas semelhantes, alavancando erros e criando pacotes em registros públicos com o mesmo nome que os pacotes internos da empresa para se infiltrar como Shopify, Apple, PayPal, Netflix, Yelp e Uber.
No desleixo, a abordagem é semelhante, mas os pacotes utilizados são alucinados pelo LLMS. Como algumas alucinações são recorrentes, os hackers podem aprimorar nomes de pacotes específicos que provavelmente serão repetidos. Em seguida, eles criam um pacote falso usando esse nome que contém código malicioso. E como muitas alucinações de pacotes têm nomes semelhantes aos pacotes reais, eles podem ser difíceis de detectar.
Mitigando os riscos de slopsquatting usando técnicas de pré-geração
A maneira mais eficaz de proteger contra o risco de desleixo é usar técnicas de pré-geração-estratégias que reduzem preventivamente o número de alucinações de pacotes criadas.
Auto-refinamento
Alguns modelos já são capazes de detectar suas próprias alucinações com um bom grau de precisão. No estudo citado acima, os modelos GPT 4 Turbo, GPT 3.5 e Deepseek foram capazes de identificar alucinações com precisão de mais de 75%.
Isso abre a possibilidade de auto-refinamento. É quando um programador instrui um LLM a verificar e refinar sua própria saída para elaborar alucinações de eliminatórias. Depois que o modelo gerou nomes de pacotes, ele é solicitado a confirmar que cada pacote é válido. Caso contrário, a resposta é regenerada com instruções para não usar o pacote inválido.
Essa abordagem não é perfeita. Por exemplo, um modelo pode classificar erroneamente um pacote válido como inválido. Deve -se lembrar também que algumas alucinações podem ser persistentes. No entanto, ao iterar esse processo várias vezes, pode -se aumentar as chances de identificar e remover com sucesso os pacotes inválidos.
Infelizmente, o sucesso dessa abordagem é altamente dependente do modelo usado. Por exemplo, verificou -se que o Codellama de Meta tem um viés no tratamento de pacotes alucinados como válidos.
Ajustando o modelo
Outra técnica de pré-geração que é possível com modelos de código aberto, como Deepseek e Codellama, está ajustando o modelo. Isso envolve ajustar o próprio modelo para melhorar o desempenho em tarefas propensas a alucinações.
O problema dessa abordagem, no entanto, é que ela pode impactar o desempenho real do código. Portanto, embora um modelo de ajuste fino possa produzir menos alucinações de pacotes, é provável que a qualidade do código seja pior.
Geração de recuperação une a geração
Em outra técnica notável de pré-geração, a geração de recuperação (RAG), os prompts para LLMs são enriquecidos com informações de fontes de dados específicas. Isso pode ocorrer na fase do prompt inicial ou durante o refinamento e iteração.
No caso de alucinações de pacotes, é possível aumentar os avisos com um banco de dados de pacotes e descrições válidas do que esses pacotes são relevantes. O LLM pode consultar o banco de dados e adicionar respostas relevantes ao prompt, o que o ajudará a identificar com precisão pacotes válidos.
Naturalmente, essa abordagem requer um investimento inicial de tempo para criar um conjunto de dados e estruturá -lo para que um LLM possa pesquisá -lo efetivamente para identificar pacotes válidos relevantes. No entanto, essa abordagem demonstrou reduzir o número de alucinações ao usar modelos como Deepseek.
Técnicas de pós-geração para mitigar a alucinação de pacotes
Uma segunda abordagem e, sem dúvida, menos eficaz para a mitigação, é filtrar alucinações de pacotes depois que elas foram geradas.
Por exemplo, uma opção seria pegar uma lista mestre de pacotes válidos e, em seguida, referência cruzada com a saída de um LLM. Essa abordagem eliminaria nomes de pacotes inválidos. No entanto, é tão confiável quanto a lista mestre usada. Um invasor pode simplesmente adicionar seu pacote inválido a qualquer lista de mestres públicos usada, tornando -o ineficaz como defesa. Também é possível curar a lista usando métricas que estimam a validade, como sua popularidade, mas isso estaria longe de ser infalível.
Outras técnicas de pós-geração, como a digitalização em busca de conteúdo malicioso, também são improváveis de fornecer 100% de segurança. Os pacotes podem ser legítimos desde o início, mas podem ser um servidor de controle de comando em uma data posterior, que atualiza o pacote e adiciona o código malicioso.
Práticas internas robustas para verificar o código
Por fim, essa ameaça depende de agentes internos que executam o código recebido de um LLM sem primeiro validá -lo. Portanto, uma das abordagens mais eficazes que uma organização pode adotar para mitigar o risco de desleixo é garantir que eles tenham práticas robustas de verificação.
Em primeiro lugar, o código deve ser testado em ambientes seguros para evitar o risco de a cadeia de suprimentos ser envenenada. Também é crucial treinar programadores sobre os riscos potenciais de alucinações de pacotes e implementar procedimentos para revisões de código de pares.
A notificação dos revisores sobre quais partes do código foram geradas pelo LLMS aumentará a eficácia das revisões por pares. Além disso, as ferramentas de análise de dependência podem ajudar identificando possíveis vulnerabilidades e alertando pacotes suspeitos.
Resumindo: enfrentar novas ameaças
Os LLMs estão revolucionando a maneira como os programadores funcionam. No entanto, como mostra o exemplo de alucinações de pacotes, com todos os novos empreendimentos nesses modelos, novos riscos ocorrem. Ao empregar uma combinação de técnicas de pré e pós-geração e garantir que as melhores práticas internas estejam em vigor, as empresas podem continuar a desfrutar dos benefícios do código gerado por LLM enquanto mitigam o risco de desleixo.
Listamos a melhor distro Linux para desenvolvedores.
Este artigo foi produzido como parte do canal especialista da TechRadarPro, onde apresentamos as melhores e mais brilhantes mentes do setor de tecnologia hoje. As opiniões expressas aqui são as do autor e não são necessariamente as do TechRadarpro ou do Future Plc. Se você estiver interessado em contribuir, descubra mais aqui:
Deixe um comentário
Você precisa fazer o login para publicar um comentário.
Fique conectado