Supply Chain Attack – Data 23/05/2026

21 views
4 mins read

Sobre o ataque

Mais um alerta sério de Supply Chain Attack atingindo o ecossistema open source.

Mais de 700 repositórios no GitHub foram sinalizados após a descoberta de scripts maliciosos inseridos em projetos PHP e Node.js. O malware era executado silenciosamente durante a instalação de dependências, baixando uma carga Linux do GitHub, salvando como /tmp/.sshd para parecer um arquivo legítimo do sistema e executando em background.

O ponto mais preocupante: o código malicioso foi escondido em package.json em vez de composer.json, explorando justamente o fato de muitos desenvolvedores PHP revisarem apenas arquivos PHP/Composer e ignorarem JavaScript dentro do projeto.

Pacotes afetados no Packagist incluíram templates Laravel populares como:

  1. Laravel templates devdojo/wave
  2. devdojo/genesis
  3. A mesma carga foi encontrada em pipelines de CI/CD via GitHub Actions usando um passo falso chamado "Dependency Cache Sync".

Indicadores observados:

  1. Conta GitHub: parikhpreyash4
  2. Repositório: systemd-network-helper-aa5c751f
  3. Drop path: /tmp/.sshd
  4. Comandos: curl -skL e chmod +x /tmp/.sshd

Esse caso reforça alguns pontos:

  1. Supply chain security não é mais opcional.
  2. Hoje, revisar apenas o código da aplicação já não é suficiente, porque o risco moderno muitas vezes está escondido nas dependências, pipelines CI/CD, GitHub Actions, scripts pós-instalação e componentes automatizados que fazem parte do processo de build.
  3. Um único pacote comprometido pode transformar um ambiente inteiro em ponto de entrada para exfiltração de secrets, execução remota de código e comprometimento de infraestrutura corporativa.
  4. Segurança moderna exige visibilidade contínua sobre todo o ecossistema de desenvolvimento, não apenas sobre a aplicação final.

Também é necessário validar:

  • dependências transitivas;
  • GitHub Actions;
  • scripts pós-instalação;
  • pipelines CI/CD;
  • auto-updates (dev-main, dev-master);
  • artefatos baixados em runtime;
  • egress filtering em runners;
  • pinagem de actions por SHA;
  • allowlists de rede;
  • detecção de exfiltração.

A superfície de ataque moderna está cada vez mais migrando para o ecossistema de build e automação. Pipelines CI/CD, runners, dependências open source, scripts de instalação e workflows automatizados deixaram de ser apenas mecanismos de produtividade e passaram a ser componentes críticos de segurança. Do ponto de vista de governança, esse tipo de incidente se conecta diretamente a controles de supply chain, gestão de vulnerabilidades, configuração segura, monitoramento contínuo, proteção contra malware, DLP e segurança de rede.

Falarei de alguns abaixo


Controles

📘 ISO/IEC 27001:2022

A.5.21:Managing information security in the ICT supply chain: Esse controle trata diretamente da gestão de riscos associados à cadeia de suprimentos de TIC. Ele ajuda a justificar processos formais para avaliação de dependências open source, revisão de fornecedores, validação de componentes externos e monitoramento contínuo de bibliotecas utilizadas em pipelines CI/CD. Em ataques como esse, fica evidente que a cadeia de build também precisa ser tratada como ativo crítico de segurança.

A.8.8:Management of technical vulnerabilities: Esse controle cobre identificação, avaliação e tratamento de vulnerabilidades técnicas. Na prática, ele suporta iniciativas como Software Composition Analysis (SCA), monitoramento de CVEs em dependências npm/composer e revisão contínua de pacotes utilizados em aplicações. Também fortalece a necessidade de processos rápidos de resposta quando bibliotecas comprometidas são descobertas.

A.8.9:Configuration management: Muito relevante para ambientes DevSecOps modernos. Esse controle ajuda a estabelecer padrões seguros para pipelines CI/CD, incluindo pinagem de GitHub Actions por commit SHA, proibição de versões mutáveis como latest/dev-main e gerenciamento seguro de configurações automatizadas. Em supply chain attacks, configurações inseguras frequentemente ampliam o impacto do comprometimento.

A.8.20:Network security: Aplicável para controles de egress filtering, allowlists de rede, proxies outbound e inspeção de tráfego em runners de CI/CD. O malware identificado utilizava comandos como curl -skL para baixar payloads externos, o que reforça a importância de restringir comunicações de saída em ambientes automatizados. Hoje, pipelines precisam ser tratados quase como workloads críticos de produção.

A.8.12:Data leakage prevention: Supply chain attacks frequentemente têm como objetivo roubo de secrets, tokens cloud, credenciais CI/CD e variáveis de ambiente. Esse controle ajuda a justificar mecanismos de DLP, proteção de secrets, segmentação de acesso e monitoramento de exfiltração. O impacto potencial vai muito além da estação do desenvolvedor atingindo cloud, produção e ambientes corporativos.


📙 NIST Cybersecurity Framework (CSF 2.0)

GV.SC:Cybersecurity Supply Chain Risk Management: Talvez a categoria mais importante para esse cenário. Ela estabelece práticas de governança para gerenciamento de riscos associados à cadeia de suprimentos digital, incluindo software de terceiros, bibliotecas open source, automações e fornecedores externos. O foco não é apenas proteger a empresa internamente, mas entender que o ecossistema inteiro também pode se tornar vetor de ataque.

PR.PS:Platform Security: Relaciona-se diretamente ao hardening de plataformas CI/CD, isolamento de runners, execução restrita de containers e proteção da infraestrutura de build. O incidente demonstra que ambientes automatizados hoje possuem alto valor estratégico para atacantes. Um pipeline inseguro pode se transformar rapidamente em ponto inicial de comprometimento corporativo.

DE.CM:Continuous Monitoring: Esse controle enfatiza monitoramento contínuo de ativos, workloads e atividades suspeitas. Em ambientes DevSecOps, isso significa observar criação de processos anômalos, downloads inesperados, execução de binários em /tmp e comportamento fora do padrão em pipelines. Sem visibilidade operacional, muitos supply chain attacks passam despercebidos durante semanas.


📗 NIST SP 800-53

SA-12:Supply Chain Protection: Controle extremamente forte para proteção da cadeia de suprimentos. Ele cobre validação de software, avaliação de fornecedores, integridade de componentes e mitigação de riscos associados a terceiros. É praticamente um controle obrigatório para organizações que dependem fortemente de open source e automação CI/CD.

SI-7:Software, Firmware, and Information Integrity: Focado em garantir integridade de software e detectar adulterações. Ele suporta validação de artefatos, assinatura de componentes, verificação de integridade e detecção de modificações maliciosas em pipelines e dependências. Casos como esse mostram como adulterações pequenas podem gerar impactos massivos.

SC-7:Boundary Protection: Muito relevante para segmentação de rede e controle de tráfego de entrada e saída. Esse controle fortalece o uso de firewalls, proxies, inspeção de comunicação e políticas restritivas em servidores de build. Mesmo que um pacote seja comprometido, limitar sua capacidade de comunicação pode reduzir drasticamente o impacto do ataque.

Sou um profissional apaixonado pela área de Segurança da Informação. Sou certificado em ISO 27001, ISO 27005, LGPD e GDPR, o que me torna um Data Protection Officer (DPO) certificado. Também sou certificado CC e SSCP pelo (ISC)², bem como um AWS Practitioner. Além do meu trabalho, sou um orgulhoso pai de três filhos, um nerd, um cinéfilo, um leitor voraz e um eterno aprendiz.

Deixe um comentário

Your email address will not be published.

Previous Story

JavaScript Recon + Secret Hunting

Latest from News

Zabbix SQLi

Introdução Zabbix é uma ferramenta de monitoramento de rede amplamente utilizada em infraestruturas de TI corporativas