Utilizamos inteligência artificial para as traduções dos sítios e, embora nos esforcemos por garantir a exatidão, estas podem nem sempre ser 100% precisas. Agradecemos a sua compreensão.
Início/
Blogue
/
De Dune ao npm: o verme Shai-Hulud redefine...
De Dune a npm: o worm Shai-Hulud redefine o risco Supply Chain
por
OPSWAT
Partilhar esta publicação
Os fãs de Dune reconhecerão "Shai-Hulud" como o nome dado aos colossais vermes de areia que remodelam o deserto com a sua força imparável. Agora, a comunidade de código aberto enfrenta uma ameaça cibernética igualmente formidável. No dia 15 de setembro, a comunidade de software de código aberto enfrentou uma das suas crises mais perturbadoras até à data: um worm auto-replicante, conhecido como Shai-Hulud, avançou pelo ecossistema npm, comprometendo mais de 180 pacotes em poucas horas.
Bibliotecas fiáveis, tais como @ctrl/tinycolor, crowdstrike-nodejs, string-kit, json-sugar, photon-colors e bifurcações de digitado.js e data e hora já estão afectados. Com milhões de downloads por semana, as organizações estão, sem saber, a puxar infecções activas diretamente para os seus pipelines de construção.
O worm explora os ganchos do ciclo de vida do npm para roubar credenciais do GitHub e da nuvem pública e depois usa esses segredos para publicar actualizações envenenadas noutros projectos.
Fluxo de ataque
Uma versão comprometida do @ctrl/tinycolor injecta um script malicioso local (bundle.js).
O script bundle.js descarrega e executa o TruffleHog para procurar segredos do GitHub na máquina da vítima.
Usando os segredos descobertos do GitHub, o script enumera os repositórios acessíveis (proprietário, colaborador ou membro da organização).
Para cada repositório, ele busca o branch padrão, cria um shai-hulud e carrega um ficheiro de fluxo de trabalho para .github/workflows/shai-hulud-workflow.yml .
O fluxo de trabalho está configurado para ser acionado em eventos push. O executor de GitHub Actions executa o trabalho no contexto do repositório, que tem acesso aos segredos.
O fluxo de trabalho lê os segredos do GitHub e exfiltra-os para um ponto final controlado por um atacante.
Porque é que isto é importante agora e a longo prazo
O código aberto é aberto por conceção. O registo npm serve centenas de milhares de milhões de downloads todos os meses, e qualquer pessoa pode publicar um pacote. Essa abertura impulsiona a inovação, mas também cria oportunidades para os atacantes usarem a confiança em escala como arma.
O surto torna inevitável um facto: a confiança não é permanente. Um pacote que é seguro hoje pode ser comprometido amanhã.
Recomendação: Especificar versões exatas de dependência
Recomendamos vivamente que os programadores evitem instalar automaticamente a versão mais recente. Em vez disso, defina uma versão específica a instalar e reveja manualmente e actualize para versões mais recentes apenas após verificação.
As dependências declaradas com >= ou * podem obter actualizações não intencionais, incluindo versões comprometidas. Especifique uma versão precisa e revista:
"dependencies": {
"lodash": "4.17.0"
}
Actualize apenas depois de validar as novas versões quanto à autenticidade e segurança.
Agora vs. Próximo: Equilíbrio entre automatização e intervenção humana
Agora: Resposta imediata
A seguir: Resiliência a longo prazo
Automatizado: Audite as dependências do npm e examine artefatos com vários mecanismos. Humano: Os programadores fazem uma pausa nas instalações cegas e confirmam manualmente as fontes de dependência.
Automatizado: Incorporar a validação contínua de SBOM e a verificação de malware em todos os pipelines. Humano: As equipas de segurança analisam regularmente os pacotes de alto risco e fazem o escalonamento quando surgem anomalias.
Automatizado: Revogar e rodar segredos expostos. Humano: As equipas de segurança avaliam a utilização suspeita de credenciais e decidem as medidas de contenção.
Automatizado: Aplicar políticas de rotação automatizadas e predefinições de privilégios mínimos. Humano: Os executivos definem normas de governação e asseguram a responsabilidade pela confiança na cadeia de abastecimento.
Automatizado: Aplicar MFA e verificações de assinatura em CI/CD. Humano: Os líderes decidem quando abrandar a entrega para proteger a integridade.
Automatizado: Exigir commits assinados e proveniência de compilação verificável para todos os lançamentos. Humano: As direcções tratam a confiança no software como uma questão de resiliência estratégica e não como uma caixa de verificação de conformidade.
O quadro geral
Para os executivos, este ataque é um lembrete de que o risco da cadeia de fornecimento de software é um risco empresarial. As entidades reguladoras esperam controlos verificáveis e os clientes esperam provas de integridade. As direcções não podem continuar a adiar a responsabilidade pelo código que alimenta as operações críticas.
Para os profissionais, o surto mostra que as condutas devem evoluir. Todas as dependências de código aberto devem ser tratadas como não confiáveis até que se prove que são seguras. SBOMs, verificações de malware e sanitização fornecem a linha de base, mas a conscientização humana - pausa, questionamento, escalonamento - é o que impede que a automação cega importe o próximo worm.
Perspetiva da OPSWAT
Criar confiança Supply Chain
Incidentes como os ataques à cadeia de abastecimento em ambientes de código aberto, como o npm, são a prova de que as cadeias de abastecimento de software são agora cargas de trabalho críticas. A indústria tem de passar da confiança cega para a confiança verificável.
George Prichici
Vice-Presidente de Produtos, OPSWAT
Na OPSWAT, acreditamos que a confiança na cadeia de fornecimento deve ser construída, não assumida. A nossa abordagem centra-se na defesa em profundidade:
Visibilidade abrangente da cadeia de fornecimento de software com integração SBOM para acompanhar todos os componentes de software, identificar vulnerabilidades, gerir riscos ao longo do SDLC e verificar a proveniência em todas as fases.
Multiscanning com mais de 30 motores para apanhar malware polimórfico e outro malware em pacotes, especialmente em código aberto de terceiros.
CDR (Content Disarm and Reconstruction) para neutralizar os payloads maliciosos antes de serem executados.
Controlos de armazenamento e transferênciaSecure que impõem limites de confiança nos pipelines de CI/CD.
Estes controlos não se limitam a detetar o risco; higienizam ativamente os ficheiros e reforçam a confiança, reduzindo a possibilidade de incidentes como este se propagarem a jusante.
O desenvolvimento rápido e a segurança forte não são mutuamente exclusivos. As equipas de programadores precisam de fluxos de trabalho automatizados de verificação e aprovação integrados na cadeia de fornecimento de software para poderem proteger o código sem abrandar o ritmo.
George Prichici
Vice-Presidente de Produtos, OPSWAT
Segurança que acompanha o desenvolvimento
Com o OPSWAT, a segurança integra-se diretamente nos fluxos de trabalho existentes:
Integração de pipeline CI/CD - Verificações automatizadas e aplicação de políticas no Jenkins, GitHub Actions, GitLab e outros ambientes de compilação.
Verificação contínua de artefatos - Valide pacotes npm, contêineres e binários como parte das etapas de compilação de rotina.
Geração e validação de SBOMs a pedido - Produzir e verificar SBOMs automaticamente para cada versão, garantindo a proveniência sem custos adicionais.
Experiência transparente para o programador - A segurança é executada em segundo plano, revelando problemas apenas quando a intervenção é realmente necessária.
Ganchos de correção automatizados - Colocar em quarentena ou higienizar ficheiros comprometidos sem interromper as compilações.
A cultura de desenvolvimento orientada para a velocidade não precisa de entrar em conflito com a validação de segurança necessária; os fluxos de trabalho de verificação e aprovação automatizados devem ser uma obrigação, com um impacto mínimo na velocidade de desenvolvimento.
Ao incorporar essas capacidades no ciclo de vida do software, OPSWAT ajuda as organizações a alcançar tanto a velocidade de desenvolvimento quanto a confiança verificável, que é um equilíbrio que o incidente do npm prova ser agora essencial.
O worm npm Shai-Hulud é um sinal claro das ameaças que afectam o software atualmente. Os atacantes não precisam de invadir a sua base de código. Eles podem persuadi-lo a instalá-los. Verifique cada artefato, incorpore resiliência em cada estágio e capacite as pessoas a agir quando a automação por si só não for suficiente. As organizações que levarem isto a sério agora definirão o futuro das cadeias de fornecimento de software seguras.
Pronto para proteger a sua cadeia de fornecimento de software das mais recentes ameaças informáticas com soluções personalizadas e perfeitamente integradas?
