Ameaças de cadeia de suprimentos de software

Os vetores de ataque para cadeias de suprimentos de software são as várias maneiras pelas quais alguém pode comprometer seu software intencionalmente ou acidentalmente.

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

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

Pontos de entrada para ataques à cadeia de suprimentos de software

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

Google Cloud fornece um conjunto modular de recursos e ferramentas que incorporam práticas recomendadas para mitigar os dois conjuntos de ameaças.

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

Ameaças de origem

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

  • 1: escrever código não seguro. A falta de práticas de programação seguras pode levar à escrita de código que inclui vulnerabilidades não intencionais. Estações de trabalho de desenvolvedores não seguras também podem introduzir código malicioso ou não seguro. As mitigações incluem:

    • 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 para atender aos seus requisitos.
    • Verificação local de código. O Cloud Code Source Protect (visualização privada) 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 de pacotes de linguagem e SO em imagens de contêiner.
    • Educação sobre práticas para tornar o código mais seguro.

  • A: enviar código inválido para o repositório de origem. Isso inclui não apenas código malicioso, mas também código que introduz vulnerabilidades não intencionais a um ataque, como o scripting em vários sites. As mitigações incluem:

    • Exigir revisão humana para mudanças no código-fonte.
    • Usar ferramentas de verificação e linting de código que se integram a IDEs 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 build e usar autenticação multifator ajuda a mitigar esse risco.

Ao avaliar a integridade da origem, examine também os scripts e configurações de suporte usados para criar e implantar o software. Inclua-os nos processos de revisão de código e sistema de controle de origem para reduzir o risco de vulnerabilidades nesses arquivos.

Consulte Proteger a origem para saber mais sobre como proteger sua origem.

Ameaças de build

Essas ameaças comprometem seu software quando você o cria ou empacota, ou enganam os consumidores do software para que usem uma versão ruim.

  • C: criar com uma origem que não seja do sistema de controle de origem confiável. As mitigações que ajudam a reduzir esse risco incluem:
    • Usar serviços de build, como o Cloud Build, que geram informações de procedência para que você possa validar se os builds usam uma origem confiável.
    • Colocar sua infraestrutura de CI/CD em um perímetro de rede para evitar a exfiltração de dados dos builds. Para Google Cloud serviços, use 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 build. As mitigações que ajudam a reduzir esse risco incluem:
    • Siga o princípio de privilégio mínimo restringindo o acesso direto ao sistema de build a pessoas que precisam dele. Em Google Cloud , é possível conceder papéis predefinidos adequados ou criar papéis personalizados.
    • Use serviços de build gerenciados, como o Cloud Build. O Cloud Build executa builds temporários configurando um ambiente de VM para cada build e o destrói após o build.
    • Coloque sua infraestrutura de CI/CD em um perímetro de rede para evitar. exfiltração de dados dos builds. Para Google Cloud serviços, use VPC Service Controls.
  • F: empacotar e publicar software criado fora do processo oficial. Os sistemas de build que geram e assinam a procedência do build permitem validar se o software foi criado por um sistema de build confiável.
  • G: comprometer o repositório em que você armazena o software para usuários internos ou externos. As 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 armazenamentos de artefatos particulares, como o Artifact Registry.
    • Validar a procedência do build e da origem.
    • Restringir permissões de upload a contas não humanas dedicadas e administradores de repositório. Não Google Cloud, as contas de serviço agem em nome de serviços e aplicativos.

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

  • H: resolver dependências especificando um intervalo de versões ou uma tag que não esteja permanentemente anexada a uma versão de build específica pode levar a vários problemas:

    • Os builds não são reproduzíveis porque as dependências que um build usa pela primeira vez podem ser diferentes das dependências que o build usa para execuções futuras do mesmo build.
    • Uma dependência pode ser resolvida para uma versão comprometida ou uma versão com mudanças que quebram o software. Usuários de má-fé podem aproveitar essa incerteza para fazer com que o build escolha 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 mitigar os riscos de confusão de dependências.

  • 2: comprometer o processo de implantação. Se você usar um processo de implantação contínua, comprometer esse processo poderá introduzir mudanças indesejadas no software que você entrega aos usuários. É possível mitigar o risco restringindo o acesso ao serviço de implantação e testando as mudanças em ambientes de pré-produção. O Cloud Deploy pode ajudar a gerenciar o processo de entrega contínua e a promoção entre ambientes.

  • 3: implantar software comprometido ou não compatível. A aplicação de políticas de implantação pode ajudar a mitigar esse risco. É possível usar a autorização binária para validar se 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ção incorreta no software em execução.

    • Novas vulnerabilidades são descobertas regularmente, o que significa que novas descobertas podem mudar o nível de risco de segurança dos aplicativos em 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 e problemas de configuração nas cargas de trabalho em execução.

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

Consulte Proteger builds para saber mais sobre como proteger sua origem e Proteger implantações para saber como proteger implantações.

Ameaças de dependência

As dependências incluem dependências diretas nos builds, bem como todas as dependências transitivas, a árvore recursiva de dependências que estão abaixo das dependências diretas.

No diagrama, E indica o uso de uma dependência ruim no build. Uma dependência ruim pode incluir:

  • Qualquer software de que o aplicativo dependa, incluindo componentes desenvolvidos internamente, software comercial de terceiros e software de código aberto.
  • Vulnerabilidades originadas de qualquer um dos outros vetores de ataque. Por exemplo:
    • Um invasor acessa o sistema de controle de origem e modifica a versão de uma dependência usada pelo projeto.
    • O build inclui um componente desenvolvido por outra equipe na sua organização. Eles criam e publicam o componente diretamente dos ambientes de desenvolvimento locais e introduzem acidentalmente 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 fazer com que os pipelines de consumo sejam interrompidos se eles recuperarem a dependência diretamente do repositório público.

Consulte Práticas recomendadas para dependências para saber mais sobre como mitigar riscos.

Como mitigar ameaças

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

Ao mesmo tempo, não é necessário mudar tudo de uma só vez. O efeito de ato cumulativo, mais conhecido como o 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 mitigações na cadeia de suprimentos, você aumenta a proteção contra diferentes tipos de ataques.

  • Avalie sua postura de segurança usando frameworks e ferramentas que ajudam a avaliar a capacidade da sua organização de detectar, responder e corrigir ameaças.
  • Saiba mais sobre as práticas recomendadas para proteger sua cadeia de suprimentos de software, e Google Cloud produtos projetados para oferecer suporte a essas práticas.
  • Incorpore Google Cloud recursos de segurança aos processos de desenvolvimento, build, e implantação para melhorar a postura de segurança da cadeia de suprimentos de software de software. É possível implementar serviços gradualmente, com base nas suas prioridades e infraestrutura atual.

A seguir