Boas práticas Well-Architected para segurança da cadeia de suprimentos de software

Ataques recentes à cadeia de suprimentos e por que isso importa

Desde setembro, diversos ataques notáveis à cadeia de suprimentos de software foram registrados no npm Registry: Shai-Hulud, Chalk/Debug, um abuso de tokens do tea.xyz e, mais recentemente, o axios. Graças a esforços da comunidade envolvendo a equipe do Amazon Inspector, a Open Source Security Foundation e outros colaboradores, os pacotes afetados foram rapidamente identificados, reduzindo o impacto desses incidentes.

Ataques como o Shai-Hulud exploram vulnerabilidades em duas frentes: contas de mantenedores comprometidas que publicam pacotes maliciosos e ambientes de consumidores que baixam e executam esses pacotes. O ataque Shai-Hulud teve sucesso porque credenciais de mantenedores foram comprometidas via phishing, permitindo que agentes de ameaça publicassem versões maliciosas de pacotes populares.

Incidentes como esses reforçam a necessidade de práticas de segurança robustas na cadeia de suprimentos de software. A defesa eficaz exige abordar ambos os lados: mantenedores de pacotes precisam de proteções que previnam comprometimento de contas e limitem a propagação quando credenciais são roubadas; consumidores de pacotes precisam de defesas em camadas que detectem pacotes maliciosos, impeçam sua implantação e limitem danos quando um comprometimento ocorre.

A AWS publicou um guia detalhado com boas práticas focadas em consumidores de pacotes, alinhadas ao AWS Well-Architected Framework – Pilar de Segurança. Vamos explorar essas práticas nesta releitura.

Usar credenciais temporárias e conceder privilégio mínimo

Quando o Shai-Hulud foi executado em ambientes de desenvolvimento e pipelines de Integração e Entrega Contínua (CI/CD), ele escaneou segredos como tokens npm, tokens GitHub e chaves de acesso do AWS Identity and Access Management (IAM). Credenciais de longa duração expostas dessa forma permitiram que agentes de ameaça propagassem o malware e acessassem recursos em nuvem.

Incidentes recentes mostraram organizações descobrindo múltiplos pares de credenciais IAM vazados, com preocupações sobre credenciais adicionais expostas e potencial comprometimento de pipelines CI/CD.

A remoção de credenciais de longa duração dos ambientes de desenvolvimento e pipelines CI/CD reduz o escopo de exposição caso um sistema seja comprometido. Para desenvolvedores trabalhando localmente, o novo comando de login da AWS CLI (aws login) simplifica a aquisição de credenciais CLI de curta duração e elimina a necessidade de armazenar credenciais de longa duração em arquivos de configuração. O AWS IAM Identity Center também oferece uma forma direta de adquirir credenciais temporárias que expiram automaticamente.

Para pipelines CI/CD, a federação via OpenID Connect (OIDC) com GitHub Actions, GitLab CI ou outras plataformas fornece credenciais temporárias para cada job sem armazenar tokens de longa duração. O IAM também pode federar identidades AWS para serviços externos, permitindo que workloads na AWS acessem serviços externos de forma segura sem credenciais de longo prazo.

Credenciais temporárias expiram automaticamente, limitando a janela de exposição caso um pipeline seja comprometido. Para serviços de terceiros que não suportam credenciais temporárias, a recomendação é armazenar as credenciais em um serviço centralizado como o AWS Secrets Manager ou o AWS Systems Manager Parameter Store, limitando o acesso a esses segredos, exigindo credenciais temporárias e aplicando rotação automática com registro de auditoria.

Resumo das recomendações para reduzir risco de exposição de credenciais

• Usar credenciais temporárias: Federar usuários de um provedor de identidade central para a AWS e usar IAM roles para acesso. SEC02-BP02: Usar credenciais temporárias.
• Conceder privilégio mínimo: Atribuir apenas as permissões mínimas necessárias e usar elevação temporária de permissões quando necessário. SEC03-BP02: Conceder acesso com privilégio mínimo.
• Auditar e rotacionar credenciais de longa duração quando necessárias para casos de uso específicos. SEC02-BP05: Auditar e rotacionar credenciais periodicamente.

Em caso de incidente de segurança onde credenciais possam ter sido expostas, a orientação é rotacionar imediatamente todas as credenciais de longa duração. Utilizar o Amazon GuardDuty e o AWS CloudTrail para detectar atividade IAM anômala e identificar quais credenciais podem ter sido comprometidas.

Implementar defesa em profundidade

Mesmo com credenciais temporárias e privilégio mínimo, uma única conta comprometida pode permitir que agentes de ameaça publiquem pacotes maliciosos ou acessem recursos sensíveis. A defesa em profundidade cria múltiplas camadas de proteção que trabalham juntas para prevenir a propagação após o comprometimento inicial.

O princípio-chave é garantir que, se uma credencial ou conta for comprometida, controles adicionais impeçam que esse comprometimento se espalhe pela organização. Isso inclui Autenticação Multifator (MFA) para acesso combinada com diferentes IAM roles para workloads sensíveis.

Para projetos open source de desenvolvedor único, o MFA se torna ainda mais crítico porque não há separação de funções através de múltiplos mantenedores. Em ambientes de equipe, exigir múltiplos aprovadores para liberar pacotes para produção cria separação de funções. A aprovação multi-parte deve ser implementada dentro do próprio pipeline para implantações sensíveis — garantindo que mesmo se credenciais de um desenvolvedor forem comprometidas e ele disparar um deploy, o pipeline exija aprovação adicional antes de liberar para produção.

Para consumidores de pacotes, fluxos de aprovação múltipla em pipelines de implantação ajudam a garantir que, se um pacote malicioso passar pela varredura inicial, a revisão humana possa identificar mudanças suspeitas antes da implantação em produção.

Assinatura de artefatos como parte da defesa em profundidade

A assinatura de artefatos fornece uma camada criptográfica complementar que funciona junto com os controles de processo. O ataque Shai-Hulud teve sucesso porque credenciais comprometidas de mantenedores permitiram publicar pacotes maliciosos diretamente no registro npm público. Para consumidores de pacotes, a defesa é garantir que pacotes obtidos de registros públicos não alcancem produção sem verificação.

Ao vincular criptograficamente um pacote ou imagem de contêiner à identidade que o produziu, a assinatura cria uma camada de verificação independente da credencial usada para disparar o build — significando que uma credencial de desenvolvedor comprometida sozinha não é suficiente para introduzir um artefato não verificado no pipeline de implantação.

O AWS Signer fornece assinatura criptográfica para pacotes, criando uma camada adicional de verificação. O modelo de autorização de assinatura separa responsabilidades: credenciais de desenvolvedor não devem ter permissões de assinatura. Apenas roles de pipeline CI/CD devem ter permissões de assinatura através da API signer:StartSigningJob. O Signer usa Módulos de Segurança de Hardware (HSMs) validados FIPS 140-3 Nível 3 para armazenar chaves de assinatura.

O fluxo de assinatura de imagens de contêiner funciona da seguinte forma:

• O desenvolvedor ou pipeline CI/CD constrói uma imagem de contêiner e envia para o Amazon Elastic Container Registry (Amazon ECR)
• Com a assinatura gerenciada do Amazon ECR (nova funcionalidade), o ECR dispara automaticamente a assinatura quando a imagem é enviada
• O Amazon ECR chama o Signer com o digest da imagem e o perfil de assinatura
• O Signer verifica as permissões do perfil e assina o digest usando chaves armazenadas em HSMs validados FIPS 140-3 Nível 3
• A assinatura é armazenada junto à imagem no Amazon ECR usando formato de artefato OCI (Open Container Initiative)
• No momento da implantação, controladores de admissão (Kyverno para Amazon EKS, lifecycle hooks para Amazon ECS) verificam assinaturas antes de permitir a implantação

Os benefícios do Signer em comparação com a construção de infraestrutura de assinatura personalizada incluem:

• Totalmente gerenciado: Sem necessidade de construir infraestrutura customizada ou gerenciar ciclo de vida de certificados
• Automatizado: A assinatura gerenciada do ECR acontece automaticamente no push da imagem sem etapas manuais
• Governança centralizada: Um único perfil de assinatura pode ser usado em múltiplas contas e pipelines
• Integração nativa: Integração com Notation e Kyverno para verificação de assinatura no Amazon EKS
• Conformidade FIPS 140-3 Nível 3: Atende requisitos regulatórios rigorosos para operações criptográficas

O registro de auditoria para todas as operações de assinatura permite detectar padrões incomuns, como assinatura a partir de novos endereços IP, horários incomuns ou sucessão rápida de jobs de assinatura.

Centralizar o gerenciamento de dependências

Ao centralizar o gerenciamento de pacotes e dependências, é possível validar e aprovar dependências antes de serem usadas em aplicações e auditar rapidamente dependências em caso de incidente de segurança na cadeia de suprimentos.

Na AWS, o AWS CodeArtifact permite hospedar e gerenciar os pacotes de software da organização. A configuração de grupos de pacotes permite definir uma lista aprovada de fontes upstream e bloquear acesso a todas as outras — um controle direto contra ataques de typosquatting, onde pacotes maliciosos são publicados com nomes que se assemelham a pacotes legítimos. Em vez de depender dos desenvolvedores para identificar nomes suspeitos na hora da instalação, a configuração de grupo de pacotes impõe a barreira no nível do repositório.

A centralização também permite fixar versões de dependências para evitar que atualizações automáticas puxem versões maliciosas, e remover rapidamente dependências comprometidas em todo o portfólio de software quando um incidente ocorre.

Para imagens de contêiner, o Amazon ECR fornece armazenamento centralizado de imagens com criptografia via AWS Key Management Service (AWS KMS) e políticas de ciclo de vida. Combinado com a varredura do Amazon Inspector, é possível validar continuamente a integridade das imagens. Para orientações adicionais: SEC11-BP05: Centralizar serviços para pacotes e dependências.

Atestação de proveniência do npm

Para pacotes npm especificamente, as atestações de proveniência fornecem um controle complementar no lado do consumidor. Disponíveis desde o npm 9.5, as atestações vinculam um pacote publicado ao repositório de código-fonte específico e ao fluxo CI/CD que o produziu, usando Sigstore como infraestrutura de assinatura subjacente. Quando um pacote é instalado, a CLI do npm pode verificar que o artefato publicado corresponde à proveniência de build atestada.

Mantenedores de pacotes publicando no npm podem habilitar a proveniência executando npm publish com a flag --provenance a partir de um ambiente CI/CD suportado como GitHub Actions. Para orientações adicionais: SEC11-BP06: Implantar software programaticamente e DL.CS.2: Assinar artefatos de código após cada build.

Escanear dependências ao longo do ciclo de vida de desenvolvimento

A AWS disponibiliza serviços para escanear dependências continuamente, do desenvolvimento à implantação:

• No desenvolvimento: O Kiro pode realizar análise de composição de software durante revisões de código para identificar código de terceiros vulnerável.
• Em repositórios de código e pipelines: O Amazon Inspector escaneia código próprio, dependências de terceiros e Infraestrutura como Código (IaC) em busca de vulnerabilidades.
• Para imagens de contêiner: O Amazon Inspector fornece varredura contínua de vulnerabilidades em imagens no Amazon ECR. Também pode ser integrado diretamente em pipelines CI/CD para escanear imagens antes de serem enviadas ao ECR ou implantadas.

Scanners de vulnerabilidade tradicionais focam em CVEs conhecidos — vulnerabilidades divulgadas publicamente com identificadores atribuídos. Ataques à cadeia de suprimentos como o Shai-Hulud envolvem pacotes maliciosos que funcionam como zero-days: são intencionalmente criados por agentes de ameaça e explorados ativamente antes de um CVE ser atribuído. Scanners tradicionais baseados em bancos de dados de CVE não detectarão esses pacotes até que sejam formalmente identificados e catalogados, o que pode levar dias ou semanas.

Detectar essas ameaças requer análise comportamental em escala e colaboração da comunidade, não apenas correspondência estática de assinaturas. A escala operacional da AWS — com inteligência de ameaças de fontes como MadPot e dados de resposta a incidentes de milhões de clientes — permite a detecção de comportamento suspeito de pacotes em múltiplos ambientes simultaneamente.

Quando um pacote recém-publicado exibe comportamento de coleta de credenciais em múltiplas contas de clientes em poucas horas após a publicação, esse sinal entre contas permite identificação rápida. Essas descobertas são contribuídas para bancos de dados mantidos pela comunidade como o OpenSSF Malicious Packages Repository, que atribui um identificador formal (MAL-ID) e o compartilha com a comunidade de segurança. Para a campanha de token farming do tea.xyz, o tempo médio entre submissão e identificação formal foi de aproximadamente 30 minutos.

Um modelo de ameaça relacionado importante é o pacote “dorminhoco” (sleeper package): um pacote que aparenta ser benigno na publicação e ativa comportamento malicioso apenas após um atraso ou condição de gatilho. A análise estática sozinha é insuficiente para capturar esses pacotes porque o payload malicioso não está presente ou ativo no momento da instalação. A análise comportamental do Amazon Inspector é projetada especificamente para detectar essa classe de ameaça.

Listas de Materiais de Software (SBOMs) nos formatos SPDX ou CycloneDX permitem avaliar rapidamente a exposição durante incidentes. No incidente Shai-Hulud, os pacotes comprometidos (MAL-2025-46974 e CVE-2025-59144) foram identificados precocemente, fornecendo achados acionáveis para remediação rápida. Para orientações adicionais: SEC11-BP02: Automatizar testes ao longo do ciclo de vida de desenvolvimento e lançamento.

Configurar logging e monitoramento

A visibilidade sobre atividades é essencial para detectar comportamento anômalo precocemente. As recomendações incluem:

• Habilitar logging de aplicações e serviços
• Centralizar e monitorar logs entre contas
• Usar o GuardDuty para monitorar continuamente atividade maliciosa e chamadas de API anômalas
• Agregar achados com o AWS Security Hub e impor boas práticas de configuração com o AWS Config

O logging do CloudTrail fornece trilhas de auditoria para acesso a credenciais e atividade de API. Ao responder a incidentes de cadeia de suprimentos, deve-se revisar logs do CloudTrail para eventos específicos que indicam comprometimento de credenciais ou atividade maliciosa:

• Chamadas sts:AssumeRole de endereços IP ou regiões inesperadas
• Chamadas secretsmanager:GetSecretValue ou ssm:GetParameter de fontes desconhecidas
• Chamadas ecr:PutImage de estações de trabalho de desenvolvedores, contornando pipelines CI/CD
• Chamadas lambda:UpdateFunctionCode fora de janelas normais de implantação
• Chamadas iam:CreateAccessKey seguidas de atividade imediata de API
• Chamadas codecommit:GitPush ou codebuild:StartBuild de endereços IP incomuns

Quando combinado com regras do Amazon EventBridge, é possível disparar respostas automatizadas quando o Amazon Inspector detecta pacotes maliciosos ou quando esses padrões incomuns de acesso a credenciais ocorrem. Para orientações adicionais: SEC04: Detecção.

Boas práticas adicionais

O Pilar de Segurança do Well-Architected Framework também fornece boas práticas organizacionais aplicáveis à melhoria de processos de segurança em todas as dimensões da organização. Práticas relevantes incluem: SEC11-BP01: Treinar para segurança de aplicações; SEC11-BP08: Construir um programa que incorpore ownership de segurança em equipes de workload; e SEC10: Resposta a Incidentes.

Conclusão

Incidentes recentes como Shai-Hulud, Chalk/Debug e tea.xyz refletem esforços contínuos de agentes de ameaça para atacar registros de pacotes, pipelines CI/CD e credenciais de desenvolvedores visando maior superfície de ataque e propagação. Uma única conta de mantenedor comprometida ou pacote malicioso pode se propagar simultaneamente em milhares de ambientes de consumidores.

Os controles descritos neste artigo foram projetados com esse modelo de ameaça em mente: credenciais temporárias limitam o valor de tokens roubados; gerenciamento centralizado de dependências e bloqueio de upstream reduzem a superfície de ataque no nível do registro; assinatura de artefatos garante que mesmo se um pipeline de build for comprometido, artefatos não assinados não alcancem produção; e varredura de dependências ao longo do ciclo de vida do software ajuda a identificar pacotes comprometidos precocemente. Cada camada estreita a janela de oportunidade para um agente de ameaça.

Para aprofundar

• Defending against supply chain attacks like Chalk/Debug and the Shai-Hulud worm
• Amazon Inspector detects over 150,000 malicious packages linked to token farming campaign
• What AWS Security learned from responding to recent npm supply chain threat campaigns
• Improve the security of your software supply chain with Amazon CodeArtifact package group configuration
• Hands-on Workshop: Enhancing Supply Chain Security

Fonte

Well-architected best practices for software supply chain security (https://aws.amazon.com/blogs/security/well-architected-best-practices-for-software-supply-chain-security/)