Salvaguardar builds

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

  • Otimização ou ofuscação de código: por exemplo, a ferramenta de código aberto do Google Closure Compiler analisa e analisa JavaScript, remove código morto, reescreve e minimiza o que resta. Ele também verifica o código em busca de armadilhas comuns do 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 usada e do ambiente de implantação, o build pode conter diferentes combinações dessas operações. Por exemplo, um build pode empacotar o código Python em uma distribuição criada e fazer upload para um repositório de artefatos, como o Artifact Registry ou o PyPI, para que você possa usá-lo como uma dependência nas 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 neste documento se concentram na criação de código para empacotamento ou implantação em ambientes de execução, em vez de compilar código.

Usar builds automáticos

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 cloudbuild.yaml do Cloud Build.
  • Um Makefile executado com a ferramenta make.
  • Um arquivo de fluxo de trabalho do GitHub Actions no formato YAML armazenado no diretório .github/workflows/.

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

Embora os builds locais sejam úteis para fins de depuração, o lançamento de software a partir de builds locais pode apresentar muitas preocupações de segurança, inconsistências e ineficiências no processo de build.

  • Permitir builds locais oferece uma maneira de um invasor com intenção maliciosa modificar o processo de build.
  • Inconsistências nos ambientes locais e nas práticas de desenvolvedores dificultam 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. Nos requisitos do framework SLSA, os builds automatizados são um requisito para o nível 1 do SLSA, e o uso de um serviço de build em vez de ambientes de desenvolvedor para builds é um requisito para o 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 a 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 de procedência do build ajuda você a:

  • Verifique se um artefato foi criado em 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 permitem apenas implantações de código criadas com base em fontes verificadas.

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

  • Gerado pelo serviço de build ou legível diretamente dele.
  • Verificável por um consumidor para autenticidade e integridade. Isso precisa ser feito com uma assinatura digital gerada pelo serviço que cria os dados de origem do build.

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

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

O Cloud Build pode gerar a procedência de build para imagens de contêiner que oferecem garantia de build de nível 3 do SLSA. Para mais informações, consulte Como conferir a origem 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 o build, o ambiente é apagado 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 invasores injetem arquivos e conteúdo maliciosos. Um ambiente temporário também reduz a sobrecarga de manutenção e as inconsistências no ambiente de build.

O Cloud Build configura um novo ambiente de máquina virtual para cada build e o destrói após o build.

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 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 a política organizacional Integrações permitidas do Cloud Build para controlar os serviços externos que podem invocar acionadores de build.

  • Coloque o Cloud Build em um perímetro de serviço usando o VPC Service Controls. O perímetro permite a comunicação livre entre os serviços do Google Cloud dentro do perímetro, mas limita a comunicação em todo o perímetro com base nas regras especificadas. 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ão ou na 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 suas 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 publica suas dependências, quem tem acesso de leitura e gravação aos repositórios de artefatos e as políticas para origens confiáveis de artefatos de build que você implanta nos ambientes de execução.

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

No Cloud Build, você usa builders de nuvem para executar comandos. Os builders são imagens de contêiner com linguagens e ferramentas comuns instaladas. É possível usar imagens de contêiner públicas de registros públicos, como o Docker Hub, builders fornecidos pelo Cloud Build, builders enviados pela comunidade e builders personalizados criados por você. Também é possível usar buildpacks como builders, incluindo buildpacks do Google Cloud.

Analise os builders que você usa nos builds do Cloud Build, descubra quem os fornece e decida se você confia neles na cadeia de suprimentos de software. Para manter 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:

  • Builds que são executados simultaneamente e podem influenciar um ao outro, ou um build 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 builds usarem versões incorretas ou indesejadas de dependências.

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

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

Segurança da cadeia de suprimentos de software

O Google Cloud oferece um conjunto de ferramentas e recursos modulares que podem ser usados para melhorar a postura de segurança das suas cadeias de suprimentos de software. Ele mostra insights de segurança para aplicativos criados pelo Cloud Build. 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 declarações de vulnerabilidade, exploração e troca (VEX, na sigla em inglês) 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 criadas, os locais da origem de entrada, o conjunto de ferramentas de build, as etapas de build e a duração do build.

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

A seguir