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 por acidente.

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 de ameaças abrangem todo o ciclo de vida do software e podem ter origem 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:

OGoogle Cloud oferece 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 seu código-fonte.

  • 1: escreva código não seguro. A falta de práticas de programação seguras pode levar à criação de código que inclui vulnerabilidades sem intenção. Estações de trabalho de desenvolvedores inseguras também podem introduzir código malicioso ou inseguro. 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.
    • Leitura local de código. Source protect do Cloud Code (prévia 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 em imagens de contêineres no SO e em pacotes de idiomas.
    • Educação sobre práticas para tornar o código mais seguro.

  • A: envie 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 sem intenção a um ataque, como script entre sites. As mitigações incluem:

    • Exigir revisão humana para mudanças no código-fonte.
    • Usando ferramentas de verificação e linting de código que se integram a IDEs e sistemas de controle de origem.

  • B: comprometimento do sistema de controle de origem. Restringir o acesso ao sistema de controle de origem e a outros sistemas no pipeline de build, além de usar a autenticação multifator, ajuda a reduzir esse risco.

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

Consulte Proteção da fonte para saber mais sobre como proteger sua fonte.

Ameaças de build

Essas ameaças comprometem seu software quando você o cria ou empacota, ou enganam os consumidores do seu software para usar 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 origem para que você possa validar se os builds usam uma fonte confiável.
    • Colocar sua infraestrutura de CI/CD em um perímetro de rede para evitar a exfiltração de dados dos seus builds. Para serviços do Google Cloud , use o VPC Service Controls.
    • Armazenar e usar cópias confiáveis das dependências de código aberto necessárias em um repositório 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 apenas às pessoas que precisam dele. No Google Cloud , você pode conceder funções predefinidas adequadas ou criar funções personalizadas.
    • Use serviços de build gerenciados, como o Cloud Build. O Cloud Build executa builds efêmeras configurando um ambiente de VM para cada build e destruindo-o depois.
    • Coloque sua infraestrutura de CI/CD em um perímetro de rede para evitar a exfiltração de dados dos seus builds. Para serviços do Google Cloud , use o 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 seus usuários internos ou externos. As mitigações que ajudam a reduzir esse risco incluem:
    • Armazenar e usar cópias confiáveis das dependências de código aberto necessárias em repositórios de artefatos particulares, como o Artifact Registry.
    • Validar a procedência da build e da fonte.
    • Restringir permissões de upload a contas não humanas dedicadas e administradores de repositório. No Google Cloud, as contas de serviço agem em nome de serviços e aplicativos.

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

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

    • As builds não são reproduzíveis porque as dependências usadas na primeira vez podem ser diferentes das usadas em execuções futuras da mesma build.
    • Uma dependência pode ser resolvida para uma versão comprometida ou uma versão com mudanças que prejudicam seu software. Usuários mal-intencionados podem aproveitar essa incerteza para fazer com que seu build escolha a versão de um pacote deles em vez da versão que você pretendia usar. Várias práticas recomendadas para dependências podem ajudar a reduzir os riscos de confusão de dependências.

  • 2: comprometer o processo de implantação. Se você usa um processo de implantação contínua, comprometer esse processo pode introduzir mudanças indesejadas no software que você entrega aos usuários. Para reduzir o risco, restrinja o acesso ao serviço de implantação e teste as mudanças em ambientes de pré-produção. O Cloud Deploy ajuda a gerenciar o processo de entrega contínua e a promoção entre ambientes.

  • 3: implante software comprometido ou em não 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 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 erros de configuração em softwares em execução.

    • Novas vulnerabilidades são descobertas regularmente, o que significa que novos resultados podem mudar o nível de risco de segurança dos seus aplicativos em produção.
    • Algumas configurações aumentam o risco de acesso não autorizado, como executar como usuário raiz ou permitir o 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 a jusante das dependências diretas.

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

  • Qualquer software de que seu aplicativo dependa, incluindo componentes que você desenvolve 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 ganha acesso ao seu 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 usam apenas 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 falhas nos pipelines consumidores se eles recuperarem a dependência diretamente do repositório público.

Consulte as práticas recomendadas para dependências e saiba como reduzir os riscos.

Mitigação de ameaças

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

Ao mesmo tempo, você não precisa mudar tudo de uma vez. O efeito cumulativo de atos, 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, quando você combina mitigação em toda a cadeia de suprimentos, aumenta a proteção contra diferentes tipos de ataques.

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

A seguir