Fonte de proteção

Este documento descreve as práticas recomendadas para gerenciar o código-fonte do software.

Uma etapa fundamental que as equipes de software precisam realizar para gerenciar a origem é adotar um sistema de controle de versões (VCS, na sigla em inglês). Os sistemas de controle de versão fornecem histórico e auditabilidade para mudanças. Sistemas de controle de versão hospedados, como o GitHub, oferecem outros benefícios, como disponibilidade, estabilidade, controles de segurança, ferramentas integradas de revisão de código e integração com outros serviços de nuvem.

Embora a maioria das equipes use o controle de versões atualmente, há muitas maneiras de configurar um sistema de controle de versões e as integrações dele com outras partes do pipeline de CI/CD.

Este documento aborda as considerações de segurança da cadeia de suprimentos de software para configurar um sistema de controle de versões. Ele descreve as práticas recomendadas de Níveis da cadeia de suprimentos para artefatos de software, um framework para proteger sua cadeia de suprimentos de software. O framework inclui requisitos em vários níveis para ajudar você a implementar mudanças de forma incremental, incluindo requisitos de origem.

Um sistema de controle de versões com histórico de alterações e revisões imutáveis é um requisito do nível 2 do SLSA. Recomendamos o alinhamento com o nível 2 do SLSA como um nível de referência inicial para a cadeia de suprimentos de software.

No nível 3 do SLSA, as plataformas de origem e de build aderem a requisitos de segurança mais rígidos, incluindo o histórico de origem verificado e a política de retenção de origem. O nível 4 da SLSA adiciona a revisão de duas pessoas aos requisitos de origem.

Usar o controle de versão para mais do que a origem do aplicativo

Armazenar a origem do aplicativo no controle de versões é uma prática bem estabelecida quando revisões históricas e auditorias são necessárias. No entanto, há outros tipos de origem que também se beneficiam do controle de versões, incluindo configuração, política e dados. Isso inclui arquivos que:

  • Afetam a disponibilidade e a segurança da sua infraestrutura de computação.
  • Requer colaboração para finalizar
  • Exigir um processo de aprovação repetível
  • Exigir um histórico de alterações

Por exemplo:

  • Infraestrutura como código: as organizações que querem gerenciar a infraestrutura de forma escalonável e segura usam a infraestrutura como código como uma metodologia importante. Por exemplo, é possível armazenar módulos do Terraform no controle de versão que criam repositórios do Artifact Registry.
  • Gerenciamento de configuração: é semelhante à infraestrutura como código, mas se concentra no gerenciamento da configuração do aplicativo com ferramentas como Ansible, Puppet e Chef. Você armazena e gerencia arquivos de configuração do aplicativo no sistema de controle de versões.
  • Configurações e scripts de migração de banco de dados: armazene a configuração e os scripts dos bancos de dados de produtos e de análise ou de registro.
  • Notebooks do Jupyter: há várias maneiras de trabalhar com notebooks armazenados no GitHub, incluindo a extensão para o JupyterLab, o Colaboratory e o Vertex AI Workbench.
  • Políticas de segurança: armazene arquivos de políticas para aplicação automatizada. Por exemplo, é possível armazenar políticas do Gatekeeper que permitem ou negam o comportamento de implantação no GKE ou políticas do Sentinel que impedem o Terraform de provisionar infraestrutura que viola a política.

O controle de versão é um dos recursos técnicos identificados pela pesquisa DevOps da DORA que aumenta a entrega de software e o desempenho organizacional. Armazenar scripts, código-fonte e arquivos de configuração no controle de versões ajuda a reproduzir e recuperar ambientes, rastrear e auditar mudanças e responder a defeitos rapidamente.

Configuração do repositório

Os repositórios são a unidade lógica fundamental para organizar o código e as funções, permissões, integrações e aprovações relacionadas.

Os problemas que podem ocorrer com a configuração do repositório incluem:

  • A configuração do repositório não é padronizada, por isso fica difícil garantir que a segurança do repositório seja adequada ao aplicativo que ele representa, principalmente no cenário comum em que uma organização tem centenas ou milhares de repositórios.
  • Quem cria o repositório se torna um proprietário com permissões administrativas totais, incluindo a capacidade de realizar mesclagens sem outros revisores.
  • A integração de repositórios com análise de código, servidores de build, rastreadores de problemas, serviços de notificação e outras partes da infraestrutura de CI/CD pode ser considerável. Ter uma maneira padrão de criar e configurar repositórios evita trabalho repetitivo e apoia as práticas recomendadas.

Para resolver esses problemas, as práticas recomendadas incluem:

  • Configure repositórios com um processo automatizado, repetível e voltado para a segurança. Por exemplo, é possível configurar módulos do Terraform que incorporam os requisitos de segurança do aplicativo para o qual o repositório é destinado. Aplicativos de alta segurança exigem mais aprovadores de mesclagem e diferentes do que apps de baixa segurança.
  • Crie uma maneira de os administradores de repositório selecionarem um conjunto de modelos de configuração de repositório que orientam a configuração de novos repositórios, em vez de configurar cada repositório do zero. Esses modelos precisam refletir os diferentes níveis de segurança dos seus aplicativos e ser sincronizados com as identidades de usuário necessárias para cada nível de segurança. Na prática, isso geralmente significa usar um sistema hierárquico de controle de acesso e identidade (IAM) que reflita os aplicativos e a infraestrutura da sua organização e os usuários responsáveis por eles.
  • Exija o gerenciamento centralizado de identidade com autenticação multifator para usuários do repositório.
    • O gerenciamento de identidade centralizado garante que, quando os usuários saem da organização ou passam para novas equipes, você mantém privilégio mínimo no gerenciamento de origem.
    • A autenticação multifator reduz significativamente o risco de phishing e outros tipos de ataques à sua fonte. A autenticação de dois fatores é um dos requisitos do nível 4 do SLSA para aprovadores de código.
  • Limite os proprietários do repositório a um pequeno número de funcionários de confiança. Isso pode exigir a integração do controle de versão com um sistema de gerenciamento de identidade e a capacidade de definir políticas mais altas na organização. Se possível, remova a capacidade dos proprietários de repositório de realizar mesclagens sem um segundo revisor.

Revisão de código

A revisão de código é a principal maneira de as organizações manterem a qualidade e a segurança do software. A revisão de código tenta resolver vários modos de falha, como:

  • Introdução de código com defeitos de software ou um design inflexível.
  • APIs mal definidas
  • Introdução de problemas de segurança devido a um código não seguro escrito pelo desenvolvedor
  • Introdução de problemas de segurança devido à adição de bibliotecas de terceiros que são inseguras ou podem se tornar inseguras.

Confira algumas maneiras de reduzir o risco:

  • Implemente a automatização de testes durante todo o ciclo de vida do software. O teste automatizado que é acionado quando você confirma a origem no sistema de controle de versão é uma maneira de os desenvolvedores receberem feedback rápido sobre problemas encontrados pelos testes.
  • Faça com que o número e a identidade dos revisores sejam adequados ao nível de segurança do aplicativo. Por exemplo, um app de intranet com pouco uso terá requisitos de segurança mais baixos do que um aplicativo de negócios essencial para o público.
  • Atribua revisores com base na experiência técnica e no nível de confiança necessário para a mudança na confirmação. O revisor precisa ser um especialista no idioma que está sendo revisado, nos sistemas com que o código interage e nos riscos de segurança nessa classe de aplicativo. O requisito de experiência técnica tem muitas dimensões. Por exemplo:
    • O código é legível?
    • É seguro?
    • Ele está usando bibliotecas de terceiros adequadas?
    • Há um processo de proteção de bibliotecas de terceiros?
    • O código é combinável?
    • O design da API segue as práticas recomendadas?

  • As avaliações não devem ser uma etapa burocrática, mas uma conversa contínua sobre práticas recomendadas. Crie listas de verificação, guias de estilo e padrões de design para cada parte da sua pilha de tecnologia, além de programas educacionais para novos desenvolvedores. Alguns ambientes de desenvolvimento integrado, como o VS Code e o IntelliJ, fornecem linters que podem sinalizar automaticamente erros programáticos ou estilísticos. Os linters ajudam os desenvolvedores a criar um código mais consistente e permitem que os revisores de código se concentrem mais em problemas que não são fáceis de identificar com verificações automatizadas.

    Desenvolvimento de software seguro é um curso on-line gratuito criado pela Open Source Security Foundation (OpenSSF, na sigla em inglês). Ele descreve práticas de desenvolvimento de software fundamentais no contexto da segurança da cadeia de suprimentos de software.

  • Realize revisões de código com solicitações de pull de ramificação de recursos assim que um desenvolvedor individual estiver pronto. Não espere até que uma nova versão seja colocada em teste para fazer verificações de segurança e revisão de código.

  • Integrar a verificação de vulnerabilidades, incluindo a verificação de bibliotecas de terceiros, em solicitações de pull e ambientes de desenvolvimento integrado ajuda a identificar problemas o mais rápido possível. A API On-Demand Scanning no Google Cloud permite verificar contêineres localmente em busca de vulnerabilidades.

  • Integre testes automatizados antes da mesclagem para que os desenvolvedores possam identificar e corrigir mudanças que vão quebrar o aplicativo. Saiba mais sobre a automação de testes.

Mesclar aprovações

Em pipelines de CI/CD integrados continuamente, a mesclagem de código em um ramo de produção pode resultar em mudanças downstream, incluindo build e lançamento automatizados. Por esse motivo, proteger quem pode fazer a mesclagem é uma parte essencial da segurança de implantações de software. Inclui as seguintes considerações:

  • Configure proprietários de filiais protegidas nas filiais de produção. O número e a identidade das pessoas autorizadas a mesclar precisam ser adequados aos requisitos de segurança do aplicativo. O nível 4 do SLSA exige dois aprovadores com autenticação forte, mas o número de aprovadores precisa ser adequado ao conteúdo do repositório.
  • Controle com rigor as identidades dos proprietários do repositório, já que na maioria dos sistemas de controle de versão, eles podem realizar mesclagens por conta própria.
  • Separar os processos de aprovação de implantação e mesclagem para lançamentos de vários repositórios e artefatos.

Ferramentas para proteger o desenvolvimento

O Google Cloud oferece um conjunto de ferramentas e recursos modulares que podem ser usados para melhorar a postura de segurança da cadeia de suprimentos de software. Os componentes a seguir ajudam a proteger o código-fonte do software:

  • Cloud Workstations (pré-lançamento)

    O Cloud Workstations oferece ambientes de desenvolvimento totalmente gerenciados no Google Cloud. Ele permite que administradores de TI e de segurança provisionem, escalonizem, gerenciem e protejam facilmente os ambientes de desenvolvimento e permite que os desenvolvedores acessem ambientes de desenvolvimento com configurações consistentes e ferramentas personalizáveis.

    Cloud Workstations ajudam a mudar a segurança para a esquerda, melhorando a postura de segurança dos seus ambientes de desenvolvimento de aplicativos. Ele tem recursos de segurança, como VPC Service Controls, entrada ou saída particulares, atualização forçada de imagens e políticas de acesso do Identity and Access Management. Para mais informações, consulte a documentação do Cloud Workstations.

  • Proteção source protect Cloud Code (pré-lançamento)

    O Cloud Code oferece suporte a ambientes de desenvolvimento integrado para criar, implantar e integrar aplicativos com o Google Cloud. Ele permite que os desenvolvedores criem e personalizem um novo aplicativo a partir de modelos de amostra e executem o aplicativo finalizado. A source protect do Cloud Code oferece feedback de segurança em tempo real para os desenvolvedores, como a identificação de dependências vulneráveis e relatórios de licença, enquanto eles trabalham nos IDEs. Ele fornece feedback rápido e útil que permite que os desenvolvedores façam correções no código no início do processo de desenvolvimento de software.

    Disponibilidade do recurso: source protect código do Cloud Code não está disponível para acesso público. Para ter acesso a esse recurso, consulte a página de solicitação de acesso.

A seguir