Espere até que os agentes de IA sejam comprometidos...

Portuguêsالعربية Deutsch English Español Français हिन्दी Bahasa Indonesia 日本語 한국어 Русский 中文

MMaximilian Schwarzmüller

Computing/SoftwareBusiness NewsInternet Technology

Transcript

00:00:00Estou gravando isso algumas horas após um ataque extremamente devastador à cadeia de suprimentos

00:00:06ter começado. Um ataque que se espalhou para muitos outros pacotes NPM e também Python. E no

00:00:13momento em que estou gravando isso, ainda não está claro quando e onde terminará. E eu

00:00:19criei um vídeo separado no meu canal do YouTube onde me aprofundo neste ataque específico

00:00:25porque foi bem elaborado. Eu faço uma análise detalhada lá e explico todos os detalhes porque

00:00:30isso é bem interessante. Mas aqui quero falar sobre ataques à cadeia de suprimentos, segurança e IA

00:00:38nesta era em que vivemos. Porque tenho certeza de que as coisas vão

00:00:45piorar. E temo que muitas pessoas ainda não vejam todos os perigos. E há mais que nós,

00:00:54como desenvolvedores e usuários de tecnologia e IA, para ser sincero, temos que fazer. E isso nos afeta mesmo

00:01:01se não formos desenvolvedores. Sei que a maioria das pessoas que assiste ou ouve isso são desenvolvedores. Mas,

00:01:07como deixarei claro, não se trata apenas de escrever código e não apenas de ataques à cadeia

00:01:13de suprimentos como vocês conhecem. Mas vamos começar pelo básico. O que é um ataque à cadeia de suprimentos?

00:01:20No contexto do desenvolvimento de software, significa apenas que uma dependência que você

00:01:26está usando foi comprometida. Em resumo, é disso que se trata. E comprometida,

00:01:35é claro, pode significar todo tipo de coisa. O que normalmente vemos é a inserção de código malicioso

00:01:41no pacote comprometido para coletar credenciais e tokens. Ele varre seu disco rígido para encontrar

00:01:49segredos que você possa ter em arquivos .env ou suas credenciais da AWS e assim por diante. E então usa essas

00:01:56credenciais para acessar suas contas e também para se propagar. Ou seja, para afetar outros pacotes. Se

00:02:04você é um mantenedor de pacotes de código aberto ou mesmo fechado, se está trabalhando em algo,

00:02:11algum pacote ou ferramenta que outros usam, é claro que interessa comprometer sua

00:02:19máquina para comprometer esse pacote ou ferramenta que você distribui porque, adivinhe,

00:02:26isso afetará ainda mais pessoas. Todos esses ataques à cadeia de suprimentos que vemos, incluindo o

00:02:32que começou aqui com os pacotes Tanstack, são vermes que se espalham para

00:02:38outros pacotes para afetar mais e mais pacotes e, por fim, as máquinas onde

00:02:44esses pacotes são instalados e usados. Agora, há coisas que você pode fazer para se proteger e

00:02:51eu criei um vídeo separado sobre isso no meu outro canal, o canal Academind. Coisas como garantir

00:02:56que você só instale pacotes com pelo menos três dias de idade, ou algo assim,

00:03:02refiro-me às versões dos pacotes, executando seu código em um dev container ou máquina virtual.

00:03:08Estas são coisas que você deve fazer. Você também não deve armazenar segredos em texto simples no sistema.

00:03:15Em vez disso, use um serviço como Infisical ou Doppler, ou algo similar, onde você armazena segredos

00:03:22na nuvem ou de outra forma criptografada para que, se um invasor escanear seu sistema,

00:03:28ele não veja esses segredos em texto simples. Isso é essencial agora. É importante

00:03:37porque esses ataques estão aumentando. Estamos vendo mais deles e por que isso ocorre?

00:03:42Certamente não é porque não era possível realizar ataques assim há muitos anos.

00:03:49Era possível e acontecia na época, mas a frequência aumentou drasticamente,

00:03:56é claro, e a IA é um grande motivo aqui. Então, vamos analisar o papel da IA. Ela é um grande fator

00:04:06porque, obviamente, facilita a execução de tais ataques. Se você é um invasor, pode

00:04:14usar a IA para analisar todos os tipos de repositórios de pacotes que deseja comprometer

00:04:22para ver: como eles constroem seus pacotes? Como os distribuem? Por exemplo,

00:04:30no ataque à Tanstack que iniciou este caso recente, os mantenedores usavam uma

00:04:38abordagem teoricamente segura usando o processo de publicação confiável do NPM. Novamente,

00:04:45eu detalho isso no outro vídeo, mas o que eles também fizeram foi usar um

00:04:51determinado gatilho de evento no GitHub Actions de uma forma que não estava perfeitamente protegida,

00:05:00permitindo que o invasor usasse envenenamento de cache para levar código malicioso de um ambiente não confiável

00:05:07para um ambiente confiável. Foi assim que começou. Detalhes naquele outro vídeo.

00:05:15Mas, claro, a IA facilita a análise de repositórios, de fluxos de trabalho do GitHub Actions

00:05:22ou de qualquer outro provedor de CI/CD. A IA pode analisar em massa todos esses scripts e códigos,

00:05:30buscando vulnerabilidades de segurança. E os mantenedores também podem usar a IA para escanear seus

00:05:38repositórios em busca de vetores de ataque, mas, como invasor, você tem vantagem natural

00:05:45porque pode procurar por tudo e tentar qualquer coisa, enquanto um mantenedor

00:05:52precisa antecipar tudo. A IA ajuda, mas ainda não é perfeita.

00:05:58O invasor leva vantagem e a IA simplificou isso. A IA também, claro, simplifica

00:06:04o processo de escrever código malicioso. Ela simplifica a escrita de qualquer código e,

00:06:12se você viu meus outros vídeos ou ouviu outros episódios, sabe que sou um grande defensor de

00:06:20analisar o código, fazer revisões e não terceirizar tudo para a IA. Mas,

00:06:27obviamente, você deve usar a IA como um reforço de produtividade. Ainda estamos descobrindo

00:06:33qual o nível ideal de uso. Alguns dirão 100%, nem olham para o código.

00:06:40Para mim não é assim, mas há um espectro. De qualquer forma, a IA facilita

00:06:46a geração de muito código. Se falamos de código malicioso, há certos

00:06:53pontos importantes. Se você é um invasor, quer um código que funcione e que

00:06:59não seja fácil de detectar, mas não importa se o código é bonito ou segue as melhores

00:07:06práticas. Sua melhor prática é que o ataque funcione. E a IA pode ajudar nisso,

00:07:13ajudando a escrever esse código malicioso e sugerindo ideias de como atacar

00:07:19pacotes. Essa é uma parte, mas facilitar as coisas é apenas um lado da história.

00:07:26O outro lado muito importante é que há mais código do que nunca. Isso significa que há mais

00:07:35alvos do que nunca. Talvez você tenha acompanhado aquela postagem ou a história sobre os

00:07:43problemas de confiabilidade e quedas do GitHub. Bem, o motivo é que há mais código sendo

00:07:49enviado ao GitHub do que nunca devido à IA. Gerar código está mais fácil

00:07:55e mais pessoas o fazem, incluindo muitas que não têm ideia

00:08:02do que esse código faz. O “wipe coding” é uma tendência e tem seus casos de uso. Por exemplo,

00:08:11se eu quiser unir cinco PDFs em um, fico feliz em dizer a um agente de IA para fazer isso

00:08:18e ele provavelmente escreverá um código que funcione. Eu não me importo com o código, é uma tarefa única.

00:08:24Mas se eu rodar isso no meu sistema, o agente pode instalar algum pacote para unir

00:08:32os PDFs que foi afetado por um ataque à cadeia de suprimentos. Eu nem saberia que o

00:08:37pacote foi usado se eu não verificar, pois só queria unir os PDFs.

00:08:43Há mais situações do que nunca onde pacotes estão sendo instalados porque

00:08:49há mais código sendo escrito, tanto para softwares quanto para tarefas únicas. Isso,

00:08:56obviamente, torna esses ataques à cadeia de suprimentos mais atraentes do que nunca

00:09:01porque há mais alvos, incluindo muitos que não sabem nada sobre segurança de software,

00:09:06cibersegurança ou algo do tipo. E sejamos sinceros, muitos de nós, desenvolvedores, podemos

00:09:14conhecer os riscos teoricamente, mas não nos importamos pela conveniência de concluir

00:09:22o trabalho. Precisamos repensar. Precisamos proteger nossas máquinas, garantir que

00:09:31desenvolvemos em ambientes seguros, como máquinas virtuais e dev containers, sem

00:09:37credenciais expostas. E se usamos agentes de IA, o que provavelmente todos fazemos,

00:09:44temos que ter cuidado, pois há duas formas de perigo. Vamos ver

00:09:53por que os agentes de IA são problemáticos. Um problema é o que mencionei: quando usamos

00:10:00agentes de IA, especialmente para coisas não relacionadas diretamente à escrita de código,

00:10:08ou mesmo quando os usamos para ajudar em um programa, não vemos necessariamente

00:10:17tudo o que estão fazendo. Se você usa o Claude Code ou algo parecido — e não tenho nada contra

00:10:23essas ferramentas, aliás, tenho cursos sobre Claude Code, Cursor e outros, porque

00:10:30são muito úteis — mas se você os usa e simplesmente os deixa agir, pedindo

00:10:35uma funcionalidade sem se preocupar muito, você pode nem perceber o que eles

00:10:41estão instalando. Novamente: pacotes sendo instalados, você pode ser comprometido e afetado. Uma

00:10:49defesa contra isso é limitar a quantidade de pacotes usados, mas,

00:10:54com um agente de IA, você pode perder o controle. Ele pode instalar pacotes que você

00:11:00jamais instalaria. Esse é um perigo óbvio. Aqui está um menos óbvio: os

00:11:07agentes de IA são alvos de ataque super atraentes. O que quero dizer com isso? Bem, esses ataques

00:11:15que mencionei se espalham como vermes e afetam todo tipo de pacotes.

00:11:23Agora, seria muito interessante para um invasor infectar o Claude Code ou o Cursor, ou o

00:11:32agente Pycode, o Opencode ou qualquer outro agente de IA. Por quê? Bem, se você tivesse um código malicioso

00:11:42otimizado para afetar e infiltrar exclusivamente pacotes, repositórios e bases de código de agentes de IA,

00:11:52então esse código poderia conter injeções de prompt. Ele poderia, por exemplo,

00:12:00atingir esses agentes para mudar seu código de forma que o objetivo principal não fosse

00:12:08exfiltrar dados diretamente — o código malicioso injetado no pacote não

00:12:15seria para isso — mas para ajustar o código do agente de IA para que ele tenha

00:12:22instruções especiais que o façam realizar ações indesejadas na máquina onde é usado. Na sua

00:12:28máquina, por exemplo. Imagine o Claude Code com um prompt de sistema secreto,

00:12:34que normalmente seria definido pela Anthropic, mas que agora é definido por aquele código

00:12:39malicioso que o instrui a ignorar o que você pede e apenas fingir que está fazendo,

00:12:46ou que deve fazer o que você pede, mas que, além disso, deve escanear

00:12:52o sistema em busca de segredos e talvez escrever um pequeno programa que faça esse escaneamento

00:13:00e envie os dados para um servidor remoto. O céu é o

00:13:06limite aqui, porque de repente você tem um cavalo de Troia no seu sistema. De repente, um agente

00:13:12de IA fica fora de controle na sua máquina. E não porque a IA enlouqueceu ou o modelo é

00:13:20ruim, mas porque o código do próprio agente e seu prompt de sistema foram comprometidos.

00:13:28Esse não é um cenário irrealista e garanto que acontecerá em algum

00:13:34momento. Agentes de IA são alvos obviamente interessantes. Isso vai

00:13:41acontecer. Veremos um novo nível desses ataques à cadeia de suprimentos, pois eles não apenas

00:13:49afetarão pacotes e colherão credenciais — o que já é horrível e está aumentando —

00:13:54mas também veremos agentes de IA agindo de forma maliciosa devido a códigos comprometidos.

00:14:01É apenas questão de tempo. Há muitas camadas aqui, como podem ver. Esta é a

00:14:08nova realidade em que vivemos. Acho que é um pouco como os primórdios da internet: é

00:14:14complicado enquanto ainda estamos descobrindo como as coisas funcionam e como reforçar a segurança.

00:14:21Um passo óbvio, válido para desenvolvimento e para execução de agentes de IA, é

00:14:26que você não quer fazer isso em um ambiente onde as coisas possam dar errado. Você não

00:14:32quer rodá-los em um ambiente onde armazena credenciais, segredos ou qualquer dado

00:14:37importante. Não faça isso na sua máquina principal. Você deve rodar agentes e

00:14:42desenvolver software em máquinas virtuais isoladas, remotas ou algo assim, onde o raio

00:14:49de destruição seja limitado. Pois, repito, é só questão de tempo até que algo dê errado. Temos

00:14:56que aceitar que este é o primeiro passo importante. As coisas mudam rápido e a segurança é um

00:15:03enorme problema. Continuará sendo, e se tornará ainda maior conforme a IA acelera e os

00:15:11modelos ficam mais espertos, especialmente integrados às ferramentas em que rodam. Isso

00:15:17traz novas capacidades, mas também muita conveniência. E a conveniência

00:15:23é perigosa porque te faz ficar desleixado e negligenciar detalhes. Pois bem,

00:15:30a IA está em todo lugar. Muitas pessoas que não sabem nada sobre cibersegurança a usam, e mesmo

00:15:34quem entende do assunto corre grande perigo. Estamos prestes a enfrentar

00:15:40tempos difíceis, eu acho. Temos que repensar e ser super cuidadosos sobre onde e como rodamos agentes

00:15:49e trabalhamos em nosso código.

Key Takeaway

A integração de agentes de IA no desenvolvimento exige a execução em máquinas virtuais isoladas e o uso de serviços de criptografia como Infisical para evitar que injeções de prompt e pacotes comprometidos exfiltrem credenciais do sistema principal.

Highlights

Ataques à cadeia de suprimentos utilizam vermes que se propagam de um pacote para outro para exfiltrar credenciais de arquivos .env e chaves da AWS.
O envenenamento de cache no GitHub Actions permite que invasores movam código malicioso de ambientes não confiáveis para fluxos de publicação seguros.
A instalação de pacotes com menos de três dias de existência aumenta significativamente o risco de exposição a versões comprometidas ainda não detectadas.
A IA acelera a frequência de ataques ao analisar em massa scripts de CI/CD em busca de vulnerabilidades lógicas em repositórios de código aberto.
Agentes de IA como Claude Code e Cursor são alvos críticos para injeções de prompt que podem transformar ferramentas de produtividade em cavalos de Troia no sistema local.
O armazenamento de segredos em texto simples no disco rígido facilita a coleta automatizada de dados por malwares inseridos em dependências NPM e Python.

Timeline

Mecânica dos Ataques à Cadeia de Suprimentos

O comprometimento de uma única dependência de software serve como porta de entrada para infectar todo o ecossistema de um desenvolvedor.
Scripts maliciosos automatizam a varredura de discos rígidos em busca de tokens de acesso e segredos de nuvem.
Invasores priorizam máquinas de mantenedores de pacotes para facilitar a propagação viral do código malicioso para milhares de usuários finais.

Ataques recentes em ecossistemas NPM e Python demonstram como códigos bem elaborados se espalham rapidamente antes da detecção. O objetivo central desses ataques é a coleta de credenciais de infraestrutura, como AWS, para expandir o alcance da infiltração. Pacotes populares como os da Tanstack exemplificam como ferramentas confiáveis podem ser usadas como vetores de distribuição de malware.

Protocolos de Proteção e Armazenamento de Segredos

O isolamento do ambiente de desenvolvimento em Dev Containers ou máquinas virtuais limita o raio de destruição de um ataque.
A substituição de arquivos .env por serviços de gerenciamento como Infisical ou Doppler impede a leitura de segredos em texto simples.
A verificação da idade da versão de um pacote atua como um filtro de segurança básico contra lançamentos maliciosos recentes.

Manter credenciais expostas no sistema de arquivos é um risco crítico diante do aumento da frequência de varreduras automatizadas. Recomenda-se aguardar pelo menos três dias antes de atualizar para novas versões de pacotes para permitir que a comunidade identifique anomalias. O uso de ambientes virtualizados garante que, caso um pacote seja comprometido, o invasor não tenha acesso direto aos dados confidenciais da máquina principal.

O Papel da IA na Facilitação de Ataques

Modelos de linguagem simplificam a análise de fluxos de trabalho complexos no GitHub Actions para encontrar falhas de segurança.
A IA reduz a barreira técnica para a criação de códigos maliciosos funcionais que priorizam a eficácia sobre a estética ou boas práticas.
Invasores possuem uma vantagem assimétrica ao usar IA para testar múltiplos vetores enquanto mantenedores precisam proteger todas as frentes simultaneamente.

A inteligência artificial permite a análise em massa de repositórios em busca de gatilhos de eventos mal configurados. No caso da Tanstack, o envenenamento de cache foi a técnica utilizada para infiltrar código no processo de publicação. Embora a IA ajude na produtividade, ela também gera um volume sem precedentes de ferramentas de ataque que podem ser operadas com esforço mínimo.

Riesgos de Automação e Agentes de IA

A tendência de 'wipe coding' leva usuários a executar códigos gerados por IA sem revisar as dependências instaladas silenciosamente.
Agentes de IA comprometidos podem receber instruções ocultas via injeção de prompt para realizar ações maliciosas sem o conhecimento do usuário.
O aumento do volume de código enviado ao GitHub gera problemas de confiabilidade e amplia a superfície de ataque disponível.

Muitas tarefas automatizadas por agentes, como a manipulação de arquivos PDF, envolvem a instalação de bibliotecas externas que o usuário nunca verifica. Existe o risco real de um agente ter seu prompt de sistema alterado por código injetado, passando a agir como um espião interno. Essa nova classe de ataque transforma o assistente de IA em uma ferramenta de exfiltração de dados que finge executar as tarefas solicitadas.

Conclusão e Mentalidade de Segurança

A conveniência das ferramentas de IA gera uma negligência perigosa em relação aos detalhes técnicos de segurança.
Ambientes de execução isolados são indispensáveis para rodar agentes de IA que possuem permissões de escrita ou execução de código.
A fase atual da tecnologia de IA assemelha-se aos primórdios da internet, onde a segurança ainda não está totalmente integrada ao uso cotidiano.

A evolução rápida dos modelos de IA exige uma reavaliação completa de como o software é desenvolvido e executado. É necessário assumir que, em algum momento, as ferramentas de automação serão comprometidas. A proteção eficaz depende da redução da confiança implícita em agentes e da manutenção de barreiras físicas e digitais entre o ambiente de teste e os dados pessoais.

Community Posts

Write about this video