Proteger builds

Este documento descreve as práticas recomendadas para proteger suas versões. O código de construçã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 closure Compiler analisa e analisa o JavaScript, remove o código morto, reescreve e minimiza o que resta. Ela também verifica o código em busca de armadilhas comuns do JavaScript.
  • Compilar código em código intermediário: por exemplo, você pode 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, compilação de 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: por exemplo, criar arquivos Java WAR (.war) a partir de arquivos de classe Java, criar uma imagem do Docker ou criar 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. Por exemplo, um build pode empacotar o código Python em uma distribuição criada e fazer upload dele para um armazenamento de artefatos como o Artifact Registry ou o PyPI, para que você possa usá-lo como dependência no 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 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 automatizados

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

Por exemplo, um script de compilação pode ser:

  • Um cloudbuild.yaml do Cloud Build.
  • Um Makefile que você executa 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 possam ser úteis para fins de depuração, a liberação de software de builds locais pode introduzir muitas preocupações de segurança, inconsistências e ineficiências no processo de build.

  • Permitir builds locais permite que um invasor com intenção maliciosa modifique o processo de compilação.
  • As inconsistências nos ambientes locais e nas práticas do desenvolvedor dificultam a reprodução e o diagnóstico de problemas.

Criações manuais tornam o processo ineficiente ao aproveitar mais recursos de infraestrutura, como computação, armazenamento e redes. Nos requisitos do framework SLSA, os builds automatizados são um requisito da SLSA de nível 1, e o uso de um serviço de build em vez de ambientes de desenvolvedor para builds é um requisito para a SLSA de nível 2.

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 criação ao Cloud Build. É possível configurar builds para buscar dependências, executar testes de unidade, análises estáticas e testes de integração, além de 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, além de ambientes de execução, como GKE e Cloud Run. Ele também oferece integração com os principais sistemas de gerenciamento de código-fonte, como GitHub e 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 e a duração da compilação.

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

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

É possível usar mecanismos de alerta e política para aproveitar de maneira proativa os dados de procedência da criação. Por exemplo, é possível criar políticas que permitam apenas implantações de código criado a partir de origens verificadas.

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

  • Gerados pelo serviço de build ou podem ser lidos diretamente pelo serviço de build.
  • Verificado por um consumidor quanto à autenticidade e à integridade. Isso precisa ser feito com uma assinatura digital gerada pelo serviço que cria os dados de proveniência de build.

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

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

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

Usar um ambiente de build temporário

Ambientes temporários são ambientes temporários feitos para durar uma única invocação de build. Após a criação, o ambiente é excluído permanentemente ou excluído. As versões temporárias garantem que o serviço e as etapas de criação sejam executados 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.

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 temporário oferece aos invasores a oportunidade de injetar arquivos e conteúdos maliciosos. Esse ambiente 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 a criação.

Restringir o acesso ao serviço de build

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

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 seu 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 da organização Integrações permitidas do Cloud Build para controlar os serviços externos que têm permissão para invocar acionadores de versão.

  • 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 dele, mas limita a comunicação com base nas regras especificadas. O perímetro também reduz o risco de exfiltração de dados.

    O Cloud Build só é compatível com o VPC Service Controls para builds executados em um pool particular.

Proteger credenciais

As versões geralmente incluem conexões com outros sistemas, como controle de versões, armazenamentos de artefatos e ambientes de implantação. Proteger as credenciais que você usa nas versões ajuda a evitar o acesso não autorizado a sistemas na sua cadeia de suprimentos de software e a exfiltração de dados.

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

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

Gerenciar suas dependências

A integridade dos aplicativos depende da integridade do código desenvolvido e de todas as dependências usadas. Também é preciso considerar onde você publica as dependências, quem tem acesso de leitura e gravação nos repositórios de artefatos e as políticas de fontes confiáveis de artefatos de build implantados nos ambientes de execução.

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

No Cloud Build, você usa criadores de nuvem para executar comandos. 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, os builders fornecidos pelo Cloud Build, os criados pela comunidade e os personalizados criados por você. Também é possível usar buildpacks como builders, incluindo buildpacks do Google Cloud.

Revise os criadores que você usa nos builds do Cloud Build, descubra quem os fornece e decida se você confia neles na sua cadeia de suprimentos de software. Para manter mais controle sobre o código em um builder, crie builders personalizados em vez de usar de uma fonte pública.

Reduzir as oportunidades para alterar a construção

Há diversos outros fatores que podem influenciar uma criação, incluindo:

  • Builds que são executados simultaneamente e capazes de influenciar uns aos outros ou um build que persiste e afeta um build seguinte.
  • Builds que aceitam parâmetros do 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 risco para que as versões usem versões inválidas ou indesejadas de dependências.

As práticas a seguir ajudam a reduzir 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 influenciar as variáveis definidas nos scripts de build.
  • Restrinja 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 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.

Siga as práticas recomendadas para criar contêineres

Consulte as práticas recomendadas para criar contêineres e aprenda maneiras de criar imagens de contêiner que sejam mais confiáveis e menos vulneráveis a ataques, incluindo:

  • Como empacotar aplicativos únicos
  • Manuseio de processos
  • Como otimizar o cache de criação do Docker
  • Remover ferramentas desnecessárias e manter as imagens com o menor tamanho possível
  • Verificar vulnerabilidades com o Artifact Analysis. É possível verificar imagens armazenadas no Artifact Registry ou verificá-las localmente antes de armazenar.
  • Práticas recomendadas de inclusão de tag
  • Considerações de segurança para usar imagens públicas

Software Delivery Shield

O Software Delivery Shield é uma solução totalmente gerenciada de segurança da cadeia de suprimentos de software. Ele fornece um conjunto abrangente e modular de recursos e ferramentas nos serviços do Google Cloud que os desenvolvedores, DevOps e equipes de segurança podem usar para melhorar a postura de segurança da cadeia de suprimentos de software. Ele exibe insights de segurança de aplicativos criados na IU 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 declarações Vulnerability Exploitability eXchange (Vulnerability) para artefatos de build.
  • A procedência da versão, que é uma coleção de metadados verificáveis sobre ela. Ele inclui detalhes como os resumos das imagens criadas, os locais das origens de entrada, o conjunto de ferramentas, as etapas e a duração da versão.

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

A seguir