Os registros públicos de pacotes (npm, PyPI, Maven Central, NuGet) operam com um modelo de confiança que cria uma vulnerabilidade específica e subestimada na cadeia de suprimentos: depois que um pacote se estabelece como legítimo e amplamente usado, a confiança associada a ele se estende a todas as versões futuras publicadas por quem controlar a conta de publicação naquele momento. Um pacote criado por um desenvolvedor confiável em 2019, baixado milhões de vezes e validado por milhares de desenvolvedores ao longo de anos de uso pode se tornar um vetor de distribuição de código malicioso em 2024 se a conta que publica novas versões for comprometida ou transferida para um agente mal-intencionado.
O mecanismo de tomada de conta é a ameaça mais direta. As contas em registros de pacotes podem ser comprometidas por roubo de credenciais, phishing ou engenharia social direcionada ao mantenedor do pacote, exatamente como qualquer conta pode ser comprometida. O repositório no GitHub do pacote event-stream, um pacote npm amplamente usado, foi comprometido por um ataque de engenharia social em que o desenvolvedor original, sobrecarregado com a manutenção, transferiu a titularidade para um agente mal-intencionado que publicou uma versão com porta dos fundos. A versão maliciosa foi baixada 8 milhões de vezes antes de o ataque ser descoberto.
A vulnerabilidade da sucessão de mantenedores é o risco mais sutil. Os pacotes de código aberto são frequentemente mantidos por desenvolvedores individuais que, com o tempo, podem ficar indisponíveis, esgotados ou dispostos a transferir a responsabilidade pela manutenção. Quando um pacote é transferido para um novo mantenedor, especialmente um novo mantenedor sem reputação estabelecida na comunidade de código aberto, a confiança conquistada pelo pacote é herdada por alguém cujo código não passou pelo mesmo escrutínio que deu ao mantenedor original sua reputação. Basta uma única atualização de versão feita por um novo mantenedor para entregar código malicioso a todos que confiam no pacote.
Por que isso importa
O modelo de confiança dos registros de pacotes é importante para TPRM porque os produtos de software dos seus fornecedores são construídos sobre pacotes cuja confiabilidade depende não de sua legitimidade passada, mas da segurança atual das contas de seus mantenedores. Um fornecedor que não implementou controles contra a tomada de contas, que não monitora mudanças inesperadas de mantenedor em suas dependências e que não verifica a legitimidade das atualizações de versão secundária antes de incorporá-las está exposto ao comprometimento da cadeia de suprimentos por um vetor que a varredura de vulnerabilidades de SCA não aborda.
- Legitimidade do pacote aceita como propriedade estática: mantenedor comprometido não detectável por CVE
- Segurança das contas dos mantenedores não avaliada na revisão de pacotes do fornecedor
- Mudanças repentinas de mantenedor nas dependências não monitoradas
- Atualizações de versão secundária não sujeitas à mesma revisão que as dependências principais
- Risco de tomada de conta na cadeia de suprimentos ausente do modelo de segurança do fornecedor
Como é uma boa prática
Programas maduros de confiança em registros de pacotes implementam monitoramento contínuo de mudanças de mantenedor nas dependências críticas, exigem autenticação multifator nas contas de publicação de pacotes, fixam as dependências em versões específicas com verificação de hash e revisam as alterações de código nas atualizações de versão secundária antes de incorporá-las à produção.
- Fixação de dependências: especificação exata de versão e hash que impede atualizações inesperadas
- Monitoramento de mudanças de mantenedor: alertas sobre mudanças de titularidade em pacotes críticos
- Exigência de MFA nas contas de publicação: proteção das contas do lado do fornecedor
- Revisão de atualizações de versão secundária: revisão das diferenças de código antes de incorporar as atualizações
- Uso obrigatório de arquivos de bloqueio de dependências: impede a resolução de dependências para versões inesperadas
Ferramentas
Monitoramento de registros: Socket.dev para detecção de mudanças de mantenedor; Snyk para monitoramento de atualizações de dependências
O Socket.dev oferece monitoramento em tempo real de sinais de risco da cadeia de suprimentos em registros de pacotes, incluindo mudanças nas contas de mantenedores, novas contas de publicação e alterações de código suspeitas em atualizações de pacotes. Para profissionais de TPRM, perguntar se os fornecedores monitoram mudanças de mantenedor em suas dependências críticas com ferramentas como o Socket.dev é uma pergunta específica sobre a defesa contra a tomada de contas.
Segurança da publicação de pacotes: exigência de autenticação de dois fatores no npm; exigência de TOTP para publicação no PyPI
As proteções de publicação nos registros de pacotes (exigência de MFA, rotação de tokens de publicação e controles de acesso) reduzem o risco de tomada de contas. Para profissionais de TPRM, perguntar se as contas de publicação de pacotes do fornecedor usam MFA e tokens específicos de publicação, em vez de senhas de conta, é uma pergunta específica sobre a segurança das contas dos mantenedores.
Desafios de governança
O desafio de governança da confiança em registros de pacotes é o problema do volume de dependências. Um projeto de software moderno pode ter milhares de dependências transitivas, cada uma com suas próprias contas de mantenedores. O monitoramento contínuo de mudanças de mantenedor em todas as dependências só é viável com ferramentas automatizadas. A solução de governança é o monitoramento por níveis: monitoramento abrangente das dependências diretas e das dependências transitivas de uso intenso, e detecção automatizada de anomalias para o restante da árvore de dependências.
- Implementar a fixação de dependências e o uso obrigatório de arquivos de bloqueio
- Monitorar mudanças de mantenedor nas dependências diretas críticas
- Exigir MFA em todas as contas de publicação de pacotes: proteção das contas do lado do fornecedor
- Revisar as alterações de código nas atualizações de versão secundária das dependências críticas
- Incluir a segurança das contas dos mantenedores na avaliação da cadeia de suprimentos de software dos fornecedores
Se você faz parte de uma equipe pequena
Torne obrigatório o uso de arquivos de bloqueio nas suas aplicações de produção: npm ci em vez de npm install, pip install com hashes de requisitos ou o equivalente no ecossistema da sua linguagem. Isso impede mudanças inesperadas de versão de pacotes mesmo que a conta de um mantenedor seja comprometida e uma nova versão seja publicada. Em seguida, configure o Socket.dev ou um monitoramento equivalente nas suas dependências diretas para alertá-lo quando a titularidade de um mantenedor mudar. Esses dois controles tratam os modos de falha mais críticos da confiança em registros.
- Tornar obrigatório o uso de arquivos de bloqueio nas aplicações de produção
- Configurar o monitoramento de mudanças de mantenedor nas dependências diretas
- Exigir MFA em todas as contas internas de publicação de pacotes
- Revisar as alterações de código nas atualizações de versão secundária dos pacotes críticos
O que exigir
Pergunte diretamente:
“Vocês monitoram suas dependências críticas para detectar mudanças inesperadas de mantenedor, e suas contas de publicação de pacotes usam MFA e tokens específicos de publicação? E como vocês verificam a integridade das atualizações de versão secundária antes de incorporá-las à sua compilação?”
O que esperar como evidência
- Implementação do monitoramento de mudanças de mantenedor
- MFA nas contas de publicação de pacotes
- Fixação de dependências e uso obrigatório de arquivos de bloqueio
- Processo de revisão de atualizações de versão secundária
Um fornecedor que confirma a gestão de dependências deve ser questionado sobre a segurança das contas dos mantenedores e o monitoramento de mudanças. A gestão de dependências cobre quais versões são usadas. A segurança das contas dos mantenedores determina se essas versões podem ser comprometidas sem que nenhuma vulnerabilidade seja explorada.
Como comprovar
- Registros de monitoramento de mudanças de mantenedor
- Exigência de MFA nas contas de publicação
- Implementação do uso obrigatório de arquivos de bloqueio
- Processo de revisão de atualizações de versão secundária
Principal conclusão
Pacote: legítimo, bem avaliado, 14,000 downloads semanais. Mantenedor: o desenvolvedor original transferiu a titularidade após um ataque de engenharia social. Novo mantenedor: publicou uma correção de erro com código de coleta de credenciais. Desenvolvedor da empresa: instalou a nova versão, verificou o README, verificou o número de downloads, verificou o GitHub. Não verificou o histórico do mantenedor. Não verificou as diferenças de código da nova versão. Pacote válido. Mantenedor comprometido. Atualização maliciosa. O uso obrigatório de arquivos de bloqueio teria impedido a adoção automática da nova versão. O monitoramento de mudanças de mantenedor teria sinalizado a transferência de titularidade. A MFA na conta original teria impedido o sucesso da engenharia social. Três controles para o mesmo modelo de ameaça.