Marcas enganosas e commits impostores: o novo vetor de ataque na cadeia de fornecimento de software

Num novo exemplo de como a cadeia de fornecimento de software continua a ser um vetor atraente para os atacantes, foi detectada a compromissão da popular ação do GitHub actions-cool/issues-helper, onde atores maliciosos moveram todas as etiquetas (tags) do repositório para apontar para um commit impostor que não faz parte do histórico legítimo do projeto. O resultado: qualquer fluxo de trabalho que referencie a ação por etiqueta ou versão em vez de um SHA de commit confiável poderia baixar e executar código malicioso no runner de GitHub Actions na próxima execução.

A técnica do commit impostor explora uma propriedade menos conhecida dos tags: ao contrário de um SHA irrevogável, uma etiqueta pode ser reasignada por quem controle o repositório ou um fork malicioso. Neste caso, o código injectado descarrega o runtime Bun, tenta ler a memória do processo Runner.Worker para extrair credenciais presentes no ambiente de CI/CD e envia os dados para um servidor controlado pelo atacante ("t.m-kosche[.]com"). Segundo as primeiras análises, a mesma tática afetou outro repositório relacionado, actions-cool/maintain-one-comment, e a infra-estrutura de exfiltração liga este incidente com uma onda anterior que atacou pacotes npm no ecossistema @antv, sugerindo uma possível operação coordenada em múltiplas frentes.

As implicações para organizações e projetos open source são claras e profundas: Foi demonstrado que as integrações no CI/CD podem se tornar um vetor direto para a extração de segredos. Tokens do GitHub, credenciais de nuvem, chaves API e outros segredos usados em fluxos de trabalho automatizados podem ser lidos e exfiltrados se um ator conseguir executar código arbitrário no runner. Além disso, a facilidade para propagar o compromisso –mudar tags que muitas ações usam por defeito – aumenta o alcance do dano potencial.

A defesa contra esta classe de ataques deve combinar mudanças técnicas imediatas e políticas mais amplas de governação do software. No imediato, Reveja todos os workflows que utilizem ações de terceiros e reempláce qualquer referência não sólida (por exemplo, usar "v1" ou uma etiqueta) por um SHA de commit conhecido e auditado. O GitHub oferece recomendações e guias para endurecer o GitHub Actions que explicam boas práticas como o pinning a SHAs, limitar permissões de workflow e proteger segredos; essas diretrizes estão disponíveis na documentação oficial de Actions: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions.

Rotação de credenciais e contenção são passos indispensáveis uma vez que se detecta a possível exposição. Se um repositório ou fluxo de trabalho potencialmente vulnerável tem corrido desde que o commit impostor foi publicado, assumir compromisso e rotar Tokens e chaves utilizadas por esses workflows É a medida prudente. Paralelamente, o tráfego de saída deve ser bloqueado para domínios suspeitos na resolução DNS e nos firewalls da rede interna para impedir que dados continuem a sair enquanto se investiga.

Em um nível estratégico, este incidente reforça a necessidade de adotar práticas de integridade da cadeia de fornecimento mais robustas, como o modelo SLSA (Supply-chain Levels for Software Artifacts), que propõe controles para garantir a proveniência e a inmutabilidade dos artefatos: https://slsa.dev/. Além disso, implementar autenticação federada sem segredos embebidos (por exemplo OIDC para fornecedores cloud), runners de execução com menos privilégios e temporais, e políticas rigorosas de revisão e aprovação para inclusão de ações de terceiros, reduz a superfície de exposição.

Para equipamentos que gerem projetos open source ou infra-estruturas de CI em empresas, convém também auditar o uso de tags e forks que tenham acesso a publicar versões, e favorecer pipelines que não exponham segredos a ações de terceiros. Ferramentas de digitalização de supply chain e de reputação para pacotes e ações, bem como monitores de comportamento anormais em runners - por exemplo, downloads incomuns de binários como Bun ou picos de tráfego saliente a domínios novos - ajudam a detectar detecções precoces.

Finalmente, a lição operacional é que a segurança da cadeia de abastecimento exige tanto controlos técnicos como uma cultura organizacional que trate os segredos e as dependências de terceiros como elementos de risco crítico. Se a sua organização executa workflows afetados, actue já: identifique referências a actions-cool e outras ações de terceiros, substitua etiquetas por SHAs verificados, revogar e renovar credenciais expostas e adicione as permissões de suas pipelines. A prevenção e a resposta rápida são a diferença entre uma interrupção manejada e uma filtração de alto impacto.