Salvaguardar origem

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

Um passo fundamental que as equipas de software dão para gerir a respetiva origem é a adoção de um sistema de controlo de versões (VCS). Os sistemas de controlo de versões oferecem histórico e capacidade de auditoria para alterações. Os sistemas de controlo de versões alojados, como o GitHub, oferecem vantagens adicionais, como disponibilidade, estabilidade, controlos de segurança, ferramentas de revisão de código integradas e integração com outros serviços na nuvem.

Embora a maioria das equipas use o controlo de versões atualmente, existem muitas formas de configurar um sistema de controlo de versões e as respetivas integrações com outras partes do pipeline de CI/CD.

Este documento explora as considerações de segurança da cadeia de abastecimento de software para configurar um sistema de controlo de versões. Descreve as práticas recomendadas dos níveis da cadeia de abastecimento para artefactos de software, um framework para salvaguardar a sua cadeia de abastecimento de software. A estrutura inclui requisitos a vários níveis para ajudar a implementar alterações de forma incremental, incluindo requisitos de origem.

Um sistema de controlo de versões com histórico de alterações e revisões imutáveis é um requisito de nível 2 da SLSA. Recomendamos o alinhamento com o nível 2 da SLSA como um nível de base inicial para a sua cadeia de fornecimento de software.

No nível 3 da SLSA, as plataformas de origem e de compilação cumprem requisitos de segurança mais rigorosos, incluindo o histórico de origem validado e a política de retenção de origem. O nível 4 da SLSA adiciona revisões de duas pessoas aos requisitos de origem.

Use o controlo de versões para mais do que a origem da sua aplicação

Armazenar a origem da aplicação no controlo de versões é uma prática bem estabelecida quando são necessárias revisões e auditorias históricas. No entanto, existem outros tipos de origens que também beneficiam do controlo de versões, incluindo a configuração, a política e os dados. Isto inclui todos os ficheiros que:

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

Alguns exemplos:

  • Infraestrutura como código: as organizações que querem gerir a respetiva infraestrutura de forma escalável e segura usam a infraestrutura como código como uma metodologia fundamental. Por exemplo, pode armazenar módulos do Terraform no controlo de versões que criam repositórios do Artifact Registry.
  • Gestão da configuração: a gestão da configuração é semelhante à infraestrutura como código, mas foca-se na gestão da configuração da aplicação com ferramentas como o Ansible, o Puppet e o Chef. Armazena e gere ficheiros de configuração de aplicações no seu sistema de controlo de versões.
  • Configurações da base de dados e scripts de migração: armazene a configuração e os scripts para as bases de dados de produtos e as bases de dados de estatísticas ou registo.
  • Blocos de notas Jupyter: existem várias formas de trabalhar com blocos de notas armazenados no GitHub, incluindo a extensão para o JupyterLab, o Colaboratory e o Vertex AI Workbench
  • Políticas de segurança: armazene ficheiros de políticas para a aplicação automática de políticas. Por exemplo, pode armazenar políticas do Gatekeeper que permitem ou negam o comportamento de implementação no GKE ou políticas do Sentinel que impedem o Terraform de aprovisionar infraestrutura que viole a política.

O controlo de versões é uma das capacidades técnicas identificadas pela investigação da DORA DevOps que impulsiona um maior desempenho organizacional e de entrega de software. O armazenamento dos seus scripts, código fonte e ficheiros de configuração no controlo de versões ajuda a reproduzir e recuperar ambientes, rastrear e auditar alterações, e responder rapidamente a defeitos.

Configuração do repositório

Os repositórios são a unidade lógica fundamental para organizar o código e as funções, as autorizações, as integrações e as 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, pelo que se torna difícil garantir que a segurança do repositório é adequada à aplicação que representa, particularmente no cenário comum em que uma organização tem centenas ou milhares de repositórios.
  • Quem cria o repositório torna-se proprietário com autorizações administrativas completas, incluindo a capacidade de realizar unificações sem outros revisores.
  • A integração de repositórios com a análise de código, os servidores de compilação, os rastreadores de problemas, os serviços de notificação e outras partes da infraestrutura de CI/CD pode ser um trabalho considerável. Ter uma forma padrão de criar e configurar repositórios evita trabalho repetitivo e suporta as práticas recomendadas.

Para resolver estes problemas, as práticas recomendadas incluem

  • Configure repositórios com um processo automatizado, repetível e consciente da segurança. Por exemplo, pode configurar módulos do Terraform que incorporam os requisitos de segurança da aplicação a que o repositório se destina. As aplicações de alta segurança requerem mais aprovadores de união e diferentes dos das apps de segurança inferior.
  • Criar uma forma de os administradores do repositório selecionarem a partir de um conjunto de modelos de configuração do repositório que orientam a nova configuração do repositório, em vez de configurar cada repositório de raiz. Estes modelos devem refletir os diferentes níveis de segurança das suas aplicações e ser sincronizados com as identidades dos utilizadores necessárias para cada nível de segurança. Na prática, isto significa normalmente usar um sistema de identidade e controlo de acesso (IAM) hierárquico que reflete as aplicações e a infraestrutura na sua organização, bem como os utilizadores responsáveis por elas.
  • Exija a gestão de identidade centralizada com autenticação multifator para utilizadores do repositório.
    • A gestão de identidades centralizada garante que, quando os utilizadores saem da organização ou mudam para novas equipas, mantém o menor privilégio possível em torno da gestão de fontes.
    • 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 da SLSA para aprovadores de código.
  • Limite os proprietários do repositório a um pequeno número de funcionários fidedignos. Isto pode exigir a integração do controlo de versões com um sistema de gestão de identidades e a transferência da capacidade de definir políticas para um nível superior na organização. Se possível, remova a capacidade de os proprietários do repositório realizarem uniões sem um segundo revisor.

Revisão de código

A revisão de código é a principal forma de as organizações manterem a qualidade e a segurança do respetivo 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 não seguro escrito pelo programador
  • Introdução de problemas de segurança devido à adição de bibliotecas de terceiros que são inseguras ou podem tornar-se inseguras.

Seguem-se algumas formas de mitigar o risco:

  • Implemente a automatização de testes ao longo do ciclo de vida do software. Os testes automatizados acionados quando confirma a origem no sistema de controlo de versões são uma forma de os programadores receberem rapidamente feedback sobre problemas encontrados pelos testes.
  • Certifique-se de que o número e a identidade dos revisores são adequados ao nível de segurança da aplicação. Por exemplo, uma app de intranet com baixa utilização tem requisitos de segurança inferiores aos de uma aplicação empresarial crítica acessível publicamente.
  • Atribua revisores com base nos conhecimentos técnicos e no nível de confiança necessários para a alteração na confirmação. O revisor deve ser um especialista no idioma que está a ser revisto, nos sistemas com os quais o código interage e nos riscos de segurança nesta classe de aplicação. O requisito de especialização técnica tem muitas dimensões. Por exemplo:
    • O código é legível?
    • É seguro?
    • Está a usar bibliotecas de terceiros adequadas?
    • Existe um processo de proteção de bibliotecas de terceiros?
    • O código é compondo?
    • O design da API segue as práticas recomendadas?

  • As revisões não devem ser um passo burocrático, mas sim uma conversa contínua sobre as práticas recomendadas. Crie listas de verificação, guias de estilo e normas de design em torno de cada parte da sua pilha de tecnologia, juntamente com programas educativos para novos programadores. Alguns IDEs, como o VS Code e o IntelliJ, fornecem analisadores estáticos que podem sinalizar automaticamente erros programáticos ou estilísticos. Os analisadores estáticos ajudam os programadores a criar 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 automáticas.

    Developing Secure Software é um curso online gratuito criado pela Open Source Security Foundation (OpenSSF). Descreve as práticas fundamentais de programação de software no contexto da segurança da cadeia de abastecimento de software.

  • Realize revisões de código com pedidos de obtenção de ramificações de funcionalidades assim que um programador individual estiver pronto. Não espere até imediatamente antes de uma nova versão ser colocada em teste para fazer verificações de segurança e revisão de código.

  • A integração da análise de vulnerabilidades, incluindo a análise de bibliotecas de terceiros, em pedidos de obtenção e IDEs ajuda a identificar problemas assim que possível. A API On-Demand Scanning no Google Cloud permite-lhe analisar localmente os contentores em busca de vulnerabilidades.

  • Integre testes automatizados de pré-união para que os programadores possam identificar e corrigir alterações que vão danificar a aplicação. Saiba mais sobre a automatização de testes.

Unir aprovações

Em pipelines de CI/CD integrados continuamente, a união de código num ramo de produção pode resultar em alterações a jusante, incluindo a compilação e a implementação automatizadas. Por este motivo, garantir quem pode fazer a união é uma parte fundamental da proteção das implementações de software. As considerações incluem:

  • Configure proprietários de ramificações protegidas nas suas ramificações de produção. O número e a identidade das pessoas autorizadas a fazer a união devem ser adequados aos requisitos de segurança da aplicação. O nível 4 da SLSA requer dois aprovadores fortemente autenticados, mas o número de aprovadores deve ser adequado ao conteúdo do repositório.
  • Controlar rigorosamente as identidades dos proprietários do repositório, uma vez que, na maioria dos sistemas de controlo de versões, estes podem realizar as unificações por si próprios.
  • Separe os processos de aprovação de implementação e união para implementações progressivas com vários repositórios e vários artefactos.

Ferramentas para o desenvolvimento seguro

Google Cloud oferece um conjunto de capacidades e ferramentas modulares que pode usar para melhorar o comportamento de segurança da sua cadeia de abastecimento de software. Os seguintes componentes ajudam a proteger o código-fonte do software:

  • Cloud Workstations (pré-visualização)

    O Cloud Workstations oferece ambientes de desenvolvimento totalmente geridos no Google Cloud. Permite que os administradores de TI e segurança aprovisionem, dimensionem, façam a gestão e protejam facilmente os respetivos ambientes de desenvolvimento, e permite que os programadores acedam a ambientes de desenvolvimento com configurações consistentes e ferramentas personalizáveis.

    As Cloud Workstations ajudam a deslocar a segurança para a esquerda, melhorando a postura de segurança dos seus ambientes de desenvolvimento de aplicações. Tem funcionalidades de segurança, como VPC Service Controls, entrada ou saída privadas, atualização forçada de imagens e políticas de acesso de gestão de identidade e de acesso. Para mais informações, consulte a documentação do Cloud Workstations.

  • Proteção de origem do Cloud Code (pré-visualização)

    O Cloud Code oferece suporte de IDE para criar, implementar e integrar aplicações com o Google Cloud. Permite aos programadores criar e personalizar uma nova aplicação a partir de modelos de exemplo e executar a aplicação concluída. O Cloud Code Source Protect oferece aos programadores feedback de segurança em tempo real, como a identificação de dependências vulneráveis e relatórios de licenças, enquanto trabalham nos respetivos IDEs. Fornece feedback rápido e acionável que permite aos programadores fazer correções ao respetivo código no início do processo de programação de software.

    Disponibilidade de funcionalidades: a proteção de origem do Cloud Code não está disponível para acesso público. Para aceder a esta funcionalidade, consulte a página de pedido de acesso.

O que se segue?