Ataque à cadeia de abastecimento: o que dizer aos clientes

Envie uma primeira declaração em poucas horas, uma resposta confirmada assim que a puder provar e um acompanhamento sempre que algo mudar. Diga o que sabe, o que ainda está a verificar e quando vai dar uma atualização. Baseie cada «não afetado» no que os seus builds realmente instalaram durante a janela do ataque, e não no lockfile de hoje.

Este artigo trata do que dizer, quando e com que fundamento. Para a investigação em si, ou seja, como descobrir se um componente vulnerável está nos seus produtos e desde quando, consulte estamos afetados por um CVE?.

Porque é que os clientes lhe perguntam a si, e não ao registo de pacotes

Na semana a seguir a um ataque muito noticiado, contou-nos um pequeno fornecedor de software, os clientes enviavam-lhe mensagens: as vossas coisas estão seguras? As minhas coisas estão seguras? Os clientes dele tratam dados sensíveis, a equipa dele não tem nenhum especialista em segurança, e a pergunta precisava de resposta nesse mesmo dia.

Os clientes não estão a perguntar se um pacote foi comprometido. O registo e os investigadores já o disseram. Estão a perguntar se o que lhes entregou o contém, porque o seu produto é a exposição deles. Eles próprios têm clientes, auditores ou reguladores a fazer-lhes a mesma pergunta. Em cadeias de abastecimento reguladas, como semicondutores, equipamento industrial e saúde, a pergunta é contratual, não mera curiosidade.

Também voltarão a perguntar se a sua resposta não puder ser verificada. «Não estamos afetados» sem nada por trás é uma promessa; «verificámos todos os builds de lançamento de 24 a 31 de março e nenhum instalou as versões afetadas» é uma afirmação em que podem confiar.

Quatro ataques recentes e a pergunta que cada um levantou

A resposta certa depende de como o ataque funcionou, pelo que um modelo por si só não chega. Em cada um destes casos, há um facto que decide o que «afetado» significa para um fornecedor.

Backdoor no xz Utils (CVE-2024-3094), divulgado a 29 de março de 2024. Andres Freund descobriu um backdoor nas versões 5.6.0 e 5.6.1 do xz. Os tarballs de lançamento continham código que não estava no repositório Git, e esse código injetava o backdoor durante o build. A NVD e a Red Hat atribuem-lhe ambas 10.0 em CVSS 3.1. Chegou sobretudo a distribuições rolling e de teste: Debian testing, unstable e experimental, Fedora Rawhide e 41, openSUSE Tumbleweed e Kali, enquanto as versões estáveis não foram afetadas. A pergunta que levantou: alguma imagem ou dispositivo que distribuímos inclui o xz 5.6.0 ou 5.6.1, e que imagem base usou cada build?

Worm npm Shai-Hulud, em vagas desde setembro de 2025. Os pacotes infetados executam um script durante a instalação que rouba credenciais do npm, do GitHub e da cloud e as usa para publicar versões infetadas de mais pacotes. A pergunta que levantou: algum job de CI instalou uma versão infetada, e os nossos tokens de publicação ficaram expostos, o que faria de nós um propagador? A nossa entrada sobre o Shai-Hulud lista todas as vagas e explica como verificar.

LiteLLM no PyPI, 24 de março de 2026. As versões 1.82.7 e 1.82.8 foram carregadas diretamente no PyPI com código de roubo de credenciais que nunca esteve no repositório GitHub do projeto. Na 1.82.8, um ficheiro .pth executava o payload sempre que qualquer interpretador Python arrancava, e não apenas quando o LiteLLM era importado; recolhia variáveis de ambiente, chaves SSH, credenciais de cloud e secrets do Kubernetes. A HiddenLayer associa o ataque ao TeamPCP, que também atingiu ferramentas do Trivy e da Checkmarx nesse mês. O próprio aviso de segurança do LiteLLM dá duas explicações para o acesso inicial: atribui o comprometimento à dependência do Trivy no seu workflow de análise de segurança em CI e diz que a conta PyPI de um maintainer pode ter sido comprometida. Até a janela de exposição difere dentro desse mesmo aviso: cerca de 40 minutos num ponto e das 10:39 às 16:00 UTC noutro. A pergunta que levantou: algum build ou contentor distribuído incluiu essas versões, e que secrets estavam presentes nesse ambiente?

axios no npm, 31 de março de 2026. Um atacante assumiu o controlo da conta npm de um maintainer e publicou o axios 1.14.1 e 0.30.4, que acrescentavam uma dependência, [email protected], cujo script de instalação instalava um trojan de acesso remoto para macOS, Windows e Linux. A Datadog situa a janela entre as 00:21 e as 03:25 UTC; segundo a Snyk, as versões foram removidas às 03:29 UTC. A pergunta que levantou: algum build resolveu essas versões nessa janela? Um lockfile commitado antes da janela responde «não» para os builds que o usaram, e nada diz sobre os builds que executaram npm install sem ele.

Ataque	Ecossistema	Versões afetadas	Janela	O que «afetado» significa para um fornecedor
xz Utils	Distribuições Linux	5.6.0, 5.6.1	Semanas, até à divulgação a 29 de março de 2024	Distribuiu-o, numa imagem ou dispositivo construído sobre uma distribuição afetada
Shai-Hulud	npm	Centenas de pacotes, por vaga	Horas a dias por vaga	Compilou com ele, e os seus tokens podem tê-lo propagado; também pode tê-lo distribuído
LiteLLM	PyPI	1.82.7, 1.82.8	24 de março de 2026, a partir das 10:39 UTC (as fontes divergem quanto ao fim)	Compilou com ele ou distribuiu-o, e os secrets nesse ambiente podem ter sido roubados
axios	npm	1.14.1, 0.30.4	31 de março de 2026, aproximadamente das 00:21 às 03:25 UTC	Compilou com ele durante a janela; o trojan foi executado na máquina de build

As mesmas perguntas surgem perante uma vulnerabilidade crítica que não é um ataque à cadeia de abastecimento. Quando o PHP2Shell foi explorado em outubro de 2026, os clientes de todos os produtos que incluem PHP perguntaram que versões suas continham um PHP afetado. Os passos abaixo aplicam-se sem alterações.

A resposta tem três fases

Fase	Quando	O que envia
Primeira declaração	Poucas horas após a notícia	O que sabe, o que está a verificar, quando vai dar uma atualização
Resposta confirmada	Assim que o puder provar, normalmente no primeiro dia	«Não afetado» para versões identificadas, ou «afetado» com o que fazer
Acompanhamento	Quando a correção sair, quando souber algo novo, quando encerrar o caso	O mesmo aviso, revisto

A primeira hora: a primeira declaração

A primeira declaração (holding statement) é a comunicação pública que faz antes de os factos serem conhecidos. Diga algo verdadeiro, depressa. O silêncio é preenchido com suposições, e um cliente que não recebe notícias suas assume que não deu pelo problema.

Quem e onde. Um remetente identificado pelo nome, no canal que o cliente usou, e também a sua página de segurança. Um texto comum é melhor do que respostas improvisadas: mantém-se coerente e o departamento jurídico revê-o uma só vez.
O que contém. Que tem conhecimento do ataque, que está a verificar os seus produtos e sistemas de build, o que sabe até ao momento, quando chega a próxima atualização e quem contactar.
O que não pode conter. «Não estamos afetados» antes de ter verificado, especulação sobre o atacante, ou atribuição de culpas.

Modelo 1: primeira declaração

Assunto: [Nome do ataque]: a nossa primeira declaração

Temos conhecimento do comprometimento reportado de [pacote ou projeto] ([versões afetadas], publicadas em [data]). A nossa equipa de segurança está a verificar todas as versões de [produto] e os nossos sistemas de build à procura das versões afetadas. Até ao momento, [não encontrámos versões afetadas nos produtos verificados / ainda não concluímos a verificação]. Enviaremos uma atualização até [data e hora, fuso horário]. Se entretanto tiver alguma questão, contacte [nome, endereço de contacto de segurança]. Não faremos especulações sobre o impacto antes de concluída a verificação.

Para uma mensagem de texto ou chat, bastam duas frases:

Temos conhecimento do comprometimento [nome do ataque] e estamos neste momento a verificar todas as versões de [produto] e os nossos builds. Receberá de nós uma resposta confirmada até [hora].

Obtenha a aprovação jurídica dos três modelos antes de precisar deles.

Primeiro dia: confirmar, com evidências

Há dois resultados possíveis, e cada um precisa das suas próprias evidências. Para uma resposta «não afetado», reúna:

o pacote e as versões afetadas, a partir do aviso de segurança ou da análise dos investigadores
os seus produtos e as versões que os clientes realmente executam
para cada uma dessas versões, o build que a produziu e o registo do que esse build instalou, não o lockfile atual
todos os builds executados durante a janela do ataque, incluindo jobs de CI que nunca produziram uma versão
no caso de worms que roubam tokens, se havia secrets de CI presentes em jobs que possam ter executado o código malicioso

Estamos afetados por um CVE? explica como apurar cada um destes pontos.

Cada afirmação que faz tem de estar apoiada em algo que possa mostrar:

Afirmação	O que tem de conseguir mostrar	O que não chega
«O produto X versão Y não contém o pacote Z»	A SBOM registada a partir do build de lançamento da versão Y	Uma análise do repositório atual
«Nenhum dos nossos builds instalou as versões comprometidas»	Registos de instalação de todos os builds na janela	Um lockfile que alguns jobs contornam
«O nosso pipeline de lançamento não foi comprometido»	Registos de rede e de utilização de secrets na janela	A ausência de alertas
«Os clientes com a versão Y estão seguros após a atualização»	O registo do build corrigido e as credenciais que rodou	Uma entrada no changelog

Modelo 2: não afetado

Assunto: [Nome do ataque]: [produto] não está afetado

Concluímos a nossa verificação relativa ao comprometimento de [pacote] ([versões afetadas]). As seguintes versões de [produto] não estão afetadas: [lista de produtos e versões verificados]. Verificámos todos os builds de lançamento e de CI executados entre [data de início] e [data de fim]. Esta declaração baseia-se no registo dos componentes instalados por cada build de lançamento, e não numa análise do nosso código-fonte atual. Nenhum destes builds instalou as versões afetadas. Se precisar das evidências, podemos enviar-lhe a SBOM das versões que utiliza, ou uma declaração VEX. Se tivermos conhecimento de algo que altere esta avaliação, informá-lo-emos. Contacto: [nome, endereço de contacto de segurança].

Diga «não afetado» para versões identificadas. Nunca escreva «100% seguro». Se o cliente pedir depois a SBOM completa, consulte responder a pedidos de SBOM de clientes.

Modelo 3: afetado, com mitigação

Assunto: [Nome do ataque]: ação necessária para as versões [x a y] de [produto]

A nossa verificação relativa ao comprometimento de [pacote] concluiu que as versões [x a y] de [produto] estão afetadas. O primeiro build afetado foi produzido em [data]; a versão [z], lançada em [data], já não contém [versão do pacote].

O que isto significa: [risco em linguagem simples, por exemplo «um componente instalado nestas versões pode enviar credenciais do sistema onde é executado para um servidor externo»].

O que fazer agora: atualize para [produto] [z]. Se não puder atualizar de imediato, [mitigação, por exemplo bloquear as ligações de saída para os hosts indicados]. Se utilizou as versões [x a y] de [produto] em [ambiente], faça a rotação das [credenciais ou chaves] que lhe estavam acessíveis.

O que já fizemos: removemos as versões afetadas dos nossos builds, recompilámos [produto] a partir de dependências limpas, fizemos a rotação das credenciais usadas pelos nossos sistemas de build e [outras ações]. [Notificámos as autoridades competentes sempre que exigido.]

Enviaremos a próxima atualização até [data], ou antes se algo mudar. Contacto: [nome, endereço de contacto de segurança].

Um aviso «afetado» também pode ser uma obrigação legal; consulte a secção sobre notificação abaixo.

Onde entram o VEX e o CSAF. Uma declaração «não afetado» ou «corrigido» pode ser publicada como VEX, para que os scanners dos clientes deixem de assinalar o pacote. Os clientes maiores podem também esperar um aviso de segurança legível por máquina; o CSAF é o formato que a maioria deles pede.

Acompanhamento: encerrar devidamente

Envie um acompanhamento quando a correção sair e quando a investigação descobrir algo novo, e uma nota final quando o caso for encerrado. Mantenha um único aviso de segurança por incidente e reveja-o em vez de enviar um novo de cada vez (atualizar, não substituir). Registe o que disse a quem e quando: a próxima auditoria ou o próximo questionário de segurança de um cliente vai perguntar.

O que dizer quando ainda não sabe

«Ainda não sabemos» gera mais confiança do que um «não afetado» que tenha de retirar. Frases honestas que não alarmam ninguém:

«Não encontrámos [pacote] em [produtos verificados até agora]. Continuamos a verificar [produtos ou sistemas de build restantes] e daremos uma atualização até [hora].»
«As versões que utiliza foram compiladas antes da janela do ataque. Estamos a confirmar que nenhum build posterior as substituiu.»
«Estamos a verificar se algum dos nossos sistemas de build executou as versões afetadas. O produto que tem instalado é uma questão à parte, e responderemos a ambas.»

Frases a evitar:

«Sem qualquer impacto»
«Totalmente seguro»
«Não afetado por nenhum ataque à cadeia de abastecimento»
«O nosso scanner não encontrou nada»

Quando o ataque se torna uma obrigação de notificação

Se vende produtos com elementos digitais na UE, as obrigações de notificação do Cyber Resilience Act aplicam-se desde 11 de setembro de 2026, o dia em que a ENISA lançou a Single Reporting Platform. Uma vulnerabilidade ativamente explorada no seu produto, ou um incidente grave com impacto na sua segurança, desencadeia um alerta precoce no prazo de 24 horas após tomar conhecimento dele, uma notificação no prazo de 72 horas e um relatório final, apresentados através da plataforma ao seu CSIRT coordenador e à ENISA. O guia do CRA percorre os passos.

Saber se uma dependência comprometida que distribuiu, ou um comprometimento do seu próprio pipeline de build, se enquadra nessas definições é uma avaliação que cabe a si e ao seu advogado, não a este artigo. O regulamento define os termos:

Uma «vulnerabilidade ativamente explorada» é «uma vulnerabilidade relativamente à qual existem provas fiáveis de que um agente malicioso a explorou num sistema sem autorização do proprietário do sistema» (artigo 3, ponto 42).
Um incidente é grave quando «afeta negativamente ou é suscetível de afetar negativamente a capacidade de um produto com elementos digitais de proteger a disponibilidade, a autenticidade, a integridade ou a confidencialidade de dados ou funções sensíveis ou importantes», ou quando «conduziu ou é suscetível de conduzir à introdução ou execução de código malicioso» no produto ou nos sistemas de um utilizador (artigo 14(5)).

O artigo 14(8) acrescenta um dever para com os utilizadores: informar os utilizadores afetados e, se for caso disso, todos os utilizadores, da vulnerabilidade ou do incidente e de quaisquer medidas de mitigação que possam aplicar, «se for caso disso, num formato estruturado, legível por máquina e facilmente processável de forma automática». O modelo 3 pode fazer parte do cumprimento desse dever.

Aplicam-se também outros regimes. Ao abrigo da NIS2, as entidades essenciais e importantes notificam incidentes significativos ao seu CSIRT ou à autoridade competente, e muitos contratos com clientes têm as suas próprias cláusulas de notificação, com os seus próprios prazos.

Esteja preparado antes do próximo

Um registo do que cada build de lançamento instalou, conservado durante o período de suporte do produto (SBOM no momento do build).
Uma lista de que clientes executam que versões.
Os três modelos acima, aprovados pelo departamento jurídico.
Um remetente identificado e um canal para cada tipo de cliente.
Uma página de segurança e um ficheiro security.txt onde são publicadas as atualizações (divulgação coordenada de vulnerabilidades).
Controlo de egress no CI, para que um pacote comprometido não possa enviar secrets para um host de que o build não precisa (política de egress do GitHub Actions).

Para incidentes que chegam às centenas e não um de cada vez, consulte como escalar uma PSIRT.

Onde entra o CRACI

A tabela de evidências acima pede sempre a mesma coisa: um registo do que cada build de lançamento instalou. É isso que o CRACI guarda. O CRACI executa os seus builds de GitHub Actions nos seus próprios runners e regista todos os pacotes que cada job efetivamente obteve, incluindo pacotes descarregados por scripts de instalação e pacotes restaurados de caches. A SBOM de cada build anterior é conservada, pelo que «algum build instalou o axios 1.14.1 durante a janela?» tem resposta a partir do histórico de builds, com o período em que esteve afetado, até onde chegar o seu período de retenção.

As versões maliciosas conhecidas que têm um CVE publicado, como o backdoor do xz, são assinaladas como qualquer outra vulnerabilidade, e uma policy gate pode bloquear os builds que as contenham. O CRACI não deteta um novo pacote malicioso pelo seu comportamento ou reputação.

A política de egress do CRACI bloqueia ligações a hosts de que um build não precisa, o que limita o que um script de instalação malicioso consegue enviar para fora, mesmo num ataque que ninguém viu antes. Quando um cliente pede as evidências, pode exportar a SBOM das versões que ele utiliza em CycloneDX ou SPDX e enviá-la. O CRACI suporta VEX.

Responda a «fomos afetados?» a partir do histórico de builds, ou saiba mais sobre como funcionam os ataques à cadeia de abastecimento.

Quando o CRACI não é a resposta

Precisa de ajuda com a comunicação em si. O aconselhamento de relações públicas e jurídico é outro trabalho.
O software afetado não foi compilado no CRACI. O CRACI regista builds de GitHub Actions executados nos seus runners; outros sistemas de CI estão no roadmap.
A pergunta é sobre um produto de um fornecedor que não compilou. É possível adicionar SBOM de fornecedores ao CRACI, mas a resposta só é tão boa quanto a SBOM do fornecedor.
Precisa de detetar um pacote malicioso completamente novo antes de existir qualquer aviso de segurança. O CRACI assinala versões maliciosas conhecidas assim que é publicado um aviso com CVE; não deteta malware pelo comportamento ou reputação (responder a vulnerabilidades zero-day).

Perguntas frequentes

O que devo dizer aos clientes quando um ataque à cadeia de abastecimento chega às notícias?

Envie uma primeira declaração em poucas horas: tem conhecimento do ataque, está a verificar os seus produtos e builds, o que sabe até ao momento e quando vai dar uma atualização. Siga-a com uma resposta confirmada para versões identificadas do produto assim que a puder apoiar em registos de build, e com um acompanhamento quando algo mudar.

O que deve dizer uma primeira declaração?

O que aconteceu, numa frase, que está a verificar os seus produtos e sistemas de build, o que encontrou até ao momento, a hora da próxima atualização e um contacto. Não pode dizer «não afetado» antes de ter verificado, especular sobre o atacante nem culpar ninguém.

Como dizer «não estamos afetados» sem prometer demasiado?

Identifique os produtos e versões que verificou, o intervalo de datas dos builds verificados e as evidências que usou, como o registo dos componentes que cada build de lançamento instalou. Diga «não afetado» para essas versões, ofereça a SBOM ou uma declaração VEX e comprometa-se a dar uma atualização se algo mudar. Evite «100% seguro» ou «totalmente seguro».

O que deve conter um aviso aos clientes de que «fomos afetados»?

Que produtos e versões estão afetados, desde quando e até que versão corrigida, o risco em linguagem simples, o que o cliente deve fazer agora (atualizar, fazer a rotação de credenciais, bloquear hosts), o que já fez, quando chega a próxima atualização e quem contactar.

Que evidências devem apoiar uma declaração «não afetado»?

Para cada versão que os clientes executam, o registo do que instalou o build que a produziu, não o lockfile de hoje. Acrescente os registos de todos os builds executados durante a janela do ataque e, no caso de ataques que roubam credenciais, se havia secrets presentes em jobs que possam ter executado o código malicioso.

Tenho de notificar um ataque à cadeia de abastecimento ao abrigo do Cyber Resilience Act?

Possivelmente. Desde 11 de setembro de 2026, os fabricantes de produtos com elementos digitais vendidos na UE têm de notificar as vulnerabilidades ativamente exploradas e os incidentes graves com impacto na segurança do produto: um alerta precoce no prazo de 24 horas, uma notificação no prazo de 72 horas e um relatório final. Saber se um determinado ataque se enquadra é uma avaliação que cabe a si e ao seu advogado.

Com que rapidez devemos responder aos clientes?

Em poucas horas, com uma primeira declaração, mesmo que diga apenas que está a verificar e quando vai dar uma atualização. A resposta confirmada segue-se assim que a puder provar. Um «estamos a verificar» rápido e honesto faz mais pela confiança do que um «não afetado» tardio.

Está tudo seguro? Como responder aos clientes após um ataque à cadeia de abastecimento