Proteção da fonte

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

Uma etapa fundamental que as equipes de software adotam para gerenciar a origem é a adoção de um sistema de controle de versões (VCS, na sigla em inglês). Os sistemas de controle de versões fornecem histórico e capacidade de auditoria para mudanças. Os sistemas de controle de versões 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 explora 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 dos 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 mudanças 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 sua 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 fortes, incluindo histórico de origem verificado e política de retenção de origem. O nível 4 do SLSA adiciona revisões de duas pessoas aos requisitos de origem.

Usar o controle de versões 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 todos os arquivos que:

  • Afetam a disponibilidade e a segurança da infraestrutura de computação
  • Exigem colaboração para serem finalizados
  • Exigem um processo de aprovação repetível
  • Exigem um histórico de mudanças

Por exemplo:

  • Infraestrutura como código: as organizações que querem gerenciar a infraestrutura de maneira escalonável e segura usam a infraestrutura como código como uma metodologia fundamental. Por exemplo, é possível armazenar módulos do Terraform no controle de versões que criam repositórios do Artifact Registry.
  • Gerenciamento de configuração: o 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 de aplicativos no sistema de controle de versões.
  • Configurações de banco de dados e scripts de migração: armazene a configuração e os scripts dos bancos de dados de produtos e de análise ou registro de dados.
  • Notebooks Jupyter: há várias maneiras de trabalhar com notebooks armazenados no GitHub, incluindo a extensão para JupyterLab, Colaboratory e Vertex AI Workbench
  • Políticas de segurança: armazene arquivos de política para aplicação automatizada de políticas. 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 que o Terraform provisione infraestrutura que viole a política.

O controle de versões é um dos recursos técnicos identificados pela pesquisa do DORA DevOps que impulsiona 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 os papéis, permissões, integrações e aprovações relacionados.

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

  • A configuração do repositório não é padronizada, então 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 completas, 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 um trabalho considerável. Ter uma maneira padrão de criar e configurar repositórios economiza trabalho repetitivo e oferece suporte a práticas recomendadas.

Para resolver esses problemas, as práticas recomendadas incluem

  • Configure repositórios com um processo automatizado, repetível e com foco na 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 é. Aplicativos de alta segurança exigem mais e diferentes aprovadores de mesclagem do que aplicativos de segurança mais baixa.
  • Crie uma maneira para que os administradores do repositório selecionem um conjunto de modelos de configuração de repositório que impulsionam a nova configuração do repositório em vez de configurar cada repositório do zero. Esses modelos precisam refletir os diferentes níveis de segurança dos 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 identidade e controle de acesso (IAM) que reflita os aplicativos e a infraestrutura da sua organização e os usuários responsáveis por eles.
  • Exija o gerenciamento de identidade centralizado 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 mudam para novas equipes, você mantenha o privilégio mínimo em relação ao gerenciamento de origem.
    • A autenticação multifator reduz significativamente o risco de phishing e outros tipos de ataques à sua origem. 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 confiáveis. Isso pode exigir a integração do controle de versões 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 de os proprietários do repositório realizarem 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 código inseguro 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.

Algumas maneiras de mitigar o risco incluem:

  • Implemente a automaçã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ões é uma maneira de os desenvolvedores receberem feedback rápido sobre problemas encontrados pelos testes.
  • Defina o número e a identidade dos revisores 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 comercial crítico voltado ao público.
  • Atribua revisores com base na experiência técnica e no nível de confiança necessário para a mudança no commit. O revisor precisa ser um especialista na linguagem que está sendo revisada, 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?
    • Ele é 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 revisõ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 em 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.

    O curso on-line sem custo financeiro Developing Secure Software foi criado pela Open Source Security Foundation (OpenSSF). Ele descreve as práticas fundamentais de desenvolvimento de software no contexto da segurança da cadeia de suprimentos de software.

  • Realize revisões de código com solicitações de envio de ramificações de recursos assim que um desenvolvedor individual estiver pronto. Não espere até pouco antes de um novo lançamento ser colocado em teste para fazer verificações de segurança e revisão de código.

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

  • Integre testes automatizados de pré-mesclagem para que os desenvolvedores possam identificar e corrigir mudanças que vão interromper o aplicativo. Saiba mais sobre a automação de testes.

Aprovações de mesclagem

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

  • Configure proprietários de ramificações protegidas nas ramificações 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 rigorosamente as identidades dos proprietários do repositório, já que, na maioria dos sistemas de controle de versões, eles podem realizar mesclagens por conta própria.
  • Separe os processos de implantação e aprovação de mesclagem para lançamentos de vários repositórios e artefatos.

Ferramentas para proteger o desenvolvimento

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

  • Cloud Workstations (prévia)

    O Cloud Workstations oferece ambientes de desenvolvimento totalmente gerenciados no Google Cloud. Ele permite que os administradores de TI e segurança provisionem, escalonem, 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.

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

  • Cloud Code source protect (prévia)

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

    Disponibilidade de recursos: o Cloud Code source protect 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