A superfície de ataque das contribuições a código aberto decorre do modelo de confiança específico do desenvolvimento de código aberto: contribuições de colaboradores estabelecidos recebem menos escrutínio do que as de novos colaboradores, porque a reputação funciona como indicador de confiabilidade. Esse modelo de confiança baseado em reputação cria uma vulnerabilidade na cadeia de suprimentos quando as motivações ou circunstâncias de um colaborador estabelecido mudam: quando um funcionário sai em circunstâncias conflituosas, quando uma conta é comprometida ou quando um colaborador legítimo é coagido. A confiança construída por três anos de contribuições de qualidade se estende à contribuição que carrega o backdoor, justamente porque a confiança torna menos provável uma revisão aprofundada.
A transição de ameaça interna para ameaça externa é o cenário de risco específico. Um funcionário que contribui para projetos de código aberto como parte de sua função tem uma identidade dupla: é um funcionário de confiança sujeito aos contratos de trabalho, aos processos de revisão de código e ao monitoramento de segurança da empresa, e um colaborador de código aberto de confiança cujas contribuições estão sujeitas aos padrões de revisão da comunidade de código aberto. Quando a relação de emprego termina, especialmente em circunstâncias conflituosas, como uma demissão por justa causa, os controles da empresa sobre o comportamento do ex-funcionário terminam. A reputação acumulada pelo ex-funcionário no código aberto, não.
O ataque ao XZ Utils, em março de 2024, é o exemplo real clássico. Um atacante passou cerca de dois anos construindo confiança como colaborador da biblioteca de compressão xz-utils sob um pseudônimo: enviou contribuições de qualidade, construiu relações com o mantenedor existente e acabou recebendo permissão de commit. Quando a carga do ataque foi inserida, ela foi incorporada por um mantenedor que confiava no colaborador com base em dois anos de trabalho de qualidade. A engenharia social foi paciente, sistemática e projetada especificamente para explorar o modelo de confiança baseado em reputação que torna possível a colaboração em código aberto.
Por que isso importa
O risco das contribuições a código aberto é relevante para TPRM porque as bibliotecas de código aberto sobre as quais o software dos fornecedores é construído são mantidas por colaboradores humanos cujas motivações podem mudar, e porque o modelo de confiança que torna eficiente o desenvolvimento de código aberto é também o modelo de confiança que os atacantes da cadeia de suprimentos visam especificamente. O fornecedor cujo software é construído sobre pacotes de código aberto mantidos por colaboradores confiáveis depende da confiabilidade contínua de colaboradores cujas circunstâncias o fornecedor não consegue monitorar.
- Risco das contribuições a código aberto fora do modelo de segurança da cadeia de suprimentos
- Contribuições a código aberto de ex-funcionários não monitoradas
- Revisão de PR baseada em confiança, criando vulnerabilidade a contas de colaboradores comprometidas
- Dependências de pacotes com equipes pequenas de colaboradores, aumentando a exposição ao risco interno
- Engenharia social contra mantenedores de código aberto como vetor de ataque à cadeia de suprimentos
Como é uma boa prática
Programas maduros de risco das contribuições a código aberto implementam políticas para as contribuições dos funcionários a código aberto, monitoram mudanças nas dependências críticas de código aberto, incluindo mudanças de colaboradores, e aplicam escrutínio adicional a PRs de colaboradores com mudanças recentes de conta, transferências de reputação ou padrões incomuns de contribuição.
- Política de contribuição a código aberto pelos funcionários: escopo e requisitos de revisão
- Monitoramento de colaboradores das dependências: mudanças na equipe de mantenedores de pacotes críticos
- Escrutínio adicional para colaboradores com mudança de credenciais: contas transferidas recentemente
- Detecção de padrões anômalos de contribuição: atividade incomum após um período de inatividade
- Consciência de ataques no estilo do XZ Utils: ataques pacientes à cadeia de suprimentos por engenharia social
Ferramentas
Monitoramento de Contribuições: Socket.dev para detecção de mudanças de mantenedores e colaboradores; OpenSSF Scorecard para a saúde dos mantenedores
O monitoramento de pacotes em tempo real do Socket.dev detecta mudanças nas contas de colaboradores e mantenedores, especificamente o tipo de transferência de contas e de inclusão de novos mantenedores que precede ataques à cadeia de suprimentos pelo vetor de contribuições a código aberto. O OpenSSF Scorecard fornece uma pontuação de saúde de segurança para projetos de código aberto que inclui sinais de atividade dos colaboradores e de qualidade do processo de revisão.
Desafios de governança
O desafio de governança do risco das contribuições a código aberto é a escala do monitoramento. Uma cadeia de suprimentos de software que inclui milhares de dependências transitivas não consegue monitorar manualmente todos os colaboradores de todos os pacotes. A solução de governança é o monitoramento por níveis: monitoramento abrangente de colaboradores para dependências diretas e dependências transitivas críticas, e detecção automatizada de anomalias para o restante da árvore de dependências.
- Monitore mudanças de colaboradores nas dependências diretas críticas
- Aplique o modelo do ataque ao XZ Utils à análise de padrões de contribuição
- Implemente uma política de contribuição a código aberto pelos funcionários
- Inclua o risco de contribuição na avaliação de saúde das dependências de código aberto
- Use o Socket.dev para detectar automaticamente mudanças de colaboradores
Se você faz parte de uma equipe pequena
Configure o monitoramento do Socket.dev para as suas dez dependências diretas de código aberto mais críticas. O Socket.dev alertará sobre mudanças nas contas de colaboradores, inclusões de novos mantenedores e padrões incomuns de contribuição, os sinais específicos que precedem ataques à cadeia de suprimentos pelo vetor de contribuições a código aberto. Esse monitoramento automatizado de dez pacotes leva minutos para ser configurado e oferece a capacidade de alerta antecipado cuja ausência o ataque ao XZ Utils demonstrou.
- Configure o Socket.dev para as dez dependências diretas mais críticas
- Gere alertas sobre mudanças nas contas de colaboradores e inclusões de novos mantenedores
- Implemente uma política de contribuição a código aberto pelos funcionários
- Inclua o risco de colaboradores na avaliação de saúde das dependências
O que exigir
Pergunte diretamente:
“Como vocês monitoram ataques à cadeia de suprimentos pelos canais de colaboradores das suas dependências de código aberto, especificamente o padrão de engenharia social demonstrado pelo ataque ao XZ Utils, em que um colaborador paciente constrói confiança ao longo de anos antes de inserir código malicioso?”
O que esperar como evidência
- Programa de monitoramento de colaboradores das dependências
- Detecção de padrões anômalos de contribuição
- Política de contribuição a código aberto pelos funcionários
- Consciência de ataques no estilo do XZ Utils no modelo de segurança da cadeia de suprimentos
A um fornecedor que confirma fazer a gestão de dependências de código aberto, deve-se perguntar sobre o monitoramento do risco de colaboradores. A gestão de versões das dependências trata de qual pacote é usado. O monitoramento de colaboradores trata de quem tem a confiança necessária para modificar esse pacote.
Como comprovar
- Implementação do monitoramento de colaboradores
- Detecção de contribuições anômalas
- Política de contribuição a código aberto pelos funcionários
- Risco de colaboradores na avaliação de saúde das dependências
Principal conclusão
Três anos de contribuições confiáveis. Funcionário desligado. Reputação no código aberto intacta. PR com backdoor. Incorporado com base na confiança. Catorze fornecedores afetados a jusante. A relação de emprego terminou com a revogação do acesso. A reputação no código aberto, não. O ataque ao XZ Utils demonstrou o mesmo padrão: engenharia social paciente, voltada a construir confiança e sistemática, explorando o modelo de reputação que torna possível a colaboração em código aberto. O monitoramento de mudanças de colaboradores detecta as transferências de contas e as inclusões de novos mantenedores antes do backdoor. O Socket.dev oferece detecção automatizada. A reputação que faz PRs serem incorporados é a mesma reputação que o atacante da cadeia de suprimentos constrói ao longo de anos de contribuições legítimas.