Proteger fonte

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

Uma etapa fundamental que as equipes de software realizam 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 auditoria das alterações. Os 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 em nuvem.

A maioria das equipes usa o controle de versões atualmente, mas 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.

Neste documento, exploramos as considerações sobre a segurança da cadeia de suprimentos de software para configurar um sistema de controle de versões. Aqui você encontra as práticas recomendadas em 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 incrementalmente, incluindo requisitos de origem.

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

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

Usar o controle de versões além da origem do aplicativo

Armazenar a origem do aplicativo no controle de versões é uma prática bem estabelecida quando revisões e auditorias históricas 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:

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

Por exemplo:

  • Infraestrutura como código: organizações que querem gerenciar a infraestrutura de maneira escalonável e segura usam a infraestrutura como código como metodologia principal. 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: o gerenciamento de configurações é semelhante à infraestrutura como código, mas se concentra no gerenciamento da configuração de aplicativos 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 de geração de registros.
  • Notebooks Jupyter: há várias maneiras de trabalhar com notebooks armazenados no GitHub, incluindo a [extensão para JupyterLab][jlab], Colaboratory e [Vertex AI Workbench][vertex]
  • Políticas de segurança: armazene os arquivos de políticas para a aplicação automática de políticas. Por exemplo, é possível armazenar políticas do Gatekeeper que permitem ou negam o comportamento da implantação no GKE ou políticas da Sentinel que impedem o Terraform de provisionar a infraestrutura que viola a política.

O controle de versões é um dos recursos técnicos identificados pela pesquisa 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 você a reproduzir e recuperar ambientes, rastrear e auditar alterações, além de 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 papéis, permissões, integrações e aprovações relacionados.

Estes são alguns problemas que podem ocorrer com a configuração do repositório:

  • A configuração do repositório não é padronizada, por isso é difícil garantir que a segurança do repositório seja apropriada para o aplicativo que ele representa, especialmente no cenário comum em que uma organização tem centenas ou milhares de repositórios.
  • A pessoa que cria o repositório se torna um proprietário com permissões administrativas completas, incluindo a capacidade de fazer mesclagens sem nenhum outro revisor.
  • A integração de repositórios com análise de código, servidores de criação, rastreadores de problemas, serviços de notificação e outras partes da infraestrutura de CI/CD pode ser uma tarefa considerável. Ter uma maneira padrão de criar e configurar repositórios salva o trabalho repetitivo e oferece suporte às 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 a que o repositório se destina. Aplicativos de alta segurança exigem mais e mais aprovadores de mesclagem do que apps de segurança inferior.
  • Crie uma maneira para os administradores de repositório selecionarem um conjunto de modelos de configuração de repositório que impulsionam 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 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 reflete os aplicativos e a infraestrutura na sua organização e os usuários responsáveis por eles.
  • Exija o gerenciamento centralizado de identidades com autenticação multifator para usuários de repositórios.
    • O gerenciamento centralizado de identidade garante que, quando os usuários saem da organização ou migram para novas equipes, você mantenha privilégio mínimo no gerenciamento da 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 SLSA de nível 4 para aprovadores de código.
  • Limite os proprietários de repositórios 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 identidades e mover a capacidade de definir políticas para um nível mais alto na organização. Se possível, remova a capacidade dos proprietários do repositório fazerem 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 dos softwares. 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 desenvolvedor
  • Introdução de problemas de segurança devido à adição de bibliotecas de terceiros que não são seguras ou podem se tornar não seguras.

Estas são algumas maneiras de mitigar riscos:

  • Implemente a automação de teste durante todo o ciclo de vida do software. Os testes automatizados, acionados quando você confirma a origem no sistema de controle de versões, são uma maneira dos desenvolvedores receberem feedback rapidamente sobre os 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 aplicativo de intranet com pouco uso terá requisitos de segurança menores do que um aplicativo essencial para os negócios 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 especialista na linguagem revisada, nos sistemas com que o código interage e nos riscos de segurança nessa classe de aplicativo. O requisito de conhecimento técnico tem muitas dimensões. 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 está seguindo 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 pilha de tecnologia, além de programas educacionais para novos desenvolvedores. Alguns ambientes de desenvolvimento integrado, como o VS Code e o IntelliJ, fornecem lints que podem sinalizar automaticamente erros programáticos ou de estilo. Os linters ajudam os desenvolvedores a criar códigos mais consistentes e permitem que os revisores se concentrem mais em problemas que não são fáceis de identificar com verificações automatizadas.

    Developing Secure Software é um curso on-line gratuito criado pela Open Source Security Foundation (OpenSSF). Ele descreve 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ção de recursos assim que um desenvolvedor individual estiver pronto. Não espere um pouco antes que uma nova versão seja colocada 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. A API On-Demand Scanning no Google Cloud permite que você verifique contêineres localmente em busca de vulnerabilidades.

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

Aprovações de mesclagem

Em pipelines de CI/CD integrados continuamente, mesclar o código em uma ramificação de produção pode resultar em alterações downstream, incluindo criação e lançamento automatizados. Por esse motivo, proteger quem pode mesclar é uma parte essencial para proteger as implantações de software. As considerações incluem:

  • Configurar proprietários de ramificações protegidas nas ramificações de produção. O número e a identidade das pessoas que podem ser mescladas precisam ser adequados aos requisitos de segurança do aplicativo. O SLSA nível 4 requer dois aprovadores fortemente autenticados, mas o número de aprovadores precisa ser adequado ao conteúdo do repositório.
  • controlar rigidamente as identidades dos proprietários do repositório, já que eles podem fazer mesclagens na maioria dos sistemas de controle de versões.
  • Separe 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 Software Delivery Shield é uma solução totalmente gerenciada de segurança de ponta a ponta 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. Os componentes a seguir do Software Delivery Shield 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. Com ele, os administradores de TI e de segurança podem provisionar, escalonar, gerenciar e proteger facilmente os ambientes de desenvolvimento, além de permitir que os desenvolvedores acessem ambientes de desenvolvimento com configurações consistentes e ferramentas personalizáveis.

    O Cloud Workstations ajuda a mudar a segurança ao melhorar 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 particular, atualização forçada de imagem 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 IDE para criar, implantar e integrar aplicativos ao Google Cloud. Com ele, os desenvolvedores podem criar e personalizar um novo aplicativo usando modelos de amostra e executar o aplicativo finalizado. Source protect do Cloud Code oferece aos desenvolvedores feedback de segurança em tempo real, como a identificação de dependências vulneráveis e a geração de relatórios de licenças, enquanto trabalham nos ambientes de desenvolvimento integrado. Ele fornece feedback rápido e prático 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 do Cloud Code não está disponível para acesso público. Para acessar esse recurso, consulte a página de solicitação de acesso.

A seguir