Red team vs blue team
Os atacantes raramente visam a sua empresa. Visam o pacote, a Action ou a ferramenta de build de que empresas em todo o lado dependem, e depois experimentam o exploit em todas ao mesmo tempo. Não precisam da sua lista de dependências. A sua empresa precisa.
Um ataque à cadeia de abastecimento de software compromete algo a partir do qual um produto é construído, como um pacote open source, um componente de CI/CD ou o sistema de build, em vez de atacar diretamente o produto. O software moderno é maioritariamente código de outras pessoas: a maior parte vem de pacotes open source, e a maioria destes são dependências transitivas que ninguém na equipa escolheu. Comprometa um componente amplamente usado e chega a todas as organizações que constroem sobre ele.
Isso muda a forma como os atacantes escolhem os alvos. Não investigam as dependências de uma empresa. Escolhem um pacote ou uma ferramenta com grande alcance, exploram-no em todo o lado e veem o que responde.
É divulgada uma falha num pacote open source popular, e os atacantes exploram-na em todos os produtos que distribuem a versão vulnerável, normalmente como dependência transitiva que ninguém escolheu diretamente.
Um atacante apodera-se da conta de um responsável pela manutenção, ou um worm rouba tokens de publicação, e lança uma versão envenenada de um pacote de confiança. É executada no momento em que um build a instala, como aconteceu com o worm npm Shai-Hulud.
Um colaborador ganha confiança num projeto open source ao longo do tempo e depois introduz código malicioso numa versão que as distribuições e os produtos a jusante adotam, como aconteceu com a backdoor do xz utils.
Pacotes com nomes próximos dos populares apanham erros de digitação. A confusão de dependências vai mais longe: um pacote público com o mesmo nome de um pacote interno de uma empresa é instalado no seu lugar.
Uma GitHub Action ou outra ferramenta de build é sequestrada, e todos os pipelines que a usam executam o código do atacante com os respetivos segredos ao alcance, como aconteceu com o tj-actions e o Codecov.
O próprio build é alterado, ou o artefacto é trocado entre o build e a implementação, pelo que uma árvore de código-fonte limpa produz, ainda assim, uma versão comprometida, como aconteceu com a SolarWinds.
A SolarWinds é o ataque à cadeia de abastecimento mais conhecido: código malicioso inserido no build e distribuído aos clientes como uma atualização normal. Os ataques mais recentes visam antes os registos de pacotes e os pipelines de CI, onde um único pacote ou Action comprometidos chegam a todos os builds que os usam. Do mais recente para o mais antigo:
Um worm que se propaga sozinho, é executado quando se instala um pacote npm infetado, rouba tokens de npm, GitHub e cloud, e publica versões infetadas dos outros pacotes da vítima. A maioria das infeções ocorreu na CI.
Como verificar os seus builds →A CISA reportou que todas as versões desta popular GitHub Action estiveram comprometidas durante três dias, com segredos expostos nos registos dos workflows. Os workflows que a referenciavam por tag executaram o código do atacante.
Andres Freund encontrou uma backdoor nas versões 5.6.0 e 5.6.1 do xz depois de reparar que os inícios de sessão SSH estavam a usar demasiada CPU. Tinha sido introduzida no próprio projeto upstream.
Uma falha no Apache Log4j 2 permitia a um atacante que controlasse uma mensagem registada executar código arbitrário, com classificação CVSS 10.0. A parte difícil para a maioria das equipas foi descobrir que aplicações continham o log4j-core, normalmente como dependência de uma dependência.
Os atacantes alteraram o script Bash Uploader que as equipas executavam nos seus pipelines de CI, para que enviasse o ambiente de CI, incluindo credenciais, tokens e chaves, para um servidor fora da infraestrutura da Codecov. Funcionou sem ser detetado desde 31 de janeiro até um cliente o reportar a 1 de abril.
Os atacantes tinham acesso prolongado e dissimulado ao processo de build do SolarWinds Orion e inseriram código malicioso nas versões 2019.4 a 2020.2.1 HF1 do Orion, que os clientes instalaram como atualizações normais. A CISA emitiu uma diretiva de emergência em resposta.
Red team vs blue team
Cada fase nas palavras do atacante, e a defesa que lhe responde.
Fase 1 de 3
Não é preciso conhecer o alvo. Escolha o pacote, e os alvos escolhem-se sozinhos.
Red team
Não precisa do lockfile deles. Os pacotes populares estão no fundo da árvore transitiva de quase tudo, e a maioria das equipas não sabe dizer quais distribui. As pistas públicas restringem a procura: versões em bundles de JavaScript e em cabeçalhos HTTP, repositórios públicos e imagens de contentor. E tudo o que o build deles obtém fora do lockfile, como o binário que um script postinstall descarrega ou as camadas por baixo da imagem base, nunca foi visto pelo scanner deles, por isso ninguém o está a corrigir.
Blue team
O CRACI vê o tráfego que entra em cada build e regista cada pacote e ficheiro que este traz, incluindo as dependências ocultas que escapam às ferramentas baseadas em lockfiles, a qualquer profundidade da árvore transitiva. A sua SBOM vem do build que foi distribuído, pelo que tem a lista de que um atacante nunca precisou, antes de alguém a ir procurar.
SBOM durante o build →Red team
Um novo aviso de segurança diz-lhe exatamente que versões são vulneráveis. Construa o exploit, procure tudo o que responda e deixe a análise dizer-lhe quem são. Começa no próprio dia, enquanto a equipa deles ainda pergunta "estamos afetados?" numa conversa de Slack.
Blue team
O CRACI reavalia continuamente as SBOM monitorizadas face a novos dados de vulnerabilidades. O histórico de builds mostra que builds continham a dependência vulnerável, direta ou transitiva, para que saiba onde foi distribuída e durante quanto tempo.
Estamos afetados? →Fase 2 de 3
Explore a falha antes de ser corrigida, ou ignore a falha e aproveite o pipeline deles.
Red team
A IA transforma um aviso de segurança e um diff de correção num ataque funcional antes de a equipa de segurança deles ter feito a triagem do ticket. A divulgação é o seu tiro de partida. O planeamento do sprint deles é na próxima semana.
Blue team
Os policy gates podem bloquear qualquer build que contenha uma CVE específica, pelo que a versão vulnerável deixa de ser distribuída no momento em que o decidir, por mais fundo que esteja na árvore.
Remediação de CVE →Red team
Os workflows confiam em tags como @v4, e as tags podem ser movidas. Comprometa uma GitHub Action popular e todos os workflows que a usam executam o seu código, com os segredos deles ao alcance.
Blue team
O CRACI regista as GitHub Actions que um workflow executa na SBOM do build, fixadas ao commit que foi realmente executado. Quando uma Action é comprometida, pode ver que builds executaram o código malicioso em vez de adivinhar a partir de uma tag.
Lista de verificação de segurança de CI/CD →Fase 3 de 3
Leve os segredos e fique por perto para obter mais.
Red team
Uma versão maliciosa de um pacote executa o seu script de instalação dentro do build deles, onde estão os tokens e as credenciais de cloud. Os runners de CI conseguem normalmente chegar a toda a internet, pelo que os segredos partem para o seu servidor antes de alguém saber que o pacote é malicioso.
Blue team
Uma política de egress de negação por defeito permite que um build chegue às suas origens de pacotes e destinos de publicação, e bloqueia tudo o resto. O malware que envie os seus segredos para o host de um atacante é bloqueado, mesmo como paciente zero de um ataque que ninguém viu antes, e a sua empresa recebe um alerta sobre a violação da política.
Políticas de egress →Red team
Os runners self-hosted de longa duração são uma dádiva: plante algo no espaço de trabalho ou na cache de ferramentas e espere que o próximo job, e o próximo conjunto de segredos, venha ter consigo.
Blue team
Cada job do CRACI é executado na sua própria máquina virtual isolada, pelo que nada do que um job deixa para trás fica à espera do seguinte. Também não existe nenhuma frota de runners para corrigir e reforçar.
Runners geridos vs self-hosted →Após a divulgação
O atacante não precisa de saber que a sua empresa executa a dependência. Experimenta o exploit em todo o lado e vê o que responde. A sua equipa precisa de saber onde essa dependência foi distribuída. A diferença está em ter ou não de a ir procurar, e há mais corridas todos os anos: consulte quantas CVE são publicadas por dia.
Red team
Blue team, sem registo do build
Blue team, com o CRACI
Nenhum controlo trava todos os ataques à cadeia de abastecimento. Combine estes, e cada fase acima fica mais difícil. Para o lado do pipeline em pormenor, consulte a lista de verificação de segurança de pipelines de CI/CD.
Os atacantes vigiam todos os avisos de segurança e experimentam o exploit em toda a gente no dia em que uma vulnerabilidade é divulgada. Nunca precisaram da sua lista de dependências. A sua empresa precisa. O CRACI dá à sua equipa essa lista, retirada do próprio build, e fecha as portas com que os atacantes contam: egress aberto e runners partilhados.
Um ataque ao código, às ferramentas ou aos serviços a partir dos quais um produto é construído, como um pacote open source, um componente de CI/CD ou o sistema de build, em vez de ao próprio produto. Um único comprometimento chega a todas as organizações que usam o componente afetado.
O worm Shai-Hulud (desde 2025) propagou-se através de pacotes npm infetados e roubou segredos de CI. O comprometimento do tj-actions/changed-files (CVE-2025-30066) sequestrou uma GitHub Action popular. A backdoor do xz utils (CVE-2024-3094) foi introduzida numa biblioteca de compressão upstream. O Log4Shell (CVE-2021-44228) explorou uma falha numa biblioteca de registo Java amplamente usada. O Bash Uploader da Codecov (2021) foi alterado para enviar credenciais de CI para um servidor externo, e o SolarWinds Orion (2020) distribuiu código malicioso inserido no build.
O da SolarWinds. Em 2020, atacantes com acesso dissimulado ao processo de build do SolarWinds Orion inseriram código malicioso nas suas versões, e os clientes instalaram-no como uma atualização normal. Mostrou que uma árvore de código-fonte limpa não basta: o próprio build tem de ser fiável e verificável.
Normalmente não, nem precisam de saber. A maioria dos ataques visa um pacote e não uma empresa: assim que é publicado um aviso de segurança, os atacantes experimentam o exploit em tudo o que possa executar uma versão vulnerável e veem o que responde. As pistas públicas, como versões em bundles de JavaScript ou repositórios open source, ajudam-nos a apontar. A assimetria é que a sua empresa precisa da lista: para saber se é afetada, tem de saber o que cada build distribuiu, incluindo o que obteve fora do lockfile.
Nenhum controlo os trava a todos. Mantenha uma SBOM do que cada build distribui e monitorize-a face a novos avisos de segurança, fixe as dependências e as GitHub Actions, bloqueie as versões vulneráveis no build, restrinja aquilo a que os jobs de CI se podem ligar, isole os jobs e limite os seus segredos, e verifique se os artefactos implementados são os que compilou.
Faça commit de um lockfile e instale a partir dele na CI, e desative os scripts de instalação onde um build não precisar deles (--ignore-scripts do npm). Mantenha um registo das versões de pacotes que cada build realmente instalou, para poder verificar rapidamente quando for anunciada uma nova vaga como o Shai-Hulud. Restrinja aquilo a que os jobs de CI se podem ligar, para que um script de instalação malicioso não consiga enviar os seus tokens para fora, e faça a rotação de qualquer token a que uma versão infetada possa ter chegado.
Nos exercícios de segurança, a red team faz de atacante e a blue team defende. Esta página usa a mesma divisão: cada fase de um ataque à cadeia de abastecimento nas palavras do atacante, com a resposta da defesa.
Os conhecidos, sim. Uma versão maliciosa com uma CVE publicada, como a backdoor do xz, é assinalada como qualquer outra vulnerabilidade, e um policy gate pode bloquear os builds que a contenham. O CRACI não analisa o comportamento dos pacotes nem pontua a sua reputação, pelo que um pacote malicioso totalmente novo não é assinalado até existir um aviso de segurança. É para isso que serve a política de egress: com a negação por defeito, o build só chega aos hosts de que precisa, pelo que o pacote não consegue enviar os seus segredos para fora, mesmo num ataque que ninguém viu antes.