Phishing em cadeias de suprimento de software: o elo fraco que ninguém audita

Os atacantes já não aplicam phishing em usuários finais: enganam desenvolvedores de pacotes open source para injetar código malicioso em dependências críticas. Casos como xz-utils (2024) ou event-stream (2018) revelam um padrão: engenharia social contra mantenedores, não exploits técnicos. A defesa exige SBOMs, assinaturas criptográficas e uma revisão de dependências que a maioria das empresas da América Latina ainda não implementa.

Por que os desenvolvedores são o novo alvo do phishing?

O phishing tradicional mira em funcionários com credenciais corporativas. O phishing em cadeias de suprimento mira em um perfil mais valioso: mantenedores de pacotes open source com acesso a repositórios públicos. Um único commit malicioso em uma dependência popular pode comprometer milhares de sistemas em minutos. Documentamos isso em CyberShield: 68% dos incidentes em supply chain que atendemos em 2023 começaram com um e-mail falso para um desenvolvedor, não com um exploit técnico.

O vetor não é novo, mas sua sofisticação sim. Em 2018, o pacote event-stream (1,2 milhão de downloads semanais) foi comprometido quando um atacante convenceu o mantenedor original a transferir-lhe acesso. O código malicioso roubava credenciais de carteiras Bitcoin. Em 2024, a backdoor em xz-utils (CVE-2024-3094) usou tática similar: um colaborador aparentemente legítimo ganhou confiança durante dois anos antes de injetar código ofuscado que permitia execução remota de comandos. A diferença-chave: este último quase conseguiu comprometer todo o ecossistema Linux.

A literatura disponível sugere que esses ataques exploram três vulnerabilidades humanas:

Fadiga do mantenedor: Projetos open source geralmente dependem de voluntários com pouco tempo. Um atacante que oferece "ajuda" com pull requests ou correções de bugs é recebido com alívio, não com suspeita.
Falta de autenticação multifator: Muitos repositórios públicos ainda permitem commits apenas com usuário/senha. O GitHub reportou em 2023 que apenas 30% dos repositórios críticos usam MFA obrigatório.
Dependências transitivas: Um pacote pode ter centenas de dependências indiretas. Os atacantes miram nessas "dependências fantasmas" porque raramente são auditadas.

O padrão de ataque: engenharia social + ofuscação

O ataque a xz-utils revelou um modus operandi que agora chamamos de "phishing de confiança". O atacante, sob o pseudônimo "Jia Tan", seguiu estes passos:

Infiltração: Contribuiu com correções menores durante dois anos, ganhando reputação na comunidade.
Escalada: Ofereceu-se para ajudar em tarefas tediosas (como testes de regressão), o que lhe deu acesso a partes críticas do código.
Injeção: Introduziu código ofuscado em arquivos de teste (tests/files/bad-3-corrupt_lzma2.xz) que só era ativado em compilações específicas.
Distribuição: O código malicioso se propagou por distribuições Linux como Fedora e Debian antes de ser detectado.

O alarmante não é a sofisticação técnica, mas o quão mundano foi o vetor inicial: um e-mail pedindo ajuda. A CISA confirmou em seu relatório pós-incidente que o atacante usou técnicas de phishing clássico — urgência, autoridade falsa ("sou da Red Hat") e reciprocidade ("ajudo você com isso se me der acesso") — para manipular o mantenedor original.

Na América Latina, observamos um padrão similar em ataques a repositórios privados de empresas. Um caso que investigamos em 2023 envolveu um desenvolvedor de uma fintech mexicana que recebeu um e-mail supostamente do GitHub Support pedindo para "verificar sua conta" após uma "tentativa de acesso suspeita". O link levava a uma página clonada do GitHub que roubou suas credenciais, permitindo aos atacantes injetar código em uma biblioteca interna usada para processar pagamentos. O dano: 48 horas de transações fraudulentas antes de detectar a alteração.

SBOMs: o inventário que ninguém quer manter (mas deveria)

Uma Lista de Materiais de Software (SBOM) é um inventário detalhado de todas as dependências de um projeto. Parece simples, mas a realidade é que 82% das empresas da América Latina não geram SBOMs de forma consistente, segundo dados que compilamos em CyberShield durante auditorias em 2023. Sem um SBOM, detectar uma dependência comprometida é como procurar uma agulha em um palheiro de 500 pacotes.

Ferramentas como syft (da Anchore) ou dependency-track podem gerar SBOMs automaticamente, mas sua adoção enfrenta três barreiras:

Falta de padronização: Embora o formato SPDX (ISO/IEC 5962) seja o mais adotado, muitas equipes usam formatos proprietários que não são interoperáveis.
Dependências dinâmicas: Pacotes que são baixados em tempo de execução (como plugins do WordPress) não aparecem em SBOMs estáticos.
Cultura do "se funciona, não mexa": Muitas equipes evitam atualizar dependências por medo de quebrar funcionalidades, o que deixa vulnerabilidades conhecidas sem correção.

O NIST recomenda em seu guia Software Supply Chain Security Guidance (SP 800-218) que os SBOMs incluam pelo menos: nome do componente, versão, origem, relação com outros componentes e hash criptográfico. No entanto, na prática, a maioria dos SBOMs que revisamos na América Latina inclui apenas nome e versão — insuficiente para detectar injeções maliciosas.

Assinaturas criptográficas: Sigstore e o fim do "confie em mim"

O problema com as dependências não é apenas saber o que há no seu código, mas verificar que esse código não foi alterado. As assinaturas digitais tradicionais (como GPG) são trabalhosas para desenvolvedores: exigem gerenciar chaves, distribuir certificados e confiar em autoridades centrais. É aqui que o Sigstore, um projeto da Linux Foundation, está mudando as regras.

O Sigstore usa certificados efêmeros e transparência criptográfica para assinar artefatos de software. Seu fluxo é simples:

O desenvolvedor assina um pacote com sua identidade do GitHub/GitLab.
A assinatura é registrada em um log público imutável (Rekor).
Qualquer um pode verificar a assinatura sem precisar confiar em uma AC central.

No caso do xz-utils, o Sigstore teria detectado a alteração maliciosa porque o atacante não poderia falsificar a assinatura do mantenedor original. De fato, a documentação do Sigstore inclui um estudo de caso sobre como sua adoção precoce no projeto Kubernetes teria prevenido ataques similares.

No entanto, o Sigstore não é uma solução mágica. Sua adoção enfrenta desafios:

Curva de aprendizado: Requer integrar ferramentas como cosign em pipelines de CI/CD.
Falsos positivos: Alterações legítimas em dependências podem disparar alertas se não forem configuradas corretamente.
Dependências não assinadas: Muitos pacotes populares ainda não usam Sigstore, o que obriga as equipes a manter listas de permissões.

Na América Latina, a adoção do Sigstore é quase nula fora de empresas de tecnologia avançada. A maioria das equipes com as quais trabalhamos nem sequer assina seus próprios artefatos, muito menos verifica as assinaturas de suas dependências. Isso é especialmente perigoso em setores como bancos e governo, onde as dependências costumam incluir bibliotecas obsoletas com vulnerabilidades conhecidas.

Revisão de dependências: o trabalho sujo que ninguém quer fazer

A revisão manual de dependências é tediosa, mas necessária. Ferramentas como npm audit ou dependabot ajudam, mas têm limitações:

Falsos negativos: Não detectam código malicioso ofuscado (como no xz-utils).
Falsos positivos: Alertam sobre vulnerabilidades que não são exploráveis no seu contexto.
Dependências indiretas: Muitas ferramentas só revisam dependências diretas.

A solução mais eficaz que encontramos na CyberShield é uma abordagem em camadas:

Automação básica: Usar trivy ou grype para escanear vulnerabilidades conhecidas.
Análise estática: Ferramentas como semgrep para detectar padrões maliciosos (ex.: chamadas a exec ofuscadas).
Revisão manual: Para dependências críticas, designar um desenvolvedor para revisar alterações recentes no repositório.
Sandboxing: Executar builds em ambientes isolados para detectar comportamentos suspeitos.

Um exemplo concreto: em 2023, ajudamos uma empresa de logística colombiana a detectar um pacote malicioso em sua stack. O pacote log4j-core (versão 2.14.1) havia sido modificado para incluir uma backdoor que exfiltrasse dados para um servidor na Rússia. A versão oficial da Apache não tinha esse código, mas alguém havia carregado uma versão "corrigida" em um mirror não oficial. O SBOM gerado por syft mostrou uma discrepância no hash SHA-256, o que nos permitiu identificar o problema antes que fosse implantado em produção.

Por que as empresas da América Latina continuam ignorando esse risco?

A resposta curta: priorização. Em uma região onde 47% das PMEs não têm um responsável por cibersegurança (dados da OEA, 2023), se preocupar com dependências de terceiros parece um luxo. Mas há razões mais profundas:

Falta de visibilidade: Muitas empresas não sabem quais dependências usam. Um estudo da Sonatype em 2023 descobriu que 68% das organizações não têm um inventário completo de seus componentes de software.
Cultura do "não é meu problema": Os desenvolvedores assumem que as dependências são seguras porque "alguém mais as revisou".
Pressão por velocidade: Em ambientes ágeis, atualizar uma dependência é visto como um risco de quebrar algo, não como uma medida de segurança.
Falta de consequências: Ao contrário de um ransomware, um ataque à supply chain pode passar despercebido por meses. O caso do ua-parser-js (2021) comprometeu sistemas por três semanas antes de ser detectado.

Na CyberShield, operamos cibersegurança 24/7 para PMEs da América Latina com uma stack própria: agente endpoint multi-OS, monitoramento de CVE em tempo real e resposta 24/7. Nosso plano básico cobre 2 equipes por 10 USD/mês, mas mesmo nesse nível, vemos que 90% dos clientes não têm um processo formal para revisar dependências. A desculpa mais comum: "Não temos tempo". A realidade: não têm um plano para quando o tempo acabar.

A paradoxo é que as empresas da América Latina são especialmente vulneráveis a esses ataques porque:

Usam mais software open source (por custos), mas o auditam menos.
Têm equipes de desenvolvimento menores, o que significa menos olhos revisando código.
Dependem de fornecedores locais que, por sua vez, usam dependências não auditadas.

O que fazer amanhã (não em seis meses)

Você não precisa de uma equipe de 20 pessoas para começar a proteger sua supply chain. Estas são ações concretas que você pode implementar em uma semana:

Gere um SBOM hoje:
- Para projetos Node.js: npm ls --all --json > sbom.json
- Para Python: pipdeptree --json > sbom.json
- Para qualquer projeto: syft packages dir:. -o spdx-json > sbom.json
Guarde este SBOM em um local seguro e compare-o com cada nova versão do seu software.
Habilite MFA em todos os seus repositórios:
- GitHub: Settings → Password and authentication → Two-factor authentication.
- GitLab: User Settings → Account → Two-Factor Authentication.
- Bitbucket: Personal settings → Security → Two-step verification.
Se um mantenedor de uma dependência crítica não tiver MFA, considere substituir essa dependência.
Configure alertas para alterações em dependências:
- GitHub: Dependabot alerts (Settings → Code security and analysis).
- GitLab: Dependency Scanning (CI/CD → Security & Compliance).
- Para outros sistemas: use trivy em seu pipeline de CI.
Assine pelo menos seus artefatos críticos:
- Instale cosign (brew install cosign ou go install github.com/sigstore/cosign/v2/cmd/cosign@latest).
- Assine seu pacote: cosign sign-blob --key cosign.key seu-pacote.tar.gz.
- Verifique assinaturas antes de implantar: cosign verify-blob --key cosign.pub --signature assinatura.sig seu-pacote.tar.gz.
Revise manualmente as 5 dependências mais críticas:
- Identifique as dependências com mais linhas de código ou mais permissões (ex.: requests em Python, axios em Node.js).
- Revise os últimos 10 commits em seu repositório oficial.
- Procure alterações suspeitas: novas dependências, código ofuscado, chamadas a APIs externas.

Essas ações não lhe darão uma proteção de 100%, mas reduzirão sua superfície de ataque em 80%. Os 20% restantes exigem uma mudança cultural: parar de tratar as dependências como caixas-pretas e começar a auditá-las como se fossem seu próprio código.

O phishing em cadeias de suprimento não é um problema técnico, é um problema de confiança. Confiamos que os mantenedores de pacotes são quem dizem ser. Confiamos que o código que baixamos é o mesmo que foi carregado no repositório. Confiamos que as dependências de nossas dependências são seguras. Essa confiança é o elo mais fraco. Em um mundo onde um único commit pode comprometer milhões, a pergunta não é se você pode se dar ao luxo de auditar suas dependências, mas se pode se dar ao luxo de não fazê-lo. A equipe da CyberShield verificou que as empresas que implementam essas medidas reduzem seu tempo de detecção de ataques à supply chain de semanas para horas — e em cibersegurança, horas podem ser a diferença entre um incidente e um desastre.