O software que uma empresa instala, atualiza ou incorpora às suas aplicações pode carregar uma ameaça sem apresentar a aparência tradicional de um ataque. Pacotes open source, pipelines de CI/CD, imagens de contêiner e até modelos de Inteligência Artificial transformaram relações de confiança da cadeia de suprimentos em uma superfície capaz de levar código malicioso para dentro dos ambientes corporativos.
Durante muito tempo, a representação mais intuitiva de um ataque cibernético colocou o criminoso do lado de fora da organização. Firewalls, sistemas de detecção, proteção de endpoints e controles de acesso foram desenvolvidos, em grande medida, para identificar alguém tentando atravessar essa fronteira.
A cadeia moderna de desenvolvimento tornou essa separação muito menos evidente. Aplicações corporativas dependem de bibliotecas open source, pacotes, imagens de contêiner, ferramentas de build, serviços de Continuous Integration/Continuous Delivery (CI/CD), Software Development Kits (SDKs), APIs e, cada vez mais, modelos e componentes de Inteligência Artificial.
O problema começa quando um desses elementos confiáveis deixa de ser confiável. Nesse cenário, o atacante não precisa necessariamente invadir diretamente a empresa que pretende atingir. Pode comprometer algo que a própria organização está programada para buscar, instalar, executar ou atualizar.
Em vez de atravessar a porta, o ataque pode chegar dentro de uma entrega autorizada.
A confiança tornou-se parte da superfície de ataque
Ataques à cadeia de suprimentos de software não são novos. O que mudou foi a quantidade de dependências, a velocidade da automação e a capacidade de um único comprometimento alcançar simultaneamente grande número de organizações.
O caso do XZ Utils ajudou a tornar esse risco particularmente visível em 2024. Código malicioso foi introduzido nas versões 5.6.0 e 5.6.1, demonstrando como um projeto amplamente utilizado poderia tornar-se um vetor de comprometimento.
Em 2026, o GitHub descreveu ataques explorando repositórios de pacotes e sistemas de CI/CD para disseminar malware por projetos open source. Um dos padrões observados envolve roubar credenciais, utilizá-las para comprometer outros projetos e continuar propagando o ataque. A cadeia deixa de funcionar apenas como vetor de entrada e pode tornar-se mecanismo de propagação.
Quando a infraestrutura considera o ataque legítimo
Um ataque pode começar longe da empresa que terminará comprometida. A conta de um mantenedor pode ser tomada por phishing. Um token utilizado pelo pipeline pode ser roubado. Um workflow vulnerável pode executar código não confiável. Uma credencial de publicação pode ser extraída de um ambiente de CI/CD.
O atacante passa então a controlar um componente que já possui reputação e consumidores. Uma nova versão aparentemente legítima é publicada, sistemas automatizados detectam a atualização, pipelines executam o download, dependências são atualizadas, imagens são construídas e aplicações chegam à produção.
O código malicioso atravessa diferentes camadas, mas parte da infraestrutura pode não interpretar o evento como invasão porque a comunicação ocorreu com repositórios permitidos e por processos autorizados. O adversário procura herdar a confiança concedida ao fornecedor, pacote, pipeline ou artefato comprometido.
CI/CD tornou-se infraestrutura crítica de segurança
Ambientes de CI/CD frequentemente possuem acesso ao código-fonte, registries, ambientes de cloud, segredos, tokens, certificados, chaves de assinatura e mecanismos capazes de implantar software diretamente em produção. Comprometer o pipeline pode, portanto, ser mais valioso do que comprometer uma estação de trabalho.
O GitHub descreveu em 2026 campanhas nas quais atacantes procuram comprometer projetos ou workflows do GitHub Actions, obter credenciais e utilizá-las posteriormente para distribuir malware. A resposta incluiu novos controles para workflows, proteção de caches, revogação de credenciais e incentivo ao trusted publishing, reduzindo a dependência de tokens persistentes armazenados nos pipelines.
Mecanismos baseados em OpenID Connect (OIDC) permitem autorizar workloads sem manter determinados segredos de longa duração. Uma credencial que não precisa permanecer armazenada oferece ao atacante menos oportunidades de exfiltração.
O risco vai além do npm
JavaScript e npm ganharam visibilidade com campanhas recentes, mas o problema atravessa diferentes ecossistemas. Em agosto de 2026, o GitHub anunciou a expansão de alertas de malware baseados em informações da Open Source Security Foundation (OpenSSF), cobrindo npm, PyPI, Maven, RubyGems, NuGet, Go, crates.io e PHP Composer.
Não basta perguntar se há vulnerabilidades conhecidas em uma biblioteca. Também é necessário perguntar: quem pode alterar o componente que a organização está prestes a executar? Essa segunda pergunta leva a segurança para identidade, proveniência, processo de publicação e governança da cadeia.
Containers também carregam relações de confiança
Containers acrescentam outra camada ao problema. Uma organização pode revisar cuidadosamente seu código e ainda construir aplicações sobre imagens-base produzidas por terceiros.
Em abril de 2026, a Docker relatou comprometimentos envolvendo imagens relacionadas ao Trivy e ao Checkmarx KICS. Segundo a empresa, credenciais legítimas de publicação foram utilizadas para enviar imagens maliciosas pelos fluxos normais do Docker Hub. Para quem consumia a imagem, o objeto continuava vindo do repositório esperado.
Esse detalhe evidencia uma distinção fundamental: autenticidade da origem e integridade do conteúdo são problemas relacionados, mas não idênticos. Fixação de versões e digests, assinatura de artefatos, verificação de proveniência, políticas de admissão e análise das imagens antes da implantação precisam fazer parte da segurança de containers.
SBOM é importante, mas não suficiente
A Software Bill of Materials (SBOM) permite conhecer os componentes utilizados por uma aplicação e identificar rapidamente onde determinada biblioteca vulnerável está presente. Mas um ataque à cadeia apresenta outra dificuldade: o componente pode não possuir uma vulnerabilidade conhecida. Ele pode ter sido deliberadamente alterado.
SBOM deve fazer parte de um conjunto maior de controles envolvendo proveniência, assinatura, verificação de integridade, gestão de dependências e monitoramento de fornecedores. O National Institute of Standards and Technology (NIST) incorpora essas preocupações ao Cybersecurity Supply Chain Risk Management (C-SCRM).
Em 2026, o NIST também publicou orientações de due diligence para cadeias de suprimentos de Tecnologia da Informação e Comunicação, reforçando aspectos como proveniência, resiliência e práticas de segurança. Risco de fornecedor não termina no fornecedor contratado diretamente.
A cadeia de suprimentos agora inclui Inteligência Artificial
A adoção de Inteligência Artificial acrescentou uma nova dimensão. Aplicações de IA podem incorporar frameworks de Machine Learning, datasets, modelos pré-treinados, adaptadores Low-Rank Adaptation (LoRA), arquivos de pesos e componentes provenientes de plataformas externas.
A OWASP inclui Supply Chain entre os riscos relevantes para aplicações baseadas em Large Language Models (LLMs), considerando não apenas bibliotecas tradicionais, mas também modelos, dados, adaptadores e plataformas.
Há ainda um problema técnico importante: alguns formatos empregados em Machine Learning podem executar código durante a desserialização. A Hugging Face alerta que arquivos baseados em Python Pickle podem permitir execução arbitrária de código quando carregados e recomenda avaliar origem, assinatura e formatos utilizados.
Se uma empresa controla quais softwares podem ser instalados, ela também controla quais modelos de IA podem ser carregados em sua infraestrutura?
Do SBOM ao inventário da IA
Essa expansão da cadeia já impulsiona discussões sobre AI Bill of Materials (AIBOM), estendendo o princípio de inventário para elementos que um SBOM tradicional pode não representar adequadamente. Modelos, datasets, adaptadores, frameworks e outros artefatos de Machine Learning passam a exigir informações sobre origem e proveniência.
A tendência aponta para uma nova necessidade de governança: empresas precisarão saber não apenas qual software utilizam, mas também quais modelos utilizam, de onde vieram e quais componentes participaram de sua construção.
Assinatura não encerra a cadeia de confiança
Assinaturas criptográficas são fundamentais para integridade e autenticidade, mas precisam fazer parte de um processo maior. Se um atacante comprometer credenciais ou uma etapa autorizada de publicação, a proteção precisa alcançar também as identidades e os processos capazes de produzir, assinar e distribuir os artefatos.
A confiança precisa ser verificável ao longo do caminho: código → build → artefato → assinatura → registry → implantação → runtime.
Como reduzir a exposição
Não existe um único produto capaz de eliminar esse risco. O Secure Software Development Framework (SSDF), definido pelo NIST SP 800-218, reforça a incorporação de práticas de desenvolvimento seguro ao ciclo de vida do software.
Na prática, organizações precisam combinar inventário de dependências, redução de credenciais persistentes nos pipelines, princípio do menor privilégio para identidades de CI/CD, proteção dos processos de publicação, verificação de assinaturas e proveniência e monitoramento de alterações inesperadas.
Registries internos podem criar uma camada adicional entre a Internet e produção. Dependências externas podem ser analisadas e promovidas internamente antes de chegarem aos workloads corporativos. Em containers, imagens devem ser verificadas antes da implantação e identificadas de maneira imutável sempre que possível.
No ecossistema de IA, modelos externos precisam receber tratamento semelhante ao código executável: origem, formato, integridade, permissões e comportamento precisam ser avaliados. A monitoração também deve continuar após a implantação, pois um componente considerado legítimo hoje pode tornar-se objeto de investigação amanhã.
Supply chain também é governança
Compras seleciona fornecedores. Desenvolvimento escolhe bibliotecas. DevOps controla pipelines. Cloud administra infraestrutura. Segurança estabelece controles. Jurídico define cláusulas. Gestão de riscos avalia criticidade. Auditoria procura evidências. Quando cada área observa apenas seu próprio fragmento, ninguém necessariamente enxerga a cadeia completa.
O problema torna-se ainda maior porque fornecedores também possuem fornecedores e dependências. Uma organização pode avaliar rigorosamente seu prestador direto e desconhecer bibliotecas, plataformas de CI/CD, serviços SaaS, imagens ou modelos utilizados por ele.
O risco também é transitivo: a organização herda parte do risco das dependências de quem fornece tecnologia para ela.
Conclusão
A transformação digital criou uma economia baseada em dependências. Essa especialização tornou possível desenvolver e entregar software em enorme velocidade, mas também criou uma superfície de ataque profundamente conectada.
Um criminoso que compromete uma dependência popular pode alcançar organizações que nunca atacou diretamente. Ao controlar uma credencial de publicação, pipeline, imagem, pacote ou modelo de IA, mecanismos legítimos de distribuição podem ser transformados em infraestrutura de ataque.
Por isso, segurança da cadeia de suprimentos não pode ser reduzida a uma lista de fornecedores aprovados ou a uma ferramenta de análise de vulnerabilidades. Ela exige inventário, proveniência, identidade, integridade, observabilidade e governança sobre o caminho percorrido pelo software e, cada vez mais, pelos modelos de Inteligência Artificial.
A pergunta deixou de ser apenas se determinado fornecedor é confiável. A questão mais importante é como verificar continuamente se aquilo que a organização recebeu continua sendo exatamente aquilo em que decidiu confiar.
No cenário atual, o componente mais perigoso pode não ser aquele que a empresa bloqueou. Pode ser justamente aquele em que ela já confia.
Referências
- GitHub — Disrupting supply chain attacks on npm and GitHub Actions
- GitHub — How we took malware advisories beyond npm
- Docker Security — Trivy, KICS, and the shape of supply chain attacks so far in 2026
- NIST — SP 800-218 Secure Software Development Framework
- OWASP — LLM03:2025 Supply Chain
Imagem editorial: Julio Lopez / Unsplash.
Be the first to comment