Ameaças da cadeia de suprimentos de software

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Os vetores de ataque de cadeias de suprimentos de software são as várias maneiras de comprometer intencionalmente ou acidentalmente com seu software.

Os riscos de software vulnerável incluem credenciais de vazamento ou dados confidenciais, corrupção de dados, instalação de malware e falhas temporárias do aplicativo. Esses problemas resultam em perda de tempo, dinheiro e confiança do cliente.

Os pontos de entrada de ameaças abrangem todo o ciclo de vida do software e podem se originar dentro ou fora da sua organização.

Um diagrama que mostra pontos de entrada para ataques da cadeia de suprimentos de software

A legenda do diagrama inclui dois conjuntos de ameaças:

O Software Delivery Shield, uma solução de segurança da cadeia de suprimentos de software totalmente gerenciada no Google Cloud, incorpora práticas recomendadas para ajudar você a reduzir os dois conjuntos de ameaças.

As subseções deste documento descrevem as ameaças no contexto de origem, versões, implantação e dependências.

Ameaças de origem

Essas ameaças afetam a integridade do código-fonte.

  • 1: escreva um código não seguro. A falta de práticas de programação seguras pode levar a uma escrita não intencional de vulnerabilidades. As estações de trabalho do desenvolvedor não seguras também podem introduzir códigos maliciosos ou não seguros. As mitigações incluem:

    • Como definir políticas para estações de trabalho de desenvolvedores. O Cloud Workstations oferece estações de trabalho totalmente gerenciadas e pré-configuradas que podem ser personalizadas de acordo com seus requisitos.
    • Leitura local de código A proteção da origem do Cloud Code (prévia particular) fornece feedback de segurança em tempo real, incluindo informações de vulnerabilidade e licença para dependências. Os desenvolvedores também podem usar a API On-Demand Scanning para verificar vulnerabilidades em imagens de contêiner e no pacote de idiomas.
    • Veja práticas recomendadas para tornar o código mais seguro.
  • A: enviar um código inválido para o repositório de origem. Isso inclui não apenas o código malicioso, mas também o código que introduz vulnerabilidades acidentalmente a um ataque, como scripts entre sites. As mitigações incluem:

    • Exigir revisão humana para mudanças no código-fonte
    • Uso de ferramentas de verificação de código e lint que se integram a ambientes de desenvolvimento integrado e sistemas de controle de origem.
  • B: comprometer o sistema de controle de origem. Restringir o acesso ao sistema de controle de origem e a outros sistemas no pipeline de compilação e usar a autenticação multifator ajuda a reduzir esse risco.

Ao avaliar a integridade da origem, examine também os scripts de suporte e a configuração que você usa para criar e implantar o software. Inclua-os no sistema de controle de origem e nos processos de revisão de código para que seja possível correr o risco de vulnerabilidades nesses arquivos.

Consulte Fonte de segurança para saber mais sobre como proteger sua origem.

Criar ameaças

Essas ameaças comprometem o software durante a criação ou o empacotamento, ou enganam os consumidores do software para que usem uma versão incorreta.

  • C: crie com uma fonte que não seja do sistema de controle de origem confiável. Mitigações que ajudam a reduzir esse risco incluem:
    • Usar serviços de compilação, como o Cloud Build, que geram informações de procedência para validar se os builds usam origem confiável.
    • Colocar a infraestrutura de CI/CD em um perímetro de rede para evitar a exfiltração de dados dos builds. Para os serviços do Google Cloud, use o VPC Service Controls.
    • Armazenar e usar cópias confiáveis de dependências de código aberto necessárias em um armazenamento de artefatos particular, como o Artifact Registry.
  • D: comprometer o sistema de compilação. Mitigações que ajudam a reduzir esse risco incluem:
    • Seguir o princípio de privilégio mínimo restringindo o acesso direto ao sistema de compilação às pessoas que precisam dele. No Google Cloud, é possível conceder papéis predefinidos apropriados ou criar papéis personalizados.
    • Usar serviços de build gerenciados, como o Cloud Build. O Cloud Build executa builds efêmeros ao configurar um ambiente de VM para cada build e destruí-lo após o build.
    • Coloque sua infraestrutura de CI/CD em um perímetro de rede para evitar a exfiltração de dados dos builds. Para os serviços do Google Cloud, use o VPC Service Controls.
  • F: empacotar e publicar software que foi criado fora do processo oficial. Sistemas de compilação que geram e assinam a procedência do build permitem que você valide que o software foi criado por um sistema de compilação confiável.
  • G: comprometer o repositório onde você armazena o software para usuários internos ou externos. Mitigações que ajudam a reduzir esse risco incluem:
    • Armazenar e usar cópias confiáveis de dependências de código aberto necessárias em um armazenamento de artefatos particular, como o Artifact Registry.
    • Validando o build e a procedência da origem.
    • a restrição de permissões de upload para contas não humanas dedicadas e administradores de repositório. No [Google Cloud, as contas de serviço atuam em nome dos serviços e aplicativos.

Ameaças de implantação e ambiente de execução

  • H: a resolução de dependências especificando um intervalo de versões ou uma tag que não está permanentemente anexada a uma versão de compilação específica pode causar vários problemas:

    • Os builds não são reproduzíveis porque as dependências que um build usa na primeira vez podem ser diferentes daquelas que o build usa para execuções futuras do mesmo build.
    • Uma dependência pode resolver para uma versão comprometida ou para uma versão com alterações que corrompam seu software. Usuários de má-fé podem aproveitar essa incerteza para fazer seu build escolher a versão de um pacote em vez da versão que você pretendia usar. Várias práticas recomendadas para dependências podem ajudar a reduzir os riscos de confiança de dependência.
  • 2: comprometer o processo de implantação. Caso você use um processo de implantação contínua, a confirmação desse processo pode introduzir alterações indesejadas no software que você entrega aos usuários. É possível reduzir o risco restringindo o acesso ao serviço de implantação e testando as alterações em ambientes de pré-produção. O Google Cloud Deploy ajuda você a gerenciar o processo de entrega contínua e a promoção entre ambientes.

  • 3: implante um software comprometido ou que não esteja em conformidade. A aplicação de políticas de implantação pode ajudar a reduzir esse risco. É possível usar a autorização binária para validar que as imagens de contêiner estão em conformidade com os critérios da política e bloquear a implantação de imagens de contêiner de fontes não confiáveis.

  • 4: vulnerabilidades e configurações incorretas no software em execução.

    • As novas vulnerabilidades são descobertas regularmente. Isso significa que novas descobertas podem alterar o nível de risco de segurança dos seus aplicativos na produção.
    • Algumas configurações aumentam o risco de acesso não autorizado, como a execução como usuário raiz ou a permissão de escalonamento de privilégios na execução de um contêiner.

    O painel de postura de segurança do GKE mostra informações sobre vulnerabilidades do SO e problemas de configuração nas cargas de trabalho em execução.

    No Cloud Run, também é possível ver insights de segurança sobre as revisões implantadas, incluindo vulnerabilidades conhecidas nas imagens de contêiner implantadas.

Consulte Como proteger versões para saber mais sobre como proteger sua origem e Como implantar implantações para saber mais sobre como proteger implantações.

Ameaças de dependência

As dependências incluem dependências diretas nos seus builds, assim como todas as dependências transitivas, a árvore recursiva de dependências downstream das suas dependências diretas.

No diagrama, E indica o uso de uma dependência incorreta na versão. Uma dependência inadequada pode incluir:

  • Qualquer software de que seu aplicativo depende, incluindo componentes desenvolvidos internamente, software comercial de terceiros, software de código aberto.
  • Vulnerabilidades originadas de qualquer um dos outros vetores de ataque. Por exemplo:
    • Um invasor recebe acesso ao sistema de controle de origem e modifica a versão de uma dependência usada pelo projeto.
    • Seu build inclui um componente desenvolvido por outra equipe da organização. Eles publicam o build e publicam o componente diretamente nos ambientes de desenvolvimento locais e acidentalmente apresentam uma vulnerabilidade em uma biblioteca que só usam localmente para testes e depuração.
  • Remoção intencional de uma dependência de código aberto de um repositório público. A remoção pode causar a interrupção dos pipelines de consumo se eles recuperarem a dependência diretamente do repositório público.

Consulte as práticas recomendadas para dependências para saber mais sobre como reduzir riscos.

Redução de ameaças

A integridade geral da cadeia de suprimentos é tão forte quanto a parte mais vulnerável. A negligência de um vetor de ataque aumenta o risco de ataque nessa parte da cadeia de suprimentos.

Ao mesmo tempo, não é preciso alterar tudo de uma vez. O efeito de ação cumulativo, mais conhecido como modelo de queijo suíço, se aplica à segurança da cadeia de suprimentos de software. Cada mitigação implementada reduz o risco e, ao combinar as mitigações na cadeia de suprimentos, você aumenta a proteção contra diferentes tipos de ataques.

A seguir