Prefácio

Há uma categoria de ironia nesse campo que deixa de ser engraçada quando você a acompanha em três anos fiscais consecutivos. O software mais sistematicamente direcionado na cadeia de suprimentos de software é o próprio software de segurança. Não são APIs de pagamento fintech. Não são provedores de federação de identidade. Scanners de vulnerabilidade. Utilitários de verificação de integridade de CI/CD. Uma biblioteca de compressão integrada ao encanamento de autenticação SSH de aproximadamente metade da frota Linux do planeta.

Isso não é má sorte. É a seleção de alvos. E vale a pena examinar cuidadosamente os critérios de seleção, pois eles revelam algo sobre a sofisticação dos invasores que a maioria dos relatórios de incidentes de fornecedores, por motivos comerciais óbvios, tende a subestimar.

Este blog aborda quatro compromissos confirmados e distintos da cadeia de suprimentos em março de 2024, março de 2025 e março de 2026, os dois últimos detonando dentro de 24 horas um do outro no mesmo mês. Os incidentes individuais foram documentados em outro lugar. As correlações traçadas aqui não foram, que eu saiba, publicadas desta forma. Vou sinalizar especificamente onde acho que o setor errou no enquadramento.

Estudo de caso I — XZ Utils (CVE-2024-3094): a operação de paciência de dois anos

Plano de fundo

Em 28 de março de 2024, Andres Freund, um engenheiro da Microsoft comparando algo não relacionado em seu sistema Debian sid pessoal, percebeu que a autenticação SSH estava atrasada em aproximadamente 500 ms. Essa observação é a razão pela qual não estamos escrevendo um tipo completamente diferente de retrospectiva no momento. O backdoor embutido no XZ Utils 5.6.0 e 5.6.1 obteve um CVSS 10.0 e foi capturado três semanas antes do lançamento estável no Debian e no Fedora.

O jogo Jia Tan Long

O agente da ameaça operava sob o nome JiAT75 do GitHub, apresentando-se como “Jia Tan”. Conta criada em outubro de 2021. O que se seguiu foram mais de 30 meses sendo um colaborador genuinamente útil. Correções de bugs, melhorias de desempenho, engajamento tecnicamente competente em tópicos de relações públicas. A conta passou pela revisão do código repetidamente porque o código estava, na verdade, correto.

Essa é a parte em que a maioria dos artigos gasta uma frase: o atacante fez um trabalho real. Isso não é incidental à operação, é a operação. Marcas principais:

• Novembro de 2021: Primeiro commit: uma correção modesta de buffer, passa pela revisão de forma limpa
• Meados de 2022: A segunda pessoa coordenada, Jigar Kumar, começa a pressionar o mantenedor Lasse Collin a mesclar os patches de Jia Tan mais rapidamente; uma terceira conta, “Hans Jansen”, aplica pressão semelhante
• Janeiro de 2023: Jia Tan concedeu acesso ao commit após contribuições sustentadas de qualidade
• Fevereiro de 2024: Carga maliciosa introduzida por meio de dois arquivos de teste binários: testes/arquivos/bad-3-corrupt_lzma2.xz e testes/arquivos/good-large_compressed.lzma

A campanha de pressão é uma técnica clássica da HUMINT, fabricando consenso social em torno de uma meta, aplicada à governança de projetos de código aberto. Desde então, Lasse Collin falou publicamente sobre o estresse de se manter sozinho sob pressão social ativa.

Arquitetura técnica do Backdoor

O mecanismo de injeção no tempo de construção merece mais atenção do que recebeu nas retrospectivas de 2024. Durante a fabricação, o bad-3-corrupt_lzma2.xz o arquivo de teste foi desofuscado usando o utilitário Unix tr, uma ferramenta de tradução de strings com associação zero a operações criptográficas, o que significa que não aciona nenhuma heurística de varredura em tempo de construção de nenhum scanner de uso comum. O script bash resultante injetou um arquivo de objeto pré-compilado no estágio de construção do liblzma.

O implante final enganchado RSA_public_decrypt resolução em SSHD. Em compilações vinculadas ao systemd, nas quais o libsystemd vincula o liblzma, o backdoor enfraqueceu a autenticação por chave pública — um oráculo de autenticação na pilha SSH. Antes de ser armado, ele executou verificações de ambiente: arquitetura x86_64, presença do systemd, libsystemd no mapa de memória do processo. Essa especificidade é a razão pela qual ele passou sem ser detectado em compilações do macOS e ambientes de CI não systemd durante os testes de pré-lançamento.

Mapeamento MITRE

‍

Estudo de caso II — reviewdog → tj-actions (CVE-2025-30066/CVE-2025-30154): A exploração automatizada de confiança

A arquitetura Pivot

Em 14 de março de 2025, tj-actions/arquivos alterados, incorporado em mais de 23.000 repositórios, foi encontrado executando um script Python malicioso em executores de CI. O relatório inicial definiu isso como um compromisso de ação única.

O cão de revisão (GitHub) org foi infiltrada por meio do sistema automatizado de convite de equipe do GitHub. Em determinadas configurações do repositório, os colaboradores que atingem os limites de atividade recebem convites automáticos de equipe com acesso à gravação. O atacante ultrapassou esse limite, recebeu um convite para @reviewdog /actions-maintainer, enviou um commit malicioso e redirecionou para a tag v1. Tudo a jusante resultou de uma única alteração no ponteiro da tag.

A cadeia completa de eliminação de dependências:

Etapa 1 — reviewdog/action-setup é um ação utilitária — ele instala a ferramenta de linting reviewdog no executor de CI. É uma licerce do qual dependem outras ações do reviewdog.

Etapa 2 — reviewdog/action-typos (e outras ações do reviewdog) chamam action-setup primeiro para instalar a ferramenta antes de fazer seu próprio trabalho. Então, quando a configuração da ação foi envenenada, cada ação que usou ele herdou o código malicioso silenciosamente.

Etapa 3 — tj-actions/eslint-changed-files usa ações de reviewdog internamente para remover arquivos alterados, então ele inseriu a configuração de ação envenenada de forma transitiva.

Etapa 4 — tj-actions/changed-files é um dos GitHub Actions mais usados que existem — ele detecta quais arquivos foram alterados em um PR. Depende internamente de arquivos alterados pelo eslint, então também absorveu o veneno.

Etapa 5 — Mais de 23.000 repositórios tinham tj-actions/changed-files em seus fluxos de trabalho. Nenhum deles alterou uma única linha do seu próprio código. Eles apenas executaram seus pipelines de CI normais e a carga maliciosa de captura de memória foi executada silenciosamente em seus executores.

O ponto central: O atacante nunca tocou diretamente nos 23.000 repositórios afetados. Eles comprometeram uma ação fundamental da qual todo o resto dependia, como envenenar uma estação de tratamento de água em vez de bater em 23.000 portas individuais.

O script malicioso executou o acesso direto à memória do processo via /proc/ {PID} /mem no processo do GitHub Actions Runner:

• PIDs enumerados correspondentes a Runner.Worker, Runner.Listener, runsvc, run.sh
• Analisado /proc/ {PID} /maps para localizar regiões de memória ativa

Memória bruta digitalizada com Regex para a estrutura JSON secreta interna do GitHub: “nome”: {"valor”:”...”, “é secreto”: verdadeiro}

Mapeamento MITRE

‍

Estudo de caso III — Aqua Security//Trivy (março de 2026): o Infostealer de vários estágios apoiados por blockchain

Três ondas, três modos de falha diferentes

Onda 1: configuração incorreta de pull_request_target (final de fevereiro de 2026)

Um bot autônomo, hackerbot-claw, explorou o gatilho pull_request_target no fluxo de trabalho do Trivy no GitHub Actions. Ao contrário do evento padrão pull_request, esse acionador executa o fluxo de trabalho da ramificação base com acesso total ao escopo de gravação aos segredos do repositório quando um PR externo é aberto. Um token de acesso pessoal privilegiado foi extraído.

Onda 2: Remediação incompleta (1—19 de março de 2026)

A Aqua divulgou publicamente as credenciais da Onda 1 e rotacionou em 1º de março. A rotação perdeu o token da conta de serviço aqua-bot, que havia sido provisionado com permissões de assinatura de lançamento idênticas às do PAT que foi alternado. O atacante manteve o acesso residual por 18 dias por meio do token de bot não revogado.

Onda 3: Tag Poisoning + Binary Backdoor (19 de março, 17:43 UTC)

Usando as credenciais retidas pelo aqua-bot, o atacante forçou 76 das 77 tags de versão em trivy-action e todas as 7 em setup-trivy a um commit malicioso, ao mesmo tempo em que publicou trivy v0.69.4 por meio da automação de lançamento comprometida. Uma única tag limpa sobrevivente — v0.35.0 — foi ancorada pelo recurso opcional de lançamentos imutáveis do GitHub.

Análise forense de carregamento útil: O Delta do entrypoint.sh

Um aumento de 6,16 vezes no tamanho do arquivo. A interface de usuário de lançamento do GitHub não revelou nenhum indicador dessa mudança. Nenhuma ferramenta SCA convencional realiza o monitoramento da integridade do arquivo de artefato nos pontos de entrada de ação em todas as execuções do pipeline.

O bloco injetado de 105 linhas executou uma varredura completa de credenciais antes de invocar o scanner legítimo, então os pipelines pareciam ter sucesso normalmente enquanto eram drenados. A falha se ramificou no tipo de executor: executores hospedados no GitHub obtiveram captura de memória de processo (técnica idêntica à tj-actions); executores auto-hospedados obtiveram uma ampla busca no sistema de arquivos usando chaves SSH, credenciais AWS/GCP/Azure, tokens Kubernetes,

Configurações do Docker, status do Terraform, segredos do Helm e arquivos de carteira de criptomoedas. Os dados foram coletados com AES-256-CBC sob uma chave de sessão encapsulada com RSA-4096, tornando o payload.enc irrecuperável sem a chave privada do atacante, mesmo que o binário seja capturado e analisado.

O Blockchain C2: o problema da infraestrutura que não pode ser desmontado

O binário trivy v0.69.4 excluiu ~/.config/sysmon.py, nomeado para se misturar aos ambientes que executavam ferramentas sysmon legítimas, dormiu 5 minutos (evasão de sandbox) e, em seguida, consultou C2 em:

hxxps: //tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0.io

Esse endpoint é servido pelo blockchain Internet Computer (ICP), operado pela Fundação DFINITY. Sem registro. Sem operador de DNS. Sem provedor de hospedagem. Nenhum endereço abuso@ que produza uma remoção. O manual padrão de resposta a incidentes, a reclamação do registrador, a rota nula do BGP e o aviso da CISA não funcionam, por design, contra a infraestrutura hospedada pelo ICP. O bloqueio do *.icp0.io no perímetro da rede funciona, mas gerará danos colaterais crescentes à medida que os aplicativos ICP legítimos crescerem na implantação.

O caminho alternativo de exfil foi igualmente considerado: se o C2 primário estivesse inacessível, o malware criava um repositório público do GitHub chamado tpcp-docs na organização vítima, publicava uma versão com data e hora e fazia o upload do pacote de credenciais criptografado pela RSA como um ativo de lançamento, roteando a extração por objects.githubusercontent.com, um domínio que as organizações praticamente não conseguem bloquear quebrar seus canais de CI/CD.

Mapeamento MITRE

Estudo de caso IV — litellm v1.82.8 (PyPI, 24 de março de 2026): A escalada de execução automática de.pth

Plano de fundo

O LiteLM, uma das bibliotecas Python mais usadas para rotear chamadas entre OpenAI, Anthropic, Cohere e outras APIs LLM, teve as versões v1.82.7 e v1.82.8 publicadas no PyPI com uma carga maliciosa. Os pacotes foram enviados sem uma tag ou versão correspondente do GitHub, o que significa que o pipeline de lançamento padrão foi totalmente ignorado e o invasor foi enviado diretamente para o registro do pacote usando credenciais de manutenção comprometidas.

O problema do GitHub levantado pela comunidade foi encerrado como “não planejado” em poucas horas e imediatamente inundado com centenas de contas de bots para diluir o tópico de discussão — uma técnica de supressão que sugere segurança operacional pré-planejada, não um ator oportunista.

O mecanismo de execução automática do.pth

Essa é a escalada técnica que distingue o ataque litellm de tudo o que precedeu neste relatório. Os ataques anteriores exigiam a execução do pipeline de CI/CD ou uma sessão SSH ativa para acionar a carga. O malware litellm usava um arquivo Python .pth chamado litellm_init.pth.

Os arquivos.pth do Python são arquivos de configuração de caminho processados automaticamente pelo interpretador Python em cada inicialização, sem instrução de importação, sem chamada explícita, sem necessidade de ação do usuário. Qualquer processo Python iniciado em uma máquina com o pacote instalado executa o carregamento de forma silenciosa e automática a partir do momento da instalação. Isso inclui laptops para desenvolvedores locais, não apenas executores de CI.

O mecanismo cria um efeito colateral não intencional de bomba bifurcada: o arquivo.pth gera um processo secundário do Python por meio do subprocess.Popen, que por sua vez aciona o mesmo arquivo.pth na inicialização, bifurcando processos exponencialmente até a máquina travar. Isso era um bug sem malware. Um arquivo de bloqueio ou verificação de PID teria feito funcionar silenciosamente indefinidamente. Ironicamente, o acidente foi o que fez com que fosse notado.

Carga útil de três estágios

Mapeamento MITRE

The Gap: Onde o ATT&CK fica aqui de CI/CD

Três vetores de ataque específicos desses incidentes não têm um mapeamento ATT&CK limpo:

1. Escalonamento de privilégios pull_request_target
A exploração do gatilho pull_request_target do GitHub para acessar os segredos da ramificação básica de um PR externo e não confiável é uma técnica de acesso inicial específica para CI/CD. O T1195.001 é o mapeamento mais próximo, mas descreve o comprometimento da dependência, não o abuso do gatilho do fluxo de trabalho. Não existe uma técnica ATT&CK para “abuso do escopo de privilégios de gatilho do fluxo de trabalho de CI/CD”.

2. Propagação da dependência transitiva como movimento lateral
A cadeia de eliminação reviewdog → tj-actions não envolveu roubo de credenciais, pivô de rede e vulnerabilidade explorada no sentido tradicional. Foi pura herança de confiança por meio de um gráfico de dependência. O T1199 (Relacionamento confiável) se aproxima disso, mas essa técnica foi projetada para relacionamentos com provedores de TI terceirizados, não para gráficos automatizados de dependência de pacotes. A distinção é importante para a engenharia de detecção.

3. C2 hospedado em blockchain
O T1102 (Web Service) é o mapeamento mais próximo para o blockchain ICP C2, mas o T1102 foi projetado para o uso de serviços web legítimos por invasores, como Twitter ou Pastebin. A infraestrutura de blockchain do ICP é categoricamente diferente, é descentralizada, imutável e não tem caminho para denunciar abusos. O perfil de resistência à queda do blockchain C2 não é capturado em nenhum lugar na estrutura atual da ATT&CK. Essa é uma lacuna genuína que o MITRE precisará resolver à medida que essa técnica se proliferar.

Correlações entre incidentes: o que os fornecedores não estão publicando

O efeito de março

XZ Utils: março de 2024. tj-actions/reviewdog: março de 2025. Trivy/Aqua: março de 2026.

Parte disso pode ser o momento da divulgação e não o momento da detonação; as investigações levam semanas. Mas há um argumento estrutural: março é quando a pressão do ciclo de lançamento do primeiro trimestre atinge o pico, quando os principais mantenedores são atraídos para viagens de conferência (RSA, KubeCon EU e S4, todos no outono, do primeiro trimestre ao segundo trimestre) e quando os ciclos de implantação corporativa do primeiro trimestre significam que a adoção posterior de novos lançamentos atinge níveis anuais máximos. Um agente de ameaças instrumentando a frequência de confirmação do GitHub e a latência da revisão de relações públicas como proxies de atenção consideraria empiricamente que March é a janela de exploração ideal. Três marchas consecutivas sugerem que vale a pena levar a sério essa hipótese.

A tese de segmentação de ferramentas de segurança

Os três projetos comprometidos, xz-utils (incorporado ao sshd via liblzma), trivy-action (scanner de segurança), tj-actions/changed-files (detecção de alterações de CI), compartilham uma propriedade que as bibliotecas de aplicativos não têm: eles são executados com alta confiança implícita na interseção privilegiada de toda a superfície de implantação de uma organização.

Um scanner de segurança comprometido não coleta as credenciais de um pipeline. Ele coleta credenciais para cada alvo que está sendo escaneado em nome da organização, registros de contêineres, contas na nuvem, configurações de IaC e clusters Kubernetes. O multiplicador do raio de explosão de uma ferramenta de segurança comprometida é categoricamente maior do que o de uma biblioteca de aplicativos comprometida. Os agentes de ameaças descobriram isso comprovadamente. A comunidade de defesa demorou mais em articulá-la.

Evolução da infraestrutura C2: uma clara progressão

A progressão do implante passivo → efêmero log exfil → typosquatted HTTPS → GitHub CDN → blockchain C2 descreve uma busca sistemática por infraestrutura resistente à remoção. O ICP é o ponto final atual dessa pesquisa.

A armadilha de remediação incompleta é estrutural

Tanto em tj-actions quanto em Trivy, a remediação pós-divulgação deixou o acesso residual intacto. A Aqua Security confirmou que o token aqua-bot sobreviveu à noite de rotação de 1º de março. Essa não é uma falha específica do Aqua, ela reflete como os tokens de bot são gerenciados universalmente: provisionados uma vez, incorporados aos segredos do repositório e excluídos da disciplina de rotação aplicada às credenciais humanas.

Os PATs humanos vivem em gerentes secretos com trilhas de auditoria. Os tokens de conta de serviço automatizados não têm proprietário, não têm política de expiração e são consistentemente a primeira coisa perdida em uma caixa rotativa. A correção estrutural é óbvia e não é amplamente implementada: os tokens de bot com escopo para liberação e acesso de gravação de tags devem ser alternados no mesmo cronograma das credenciais humanas privilegiadas e devem ser os primeiros auditados em qualquer revisão pós-comprometimento.

Falsificação de metadados de confirmação: os carimbos de dados/hora da interface do usuário do GitHub não são confiáveis

O commit malicioso do Trivy tinha carimbos de data/hora do autor datados de 09/07/2024, definidos por meio de GIT_AUTHOR_DATE e GIT_COMMITTER_DATE, como o nome do autor copiado de um confirmador anterior legítimo e uma mensagem de confirmação dizendo “Atualize trivy to v0.53.0 (#369)”. A interface de usuário do lançamento do GitHub exibiu esses metadados de forma idêntica antes e depois do reposicionamento da tag. Nenhum indicador visual refletiu a mudança.

Qualquer reconstrução do cronograma de resposta a incidentes ancorada nos metadados da interface do usuário web do GitHub está funcionando com evidências de que um invasor pode forjar com um único comando shell. A única âncora forensicamente confiável é o commit SHA, verificado com base em atestados de proveniência SLSA, registros de transparência da Sigstore ou registros de liberação assinados.

A assinatura de persistência do sysmon.py: kit de ferramentas compartilhado ou ator compartilhado?

O binário Trivy (v0.69.4) deixou um backdoor em ~/.config/sysmon.py. O malware litellm instala a persistência em ~/.config/sysmon/sysmon.py com um serviço de usuário systemd correspondente. A convenção de nomenclatura, a estrutura do diretório, o esquema de criptografia AES-256-CBC+ RSA-4096 e a coleta de terminais de metadados do IMDS são idênticos em ambos os incidentes — e os dois incidentes detonaram em março de 2026, com cinco dias de diferença do outro.

Esse é o mesmo agente de ameaça reutilizando a mesma estrutura de ferramentas em dois alvos separados ou dois atores diferentes usando um kit de malware comercial/clandestino compartilhado. Qualquer interpretação é mais alarmante do que a coincidência. O padrão de nomenclatura sysmon.py agora deve ser tratado como um indicador de cluster de ameaças. Qualquer arquivo que corresponda a ~/.config/sysmon*.py em uma máquina de desenvolvimento ou executor de CI garante uma triagem imediata.

Engenharia de deteção: o que as ferramentas padrão perdem

Sinal 1 — Monitoramento do tamanho do arquivo do Entrypoint

Registre o tamanho do byte de cada arquivo entrypoint.sh baixado do GitHub Action por {action} @ {sha} no momento da execução do pipeline. Alerta sobre desvios superiores a 50% da linha de base estabelecida. A injeção Trivy, um aumento de tamanho de 6,16 vezes, teria sido detectada antes que uma única credencial fosse roubada. Este é um invólucro de 10 linhas em torno do bootstrap do seu corredor. Quase ninguém construiu.

Sinal 2 — Detecção de confirmação pendente

O commit malicioso do Trivy e0198fd2b6e1679e36d32933941182d9afa82f6f não pode ser acessado no branch master, ele existe apenas porque a tag faz referência a ele. A API do GitHub expõe a acessibilidade do commit.

Signal 3 — Saída do domínio Blockchain dos CI Runners

Os executores hospedados no GitHub não têm motivos legítimos para entrar em contato com *.icp0.io ou *.ic0.app. O bloqueio em nível de rede nas sub-redes do executor de CI, além do registro de consultas de DNS para esses domínios, teria fornecido a detecção pré-exploração do ciclo de pesquisa C2 do binário Trivy.

Signal 4 — Novo token/sub-rede/repositório triplo nos registros de auditoria do GitHub

Sinaliza qualquer evento git.push em que a tupla (hashed_token, prefixo de sub-rede /16, target_repo) não tenha aparecido na linha de base anterior a 7 dias. A atividade legítima do desenvolvedor raramente introduz as três dimensões simultaneamente. Os tokens roubados usados pela infraestrutura controlada pelo atacante para serem enviados para repositórios desconhecidos serão enviados.

Signal 5 — Pacote PyPI sem versão correspondente do GitHub

O ataque contornou totalmente o GitHub ao fazer o upload diretamente para o PyPI usando credenciais de manutenção comprometidas. Monitore seus arquivos de bloqueio de dependência do Python para qualquer versão do pacote que não tenha uma tag de lançamento do GitHub correspondente ou um atestado de procedência assinado no PyPI. Ferramentas como pip-audit combinadas com a API de origem do PyPI podem sinalizar incompatibilidades de versão a lançamento. Qualquer versão do pacote no PyPI sem uma versão correspondente do GitHub deve ser tratada como não verificada até que se prove o contrário.

As 10 principais dicas para equipes de segurança

1. Pare de usar tags de versão no GitHub Actions, use SHAs de confirmação

As etiquetas são ponteiros mutáveis. Um invasor com acesso de gravação no repositório pode redirecionar silenciosamente uma tag para um código malicioso com um carimbo de data/hora falsificado e nenhuma indicação de interface do usuário. Um SHA de confirmação completo é corrigido criptograficamente e remove toda a classe de ataque de envenenamento por tag.

2. Depois de qualquer comprometimento de CI/CD, audite os tokens do bot antes de qualquer outra coisa.

Os PATs humanos são alternados; os tokens dos bots são esquecidos. Nos incidentes de tj-actions e Trivy, tokens de contas de serviço não revogados com permissões idênticas deram aos atacantes acesso contínuo após a divulgação pública. Mantenha um inventário dedicado e alterne os tokens do bot no mesmo ciclo de 90 dias das credenciais humanas privilegiadas.

3. O scanner de segurança é o alvo de maior valor em seu pipeline.

Ele contém credenciais simultâneas para contas na nuvem, registros de contêineres, clusters Kubernetes e configurações de IaC, tudo o que ele verifica em seu nome. Um scanner comprometido não expõe uma tubulação; ele expõe todos os alvos que a tubulação está autorizada a alcançar.

4. Monitore os tamanhos dos arquivos do ponto de entrada do GitHub Action entre as execuções do pipeline.

O ponto de entrada malicioso do Trivy aumentou de 2.855 para 17.592 bytes, um aumento de 6,16 vezes que nenhuma ferramenta sinalizou. Uma linha de base de tamanho simples por {ação} @ {sha}, alertando sobre desvios acima de 50%, a teria sido detectada antes que uma única credencial fosse roubada.

5. Você é responsável por dependências que nunca escolheu explicitamente.

O ataque tj-actions atingiu 23.000 repositórios por meio de uma ação utilitária de três níveis de dependência anteriores que nenhuma dessas equipes jamais mencionou. Mapeie sua árvore completa de dependências de ações transitivas e marque qualquer coisa com acesso de gravação ou execução arbitrária de shell que você não possa contabilizar diretamente.

6. Bloqueie os domínios de saída do blockchain nas sub-redes do CI Runner de forma proativa.

O Trivy C2 foi hospedado no blockchain do ICP em *.icp0.io. Não existe nenhum registrador, nenhum provedor de hospedagem, nenhum caminho de remoção. O bloqueio da camada de rede é o único controle disponível e deve estar em vigor antes de um incidente, não em resposta a um.

7. Os timestamps de confirmação do GitHub não são forensicamente confiáveis.

GIT_AUTHOR_DATE e GIT_COMMITTER_DATE podem ser falsificados gratuitamente. O commit malicioso do Trivy foi datado de 2024 com um nome de autor copiado e uma mensagem plausível. Para qualquer investigação pós-incidente, somente o commit SHA validado com base na proveniência do SLSA ou nos registros de transparência da Sigstore pode ser confiável.

8. pull_request_target fornece aos PRs externos acesso aos seus segredos.

Ao contrário de pull_request, esse gatilho executa fluxos de trabalho de ramificação base com escopo totalmente secreto, mesmo em bifurcações de colaboradores não confiáveis. Audite cada fluxo de trabalho usando esse gatilho e aplique o escopo com menos privilégios. Se não houver justificativa documentada para uso, mude para pull_request.

9. Trate março como o mês de maior risco e planeje adequadamente.

Três marchas consecutivas, quatro detonações confirmadas na cadeia de suprimentos, duas somente em março de 2026, a segunda no dia seguinte à publicação deste relatório. A pressão de liberação do primeiro trimestre, as viagens de conferência do mantenedor e os ciclos de pico de implantação empresarial convergem em uma janela de exploração confiável. Execute sua auditoria de token de bot antes do trimestre anterior, aumente o monitoramento de dependências e acrescente uma análise adicional aos repositórios de ferramentas de segurança antes que março chegue.

10. A segmentação precisa e a exposição em massa não são mutuamente exclusivas.

O compromisso da reviewdog foi projetado especificamente para alcançar o pipeline de CI da Coinbase. Os 23.000 outros repositórios colhidos ao longo do caminho eram cobertura colateral. Se seu funil executou uma ação comprometida durante a janela de exposição, suas credenciais foram obtidas, independentemente de você ser o alvo pretendido. Avalie adequadamente as violações do escopo.

Nenhum desses incidentes foi detectado pelas próprias ferramentas de segurança do fornecedor

Essa é a observação que deveria estar em cada resumo executivo e não está: a Aqua Security, uma empresa cujo principal produto é a segurança da cadeia de suprimentos de contêineres e software, teve sua própria cadeia de suprimentos comprometida de uma forma que suas próprias ferramentas não detectaram. O CrowdStrike detectou o comprometimento do Trivy por meio de anomalias comportamentais nos canais de clientes, não por meio da própria infraestrutura de escaneamento da Aqua. O tj-actions foi detectado por um pesquisador terceirizado, não pela equipe de segurança do GitHub ou por qualquer uma das ferramentas de segurança das organizações afetadas. A XZ Utils foi detectada por um engenheiro que percebeu uma anomalia de desempenho durante um benchmarking não relacionado. Em todos os três casos, a detecção foi acidental, externa ou comportamental, nunca o resultado dos controles de segurança que estavam nominalmente implementados. O comprometimento do litellm foi detectado porque o bug da bomba bifurcada derrubou máquinas, não porque alguma ferramenta de segurança sinalizou o pacote malicioso. Uma implementação mais limpa teria sido executada silenciosamente indefinidamente. Cinco incidentes, zero detecções proativas por controles de segurança indicados.

O filme

Surpreso que tenha acontecido em março novamente? Os agentes de ameaças claramente têm um planejamento trimestral melhor do que a maioria das equipes de segurança. Três anos, três marchas, três compromissos, mas claro, vamos agendar o teste de caneta para o quarto trimestre. A ferramenta projetada para proteger seus segredos foi a que os roubou, e ninguém piscou. O atacante cometeu um código limpo pacientemente por dois anos e meio; seu patch foi aprovado por dois sprints e meio. E em algum lugar no momento, um comunicado da CISA está sendo elaborado para recomendar a fixação para cometer SHAs, enquanto um quinto incidente já está sendo realizado em março próximo, usando um caminho de persistência que ninguém adicionou às suas regras de detecção ainda.

Referências:

• https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/ 
• https://github.com/aquasecurity/trivy/discussions/10425
• https://thehackernews.com/2026/03/trivy-security-scanner-github-actions.html
• https://github.com/aquasecurity/trivy/security/advisories/GHSA-cxm3-wv7p-598c
• https://opensourcemalware.com/blog/teampcp-aquasec-com-github-org-compromise 
• https://www.cyberdaily.au/security/13366-code-security-platform-trivy-compromised-by-malicious-packages
• https://www.upwind.io/feed/trivy-supply-chain-incident-github-actions-compromise-breakdown
• https://www.crowdstrike.com/en-us/blog/from-scanner-to-stealer-inside-the-trivy-action-supply-chain-compromise/
• https://openssf.org/blog/2025/06/11/maintainers-guide-securing-ci-cd-pipelines-after-the-tj-actions-and-reviewdog-supply-chain-attack/
• https://github.com/advisories/ghsa-mrrh-fwg8-r2c3
• https://unit42.paloaltonetworks.com/github-actions-supply-chain-attack/ 
• https://.seqrite.com/blog/cve-2024-3094-unveiled-xz-utils-compromise-sparks-security-alarm/
• https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/