Comprometimento de Supply Chain no Axios: Análise e Recomendações para Azure Pipelines

No dia 31 de março de 2026, o ecossistema de desenvolvimento JavaScript foi alvo de um ataque de supply chain envolvendo versões maliciosas da biblioteca HTTP axios (1.14.1 e 0.30.4) publicadas no npm registry. O código malicioso continha uma dependência oculta desenhada para estabelecer comunicação com servidores de Comando e Controle (C2) e baixar um carregador de segundo estágio.

Para times de engenharia e SREs focados em pipelines automatizados, o risco é claro: se o seu build orquestra a resolução de dependências em tempo de execução, ambientes de deployment e agentes de build podem ter sido comprometidos silenciosamente. Embora o Azure Pipelines, como serviço, não tenha sido invadido, a segurança da sua esteira depende da integridade do código que você instrui a sua infraestrutura a baixar.

O Impacto Real em Azure Pipelines

É fundamental separar o serviço da execução. O Azure Pipelines utiliza Microsoft-hosted agents que funcionam em instâncias isoladas e descartáveis; portanto, uma vez que o job termina, a VM é destruída. No entanto, o dano ocorre durante a janela de execução: se o seu pipeline instalou uma dessas versões, credenciais, secrets ou tokens de service connections expostos ao job podem ter sido exfiltrados. O risco é real tanto para self-hosted agents (que possuem persistência local e caching) quanto para containerized build environments.

Para times operando no Brasil sob modelos de alta conformidade, a resposta não deve ser apenas reativa, mas pautada em auditoria. Se a sua empresa utiliza Marketplace extensions ou custom scripts que fazem npm install ou update sem pinning de versões, a superfície de ataque é significativa.

Plano de Ação e Mitigação

Recomendamos que seus times de DevOps e Segurança realizem as seguintes verificações:

1. Auditoria de Logs: Analise os logs do seu pipeline em busca das versões [email protected], [email protected] ou da dependência [email protected].
2. Análise de Rede: Monitore tráfegos atípicos direcionados aos indicadores de comprometimento (sfrclak[.]com e o IP 142.11.206.73, porta 8000).
3. Sanitização de Agentes: Em caso de uso de self-hosted agents, a recomendação é o rebuild ou reimaging imediato das instâncias afetadas, pois pacotes podem persistir em caches locais.
4. Revogação de Credenciais: Se um job infectado tinha acesso a service connections (Azure, Kubernetes, Container Registries), trate essas credenciais como comprometidas e execute a rotação imediata.

Construindo um Supply Chain Imunizado

Para evitar que incidentes similares impactem a estabilidade e a segurança da sua operação, implemente as seguintes práticas de SecOps:

• Deterministic Installs: Utilize npm ci em vez de npm install nos seus pipelines. O comando npm ci depende estritamente do package-lock.json, garantindo que versões arbitrárias não sejam instaladas durante o deployment.
• Pinning de Dependências: Elimine o uso de prefixos como ^ ou ~ em versões críticas. O pinning fixo protege contra a ingestão de updates maliciosos automáticos.
• Princípio do Menor Privilégio: Limite o escopo das service connections e das variáveis de ambiente. Um erro de supply chain só é grave se o pipeline tiver permissões excessivas para acessar o restante do seu ecossistema na cloud.

Não assuma que artifacts (como imagens Docker ou pacotes) gerados durante o período do incidente estão limpos. A política mais segura é purgar, revisar e reconstruir a partir de fontes verificadas.

---

Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.