Proteger versões

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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

  • Otimizar ou ofuscar código: por exemplo, a ferramenta de código aberto Closure Compiler do Google analisa e analisa JavaScript, remove o código inativo e reescreve e minimiza o que resta. Ela também verifica o código em busca de armadilhas comuns do JavaScript.
  • Como compilar código em código intermediário: por exemplo, você pode compilar o 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, criando uma biblioteca ou um arquivo executável: por exemplo, compilando o código C++ em uma biblioteca compartilhada (.so) ou um arquivo executável do Windows (.exe).
  • Empacotar código em um formato distribuível ou implantável: os exemplos incluem a criação de arquivos Java WAR (.war) de arquivos de classe Java, a criação de uma imagem do Docker ou a criação de uma distribuição criada para Python (.whl).

Sua versão pode conter diferentes combinações dessas operações, dependendo da linguagem de programação que você usa e do ambiente em que faz a implantação. Por exemplo, um build pode empacotar um 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 uma 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 deste 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

Uma build automática ou build com script define todas as etapas de compilação no script ou na 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 de executar a versão.

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 Actions do GitHub no formato YAML armazenado no diretório .github/workflows/.

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

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

  • Permitir versões locais oferece uma maneira de um invasor com intenção maliciosa modificar o processo de compilação.
  • inconsistências nos ambientes e práticas locais do desenvolvedor dificultam a reprodução de builds e o diagnóstico de problemas de build.

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

O Cloud Build é o serviço de compilação gerenciado no Google Cloud. Ele usa um arquivo de configuração de compilação para fornecer etapas de versão ao Cloud Build. Você pode configurar versões para buscar dependências, executar testes de unidade, análises estáticas e testes de integração e criar artefatos com ferramentas de compilação, 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 Google Cloud Deploy, bem como a ambientes de execução, como o GKE e o Cloud Run, além de fornecer integração com os principais sistemas de gerenciamento de código-fonte, como GitHub e Bitbucket.

Gerar procedência do build

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

Esses metadados incluem detalhes como os resumos das imagens criadas, os locais de origem de entrada, o conjunto de ferramentas de compilação e a duração da compilação.

Gerar procedência do build ajuda você a:

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

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

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

  • Gerado pelo serviço de compilação ou legível diretamente pelo serviço de compilação.
  • Verificado por um consumidor para autenticidade e integridade. Isso precisa ser feito com uma assinatura digital gerada pelo serviço que cria os dados de procedência da versão.

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

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

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

Usar um ambiente de build temporário

Os ambientes efêmeros são temporários e precisam durar uma única invocação do build. Após a criação, o ambiente é excluído permanentemente ou excluído. As versões efêmeras garantem que o serviço de compilação e as etapas de compilaçã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 depois o destrói após a conclusão do processo.

Ambientes efêmeros garantem builds limpos, já que não há arquivos residuais ou configurações de ambiente de builds anteriores que podem interferir no processo de build. Um ambiente não temporário oferece uma oportunidade para os invasores injetarem arquivos e conteúdos 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 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 ao conceder as permissões mínimas necessárias para o serviço de compilação e os recursos de compilação. Use 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 o mínimo de permissões 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 ele 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 podem invocar os gatilhos de compilaçã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 do perímetro, mas limita a comunicação por todo o perímetro com base nas regras que você especifica. O perímetro também reduz o risco de exfiltração de dados.

    O Cloud Build oferece suporte apenas ao VPC Service Controls para builds executados em um pool privado.

Proteger credenciais

Os builds geralmente incluem conexões com outros sistemas, como controle de versões, armazenamentos de artefatos e ambientes de implantação. A proteção de credenciais usadas nas versões evita o acesso não autorizado aos sistemas na 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 compilação. 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 confidenciais. É 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 das dependências usadas. Também é preciso considerar onde você publica suas dependências, que têm acesso de leitura e gravação aos repositórios de artefatos, e políticas para fontes confiáveis de artefatos de compilação implantados nos ambientes de execução.

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

No Cloud Build, use builders de nuvens para executar comandos. Builders são imagens de contêiner com linguagens e ferramentas comuns instaladas neles. É 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 que você cria. Também é possível usar buildpacks como builders, incluindo buildpacks do Google Cloud.

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

Reduzir oportunidades para alterar o build

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

  • Builds que são executados simultaneamente e que podem influenciar uns aos outros ou um build que persiste e afeta um build subsequente.
  • 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 mutáveis, por exemplo, usando uma imagem com a tag latest. Essas abordagens criam risco para que as versões usem versões ruins ou indesejadas de dependências.

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

  • Execute cada build em um ambiente efêmero.
  • Evite executar builds com outros parâmetros para que os usuários não influenciem variáveis definidas nos scripts de compilação.
  • Restringir o acesso ao serviço e aos recursos de compilação.
  • Faça referência a versões imutáveis de dependências em vez de identificadores, como tags que podem indicar uma versão diferente do artefato no futuro. Para ver 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 para saber mais sobre as maneiras de criar imagens de contêiner que sejam mais confiáveis e menos vulneráveis a ataques, incluindo:

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

Software Delivery Shield

O Software Delivery Shield é uma solução de segurança de cadeia de suprimentos de software totalmente gerenciada e totalmente gerenciada. Ele fornece um conjunto abrangente e modular de recursos e ferramentas nos serviços do Google Cloud que as equipes de desenvolvedores, DevOps e segurança podem usar para melhorar a postura de segurança da cadeia de suprimentos de software. Ele exibe insights de segurança para aplicativos criados na IU do Cloud Build no Console do Google Cloud. Incluindo:

  • o nível da SLSA, que identifica o nível de maturidade da segurança da cadeia de suprimentos do seu software.
  • Vulnerabilidades em artefatos de versão.
  • 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 de origem de entrada, o conjunto de ferramentas de compilação, as etapas de compilação e a duração da compilação.

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

A seguir