Ameaças de cadeia de suprimentos de software

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

Os riscos de um software vulnerável incluem vazamento de credenciais ou dados confidenciais, corrupção de dados, instalação de malware e falhas 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 originar-se dentro ou fora da sua organização.

Pontos de entrada para ataques de cadeia de suprimentos de software

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

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

As seçõ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 segura pode levar à criação de código que inclui vulnerabilidades não intencionais. Estações de trabalho de desenvolvedores 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 pré-configuradas e totalmente gerenciadas que podem ser personalizadas de acordo com seus requisitos.
    • Leitura local do código. O recurso source protect do Cloud Code (pré-lançamento privado) oferece 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 do SO e do pacote de idioma 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 não inclui apenas código malicioso, mas também código que introduz vulnerabilidades involuntariamente a um ataque, como cross-site scripting. As mitigações incluem:

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

Ao avaliar a integridade da fonte, examine também os scripts e as configurações de suporte que você usa para criar e implantar o software. Inclua os arquivos no seu sistema de controle de origem e nos processos de análise de código para reduzir o risco de vulnerabilidades nesses arquivos.

Consulte Proteger a 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 induz os consumidores do software a usar uma versão incorreta.

  • 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 a fonte confiável.
    • Colocar sua infraestrutura de CI/CD em um perímetro de rede para evitar a exfiltração de dados dos builds. Para serviços do Google Cloud, use o VPC Service Controls.
    • Armazenar e usar cópias confiáveis de dependências de código aberto em um armazenamento de artefatos privado, 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 para as pessoas que precisam dele. No 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 destruindo-o após o build.
    • 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: empacota e publica softwares criados 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 de dependências de código aberto necessárias em armazenamentos de artefatos privados, como o Artifact Registry.
    • Validação da origem e do build.
    • Restrição das 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 de 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 causar 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 deles 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 confusões de dependência.

  • 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. É possível reduzir o risco restringindo o acesso ao serviço de implantação e testando mudanças em ambientes de pré-produção. O Cloud Deploy pode ajudar você a gerenciar o processo de entrega contínuo e a promoção entre ambientes.

  • 3: implantar software comprometido ou não conforme. 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 configuração incorreta em softwares 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 seus aplicativos em produção.
    • Algumas configurações aumentam o risco de acesso não autorizado, como a execução como usuário raiz ou 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 fonte e Proteger implantações para saber como proteger implantações.

Ameaças de dependência

As dependências incluem dependências diretas nos seus builds, bem como todas as dependências transitivas, a árvore recursiva de dependências que são posteriores às dependências diretas.

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

  • Qualquer software de que seu app depende, incluindo componentes desenvolvidos internamente, softwares comerciais de terceiros e softwares de código aberto.
  • Vulnerabilidades originadas de qualquer um dos outros vetores de ataque. Por exemplo:
    • Um invasor tem acesso ao seu 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 na organização. Eles criam e publicam o componente diretamente nos ambientes de desenvolvimento locais e introduzem acidentalmente uma vulnerabilidade em uma biblioteca que só é usada 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 extraírem a dependência diretamente do repositório público.

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

Mitigar ameaças

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

Ao mesmo tempo, não é necessário mudar tudo de uma vez. O efeito cumulativo de ação, mais conhecido como modelo do 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 em toda a 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 remediar ameaças.
  • Saiba mais sobre as práticas recomendadas para proteger sua cadeia de suprimentos de software e os produtos do Google Cloud projetados para oferecer suporte a essas práticas.
  • Incorpore os recursos de segurança do Google Cloud aos seus processos de desenvolvimento, build e implantação para melhorar a postura de segurança da sua cadeia de suprimentos de software. É possível implementar os serviços gradualmente, com base nas suas prioridades e na infraestrutura atual.

A seguir