Salvaguardar builds

Este documento descreve as práticas recomendadas para proteger seus builds. O código de criação pode se referir a diferentes tipos de operações, como:

  • Otimização ou ofuscação do código: por exemplo, a ferramenta de código aberto do Google O Closure Compiler analisa e analisa JavaScript, remove códigos mortos, reescreve e minimiza o que resta. Ele também verifica o código para problemas comuns de JavaScript.
  • Compilar código em código intermediário: por exemplo, é possível compilar código Java em um arquivo de classe Java (.class) ou código C++ em um arquivo de objeto (.obj).
  • Compilar o código e vincular, criando uma biblioteca ou um arquivo executável: por exemplo, compilar código C++ em uma biblioteca compartilhada (.so) ou um arquivo executável do Windows (.exe).
  • Empacotar o código em um formato distribuível ou implantável: exemplos incluem a criação de arquivos Java WAR (.war) de arquivos de classe Java, a criação de uma imagem Docker ou a criação de uma distribuição criada em Python (.whl).

Dependendo da linguagem de programação que você usa e do ambiente em que implanta, seu build pode conter combinações diferentes dessas operações. Para Por exemplo, um build pode empacotar código Python em uma distribuição criada e fazer upload dele para um armazenamento de artefatos como o Artifact Registry ou PyPI, para que você possa usá-lo como dependência funções do Cloud Run. Também é possível colocar o código Python em contêineres e implantar a imagem do contêiner no Cloud Run ou no Google Kubernetes Engine.

As práticas deste documento se concentram na criação de código para empacotamento ou em ambientes de execução em vez de compilar códigos.

Usar builds automatizados

Um build automatizado ou com script define todas as etapas de build no script ou na configuração de build, incluindo etapas para extrair o código-fonte e etapas para criar o código. O único comando manual, se houver, é o comando para executar o build.

Por exemplo, um script de build pode ser:

  • Um Cloud Build cloudbuild.yaml.
  • Um Makefile executado com a ferramenta make.
  • Um arquivo de fluxo de trabalho do GitHub Actions no formato YAML armazenado em .github/workflows/.

Builds automatizados proporcionam consistência nas etapas de build. No entanto, também é para executar builds em um ambiente consistente e confiável.

Embora builds locais possam ser úteis para depuração, lançar versões de software de builds locais pode introduzir muitas preocupações de segurança, inconsistências e e ineficiências no processo de criação.

  • Permitir builds locais é uma forma de invasores com intenções maliciosas para modificar o processo de build.
  • As inconsistências nos ambientes locais e nas práticas dos desenvolvedores dificulta a reprodução de builds e o diagnóstico de problemas de build.

Os builds manuais tornam o processo ineficiente, usando mais recursos de infraestrutura, como computação, armazenamento e redes. Na requisitos para a estrutura SLSA, os builds automatizados são um requisito para a SLSA de nível 1 e usar um serviço de criação em vez do para builds é um requisito do nível 2 do SLSA.

O Cloud Build é o serviço de build gerenciado no Google Cloud. Ele usa um arquivo de configuração da versão para fornecer etapas de build ao Cloud Build. É possível configurar builds para buscar dependências, executar testes de unidade, análises estáticas e testes de integração e criar artefatos com ferramentas de build como Docker, Gradle, Maven, Go e Python. O Cloud Build é totalmente integrado a outros serviços de CI/CD no Google Cloud, como o Artifact Registry e o Cloud Deploy, bem como ambientes de execução, como o GKE e o Cloud Run. Ele também oferece integração com os principais sistemas de gerenciamento de código-fonte, como o GitHub e o Bitbucket.

Gerar procedência do build

A procedência do build é uma coleção de dados verificáveis sobre um build.

Os metadados de procedência incluem detalhes como os resumos das imagens criadas, os locais da origem de entrada, o conjunto de ferramentas de build e a duração do build.

A geração da procedência do build ajuda você a:

  • Verifique se um artefato criado foi criado a partir de um local de origem confiável e por um sistema de build confiável.
  • Identifique o código injetado de um local de origem ou sistema de build não confiável.

Você pode usar mecanismos de alerta e política para usar proativamente dados de origem de build. Por exemplo, é possível criar políticas que permitam apenas implantações de código criados a partir de fontes verificadas.

Para o SLSA nível 1, a procedência do build deve estar disponível aos consumidores do artefatos. Para o nível 2 do SLSA, os dados de origem do build também precisam:

  • Geradas pelo serviço de build ou legíveis diretamente do serviço de build.
  • Verificável por um consumidor quanto à autenticidade e integridade. Isso deve ser feito com uma assinatura digital gerada pelo serviço que cria o build dados de procedência.

Para o nível 3 do SLSA, o conteúdo da procedência também precisa incluir:

  • O ponto de entrada da definição do build.
  • Todos os parâmetros de build estão sob o controle do usuário.

O Cloud Build pode gerar procedência do build para imagens de contêiner. que oferecem garantia de build da SLSA nível 3. Para mais informações, consulte Como visualizar a procedência do build.

Usar um ambiente de build temporário

Ambientes temporários são ambientes temporários que duram uma única invocação de build. Após a criação, o ambiente é excluído permanentemente ou excluído. Os builds temporários garantem que o serviço de build e as etapas de build sejam executadas em um ambiente temporário, como um contêiner ou uma VM. Em vez de reutilizar um ambiente de build existente, o serviço de build provisiona um novo ambiente para cada build e o destrói após a conclusão do processo de build.

Os ambientes temporários garantem builds limpos, já que não há arquivos residuais ou configurações de ambiente de builds anteriores que possam interferir no processo de build. Um ambiente não efêmero oferece uma oportunidade para que os invasores injetar arquivos e conteúdo maliciosos. Um ambiente temporário também reduz a sobrecarga de manutenção e reduz inconsistências no ambiente de build.

O Cloud Build configura um novo ambiente de máquina virtual para cada construção e destrói todos eles após a construção.

Restringir o acesso ao serviço de build

Siga o princípio de segurança do menor privilégio concedendo as permissões mínimas necessárias ao serviço de build e aos recursos de build. Você também precisa usar uma identidade não humana para executar builds e interagir com outros serviços em nome do build.

Se você usa o Cloud Build:

  • Conceda as permissões mínimas necessárias aos membros da sua organização.
  • Personalize as permissões da conta de serviço que atua em nome do Cloud Build para que ela tenha apenas as permissões necessárias para o uso. Edite as permissões da conta de serviço padrão do Cloud Build ou use uma conta de serviço personalizada.
  • Use as integrações permitidas do Cloud Build. política da organização para controlar os serviços externos que têm permissão invocar acionadores de build.

  • Coloque o Cloud Build em um perímetro de serviço usando o VPC Service Controls. O perímetro permite comunicação livre entre os serviços do Google Cloud dentro do perímetro, mas os limites comunicação em todo o perímetro com base nas regras que você especificar. O perímetro também reduz o risco de exfiltração de dados.

    O Cloud Build só oferece suporte ao VPC Service Controls para builds executados em um pool particular.

Proteger credenciais

Os builds geralmente incluem conexões com outros sistemas, como controle de versão, armazéns de artefatos e ambientes de implantação. A proteção das credenciais usadas nos builds ajuda a impedir o acesso não autorizado a sistemas na cadeia de suprimentos de software e a exfiltração de dados.

Evite armazenar credenciais codificadas diretamente no controle de versões ou configuração do build. Em vez disso, armazene as credenciais em um keystore seguro.

No Google Cloud, o Secret Manager armazena com segurança chaves de API, senhas e outros dados sensíveis. É possível configurar o Cloud Build para usar secrets armazenados no Secret Manager.

Gerenciar as dependências

A integridade dos seus aplicativos depende da integridade do código desenvolvido e das dependências usadas. Você também precisa considerar onde você publica as dependências, quem tem acesso de leitura e gravação no repositórios de artefatos e políticas para fontes confiáveis de artefatos de build que você implanta nos ambientes de execução.

Para saber mais sobre gerenciamento de dependências, consulte Gerenciar dependências.

No Cloud Build, você usa cloud builders para executar comandos Builders são imagens de contêiner com linguagens e ferramentas comuns instalado neles. É possível usar imagens de contêiner públicas de registros públicos como o Docker Hub, criadores fornecidos pelo Cloud Build, builders fornecidos pela comunidade e criadores personalizados criados por você. Você pode também use buildpacks como builders, incluindo buildpacks do Google Cloud.

Confira os builders que você usa nos builds do Cloud Build. descubra quem fornece essas informações e decida se você confia nelas em seu software na cadeia de suprimentos. Para ter mais controle sobre o código em um builder, você pode criar builders personalizados em vez de usar builders de uma fonte pública.

Reduzir as oportunidades de alterar o build

Há vários outros fatores que podem influenciar um build, incluindo:

  • construções que são executadas simultaneamente e são capazes de influenciar umas às outras, ou que persiste e afeta um build subsequente.
  • Builds que aceitam parâmetros de usuário diferentes do ponto de entrada do build e do local de origem de nível superior.
  • Builds que especificam dependências com intervalos ou dependências que são mutáveis (por exemplo, usando uma imagem com a tag latest). Essas abordagens criam o risco de que os builds usem versões incorretas ou indesejadas de dependências.

As práticas a seguir ajudam a mitigar esses riscos:

  • Execute cada build em um ambiente efêmero.
  • Evite executar builds com parâmetros adicionais para que os usuários não possam influenciam as variáveis definidas nos scripts de build.
  • Restringir o acesso ao serviço e aos recursos de build.
  • Faça referência a versões imutáveis de dependências em vez de identificadores, como que possam apontar para uma versão diferente do artefato no futuro. Para mais informações sobre dependências, consulte Gerenciamento de dependências.

Software Delivery Shield

O Software Delivery Shield é uma totalmente gerenciada e de ponta a ponta para a segurança da cadeia de suprimentos de software. Ele fornece um conjunto abrangente e modular de recursos e ferramentas em serviços do Google Cloud que desenvolvedores, DevOps e equipes de segurança podem usar para melhorar a postura de segurança da cadeia de suprimentos de software. Ela mostra insights de segurança para aplicativos criados na UI do Cloud Build no console do Google Cloud. Isso inclui:

  • O nível SLSA, que identifica o nível de maturidade da segurança da cadeia de suprimentos de software.
  • Vulnerabilidades, lista de materiais de software (SBOM, na sigla em inglês) e vulnerabilidade Instruções Exploitability eXchange (VEX) para artefatos de build.
  • Procedência do build, que é uma coleção de metadados verificáveis sobre um build. Ele inclui detalhes como os resumos das imagens construídas, o locais de origem de entrada, o conjunto de ferramentas, as etapas e a duração da compilação.

Para instruções sobre como visualizar insights de segurança para aplicativos criados, consulte Crie um aplicativo e acesse insights de segurança.

A seguir