Proteger 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.
  • Compilação de 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).
  • Compilação de código e vinculação, criação de uma biblioteca ou arquivo executável. Por exemplo, Compilar código C++ em uma Biblioteca compartilhada (.so) ou um executável do Windows arquivo (.exe).
  • Empacotamento de código em um formato distribuível ou implantável: exemplos incluem Criar arquivos Java WAR (.war) a partir de arquivos de classe Java, criar uma imagem Docker ou criando uma distribuição integrada 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 Cloud Functions. Também é possível conteinerizar o código Python 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 um com script define todas as etapas no script de build. ou configuração do build, incluindo etapas para recuperar o código-fonte e etapas para criar o código. O único comando manual, se houver, é o que executa o ser construído.

Por exemplo, um script de compilação 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/.

Versões automatizadas oferecem consistência nas etapas de criação. No entanto, também é para executar builds em um ambiente consistente e confiável.

Embora builds locais possam ser úteis para fins de depuração, o lançamento de softwares 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.

Builds manuais tornam o processo ineficiente ao aproveitar mais 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. Ela usa um arquivo de configuração de build para fornecer o build etapas no 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 tem integração total com outros serviços de CI/CD no do Google Cloud, como o Artifact Registry e o Cloud Deploy, conforme além de ambientes de execução, como o GKE Cloud Run: ele também tem integração com os principais códigos-fonte de sistemas de gerenciamento de projetos, 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 de origem de entrada, o conjunto de ferramentas 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.

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

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

  • 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 feitos para durar de uma única invocação de build. Depois da criação, o ambiente é excluído permanentemente ou excluído. Builds efêmeros garantem que o serviço e as etapas de build 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 depois a destrói após a conclusão do processo de compilação.

Ambientes temporários garantem builds limpos porque não há arquivos residuais ou do ambiente de builds anteriores que possam interferir no build de desenvolvimento de software. Um ambiente não temporário oferece aos invasores uma oportunidade injetar arquivos e conteúdo maliciosos. Um ambiente temporário também reduz 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 de privilégio mínimo, concedendo o mínimo permissões necessárias para o serviço e os recursos de build. Você deve também usam 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 para a conta de serviço que atua em nome de o Cloud Build para que ele tenha apenas as permissões necessárias para seu uso. Edite as permissões do diretório conta de serviço do Cloud Build ou considere usar uma 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 VPC Service Controls. O perímetro permite comunicação livre entre os serviços do Google Cloud no perímetro, mas limita comunicação em todo o perímetro com base nas regras que você especificar. A também reduz o risco de exfiltração de dados.

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

Proteger credenciais

Os builds geralmente incluem conexões com outros sistemas, como controle de versões, armazenamentos de artefatos e ambientes de implantação. As credenciais que que você usa nos builds ajuda a impedir o acesso não autorizado aos sistemas da na cadeia de suprimentos de software e no vazamento 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 com segurança armazena 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 aplicativos depende da integridade do código que você desenvolve e das dependências que usa. 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ável, por exemplo, usando uma imagem com a tag latest. Esses criam risco para que os builds usem versões ruins ou indesejadas do dependências.

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

  • Execute cada build em um ambiente temporário.
  • 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 oferece abrangente e modular de recursos e ferramentas 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:

  • Nível de SLSA, que identifica o nível de maturidade do seu software segurança da cadeia de suprimentos.
  • Vulnerabilidades, lista de materiais de software (SBOM) e vulnerabilidade Instruções Exploitability eXchange (VEX) para artefatos de build.
  • Procedência do build, que é uma coleção de metadados verificáveis sobre uma ser construído. 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