10 práticas recomendadas de segurança para o GitHub

Em um cenário digital que evolui rapidamente e é dominado pelo código, proteger sua base de código é fundamental. O GitHub é a plataforma preferida da comunidade de desenvolvedores para compartilhar código e controlar versões. No entanto, devido à sua ampla adoção, o GitHub não está imune aos muitos desafios de segurança que os desenvolvedores enfrentam todos os dias. De acessos não autorizados ao risco de vazamento de dados confidenciais, é essencial que os desenvolvedores adotem as práticas recomendadas de segurança para o GitHub e reforcem o código e os fluxos de trabalho de desenvolvimento.

Neste guia rápido, apresentamos dez práticas recomendadas que você pode adotar para reforçar a segurança no GitHub. Baixe o material de uma página e continue lendo para conferir uma explicação mais detalhada das dez ações selecionadas.

Ative e exija a autenticação de dois fatores no GitHub

A autenticação de dois fatores, geralmente abreviada como 2FA, é um protocolo de segurança que exige que os usuários forneçam dois fatores de autenticação diferentes para confirmar sua identidade. Em geral, isso envolve algo que você sabe (como uma senha) e algo que você tem (como um celular). Essa abordagem em várias camadas dificulta muito o acesso aos seus dados por pessoas não autorizadas — um recurso essencial para a AppSec e a segurança do código.

O GitHub reúne uma grande quantidade de propriedade intelectual e código confidencial. Para nós, desenvolvedores e profissionais de DevOps, é extremamente importante proteger os repositórios de código e preservar a integridade dos projetos de código aberto em que trabalhamos. A 2FA acrescenta uma camada de segurança, dificultando o acesso não autorizado de possíveis invasores, mesmo que eles consigam sua senha.

Para ativar a 2FA no GitHub, siga estas etapas simples:

1. Acesse sua conta do GitHub.

2. Clique na sua foto de perfil, no canto superior direito, e depois em Settings.

3. Na barra lateral, clique em Security.

4. Clique no botão Enable two-factor authentication.

5. Escolha se quer usar um aplicativo de autenticação ou receber mensagens de texto para a 2FA e siga as instruções para configurar.

6. Por fim, você receberá alguns códigos de recuperação. Eles são importantes caso você perca o acesso ao método de 2FA, então salve-os em um local seguro.

Tornar obrigatória a autenticação de dois fatores (2FA) nos repositórios do GitHub da sua organização é uma etapa essencial para reforçar a segurança. Ao exigir a 2FA, cada membro da equipe que acessar o repositório precisará fornecer uma verificação adicional, como um código temporário de um aplicativo de autenticação ou recebido por SMS. Essa medida de segurança reduz significativamente o risco de acesso não autorizado, especialmente no caso de senhas comprometidas. Exigir a 2FA protege sua base de código e demonstra um compromisso proativo com a manutenção de um ambiente de desenvolvimento seguro, em linha com as práticas recomendadas de controle de acesso robusto.

Limite o acesso aos repositórios

Em segurança de aplicações e de código, limitar o acesso aos repositórios do GitHub é essencial. Essa é uma maneira eficiente de gerenciar quem pode visualizar, editar ou administrar seu código-fonte. Essa prática ajuda a preservar a integridade do código e também o protege de possíveis ameaças à segurança. 

O princípio do privilégio mínimo (PoLP) é um conceito de segurança computacional segundo o qual cada usuário recebe apenas o nível mínimo de acesso necessário para realizar suas funções. Esse princípio também deve ser aplicado aos seus repositórios do GitHub.

Aplicar o PoLP aos seus repositórios ajuda a reduzir os riscos relacionados a:

• Exposição acidental de dados confidenciais: restringir o acesso reduz as chances de dados confidenciais serem enviados acidentalmente a um repositório, já que menos pessoas têm permissão de gravação.

• Ataques maliciosos: limitar o acesso à sua base de código reduz o número de pontos de entrada para possíveis invasores.

• Alterações não intencionais: quanto menos pessoas tiverem acesso de gravação ou administrador, menor a chance de alterações acidentais no código que possam causar bugs ou interromper compilações.

O GitHub oferece vários níveis de acesso de usuário aos repositórios: Read, Triage, Write, Maintain e Admin. Cada nível oferece diferentes recursos. Por exemplo, um usuário com permissão Read pode apenas visualizar e criar um fork do repositório, enquanto um usuário com permissão Admin pode gerenciar as configurações, as equipes e as integrações do repositório.

Lembre-se: sempre conceda apenas o nível de acesso mínimo necessário para que um colaborador desempenhe sua função. Se necessário, você poderá ampliar o acesso depois.

Evite armazenar credenciais como código ou configuração no GitHub

Armazenar credenciais diretamente nos repositórios do GitHub representa um risco significativo à segurança, pois expõe informações confidenciais a possíveis acessos não autorizados. Para reduzir esse risco, os desenvolvedores devem usar alternativas seguras para armazenar informações confidenciais, como variáveis de ambiente ou arquivos de configuração fora do repositório controlado por versão. Ao referenciar essas variáveis ou arquivos externos no código, em vez de inserir as credenciais diretamente, os desenvolvedores mantêm uma separação clara entre os dados confidenciais e a base de código acessível publicamente, reduzindo o risco de exposição acidental.

Durante o desenvolvimento, o Snyk Code pode ajudar a identificar credenciais e segredos inseridos diretamente no código. O plugin do Snyk Code para IDEs é uma ótima ferramenta para detectar possíveis problemas de segurança antes que o código seja enviado.

Além disso, ferramentas especializadas como GitLeaks e Git-secrets são essenciais para reforçar a segurança. O GitLeaks verifica os repositórios em busca de segredos e chaves de API e alerta imediatamente quando detecta informações que podem comprometer a segurança. Integrar o GitLeaks aos pipelines de CI/CD ou aos hooks de pré-commit permite corrigir os problemas rapidamente. Outra ferramenta útil, o Git-secrets, impede a inclusão acidental de segredos ao verificar commits, branches e arquivos preparados para envio em busca de padrões predefinidos de dados confidenciais. Configurado para rejeitar commits que contenham esses padrões, o Git-secrets oferece uma defesa robusta contra vazamentos acidentais e reforça as medidas de segurança nos repositórios do Git e do GitHub.

A combinação dessas ferramentas com seu fluxo de trabalho de desenvolvimento ajuda a identificar e reduzir proativamente os riscos de segurança associados ao armazenamento de credenciais em repositórios do Git e do GitHub. Com verificações regulares e automatizadas, as equipes podem diminuir significativamente a probabilidade de expor informações confidenciais e proteger a base de código contra possíveis ameaças à segurança.

Se um segredo for detectado, avalie rapidamente a situação e identifique as áreas afetadas no repositório. Remova ou substitua as credenciais comprometidas, altere as chaves ou senhas associadas e informe os membros da equipe sobre o incidente. Além disso, se invalidar ou substituir os dados não for suficiente, você pode considerar removê-los reescrevendo o histórico do Git com uma ferramenta como o BFG Repo-Cleaner. Lembre-se de que esse histórico pode ter sido copiado para máquinas locais ou forks do seu repositório.

Conecte seus repositórios ao Snyk e verifique se há vulnerabilidades

Uma das melhores práticas de AppSec e segurança de código é conectar seus repositórios do GitHub ao Snyk, uma ferramenta de segurança para desenvolvedores. Essa integração permite verificar automaticamente se há vulnerabilidades na sua base de código, nas imagens de contêiner, nas dependências de código aberto e nas configurações de infraestrutura como código.

Conectar seu repositório do GitHub à sua conta do Snyk é simples. Primeiro, entre na sua conta do Snyk e acesse a página Integrations. Clique na integração GitHub e siga as etapas para autorizar o Snyk a acessar seus repositórios do GitHub.

Pronto para usar, o Snyk oferece quatro tipos de verificação para seus repositórios do GitHub:

1. Snyk Open Source: verifica se há vulnerabilidades conhecidas nas suas dependências de código aberto. É uma ferramenta essencial para a segurança de código aberto, pois ajuda a encontrar e corrigir problemas em pacotes de terceiros. O Snyk também verifica as licenças das dependências utilizadas, ajudando você a tomar as decisões corretas para cumprir os requisitos de licenciamento.

2. Snyk Code: verifica se há vulnerabilidades de segurança e problemas de qualidade na sua base de código. Ele ajuda na segurança de aplicações ao identificar possíveis falhas no seu código. 

3. Snyk Container: verifica se há vulnerabilidades nas imagens de contêiner Docker. Essa é uma parte essencial da segurança de contêineres, pois garante que suas imagens Docker possam ser implantadas com segurança.

4. Snyk IaC: verifica as configurações da sua infraestrutura como código. O produto oferece monitoramento e correção contínuos para identificar e corrigir vulnerabilidades nas configurações da infraestrutura em nuvem, como Kubernetes, Terraform e CloudFormation, entre outras. 

Verifique pull requests recebidas

Além de conectar seus repositórios do GitHub ao Snyk para realizar verificações abrangentes de vulnerabilidades, é essencial aproveitar o recurso da plataforma que verifica novas pull requests (PRs) em tempo real. A verificação de pull requests do Snyk permite identificar e corrigir proativamente vulnerabilidades de segurança introduzidas durante o desenvolvimento. Quando os desenvolvedores propõem alterações em suas PRs, o Snyk verifica automaticamente a base de código modificada, as dependências de código aberto e as imagens de contêiner, destacando possíveis vulnerabilidades antes que o código seja integrado à branch padrão.

Essa abordagem proativa permite que as equipes de desenvolvimento corrijam problemas de segurança nos estágios iniciais do ciclo de vida de desenvolvimento, reduzindo o risco de introduzir vulnerabilidades no ambiente de produção.

Ao integrar o Snyk perfeitamente ao seu fluxo de trabalho no GitHub, você reforça a segurança da sua base de código e promove uma cultura DevSecOps que prioriza a segurança contínua durante todo o processo de desenvolvimento de software. Conectar seus repositórios ao Snyk e ativar a verificação de pull requests adiciona uma camada extra de proteção, garantindo que apenas código seguro seja integrado à sua branch padrão.

Adicione um arquivo SECURITY.md

Além do arquivo README.md, a inclusão de um arquivo SECURITY.md é uma etapa essencial para reforçar a postura de segurança do seu projeto. Esse arquivo funciona como um ponto central para informações importantes sobre segurança, promovendo transparência e fornecendo orientações claras a colaboradores e partes interessadas.

Política de divulgação

Defina um procedimento claro para quem encontrar problemas de segurança e indique um ponto de contato, que geralmente é um endereço de e-mail “security@”. Essa política incentiva a divulgação responsável, permitindo que pessoas externas relatem problemas de segurança com segurança e promovendo uma abordagem colaborativa para gerenciar vulnerabilidades.

Política de atualização de segurança

Explique como o projeto pretende divulgar informações sobre vulnerabilidades de segurança recém-identificadas. Isso inclui os canais pelos quais os usuários receberão notificações e as medidas que devem tomar para resolver os problemas rapidamente. Uma política de atualização bem definida mantém os usuários informados e permite que tomem as medidas necessárias para proteger suas implantações.

Configurações relacionadas à segurança

Destaque as configurações que os usuários devem considerar para influenciar a postura de segurança ao implantar o projeto. Esta seção funciona como um guia prático para configurar medidas de segurança e garantir que os usuários conheçam as opções disponíveis para reforçar a segurança geral das implantações.

Lacunas de segurança conhecidas e melhorias futuras

Comunique com transparência as lacunas de segurança existentes que já foram identificadas, mas ainda não foram corrigidas. Compartilhe também informações sobre melhorias de segurança futuras que estão sendo consideradas, mas ainda não foram implementadas. Isso promove uma cultura de transparência e colaboração, incentivando os colaboradores a participar ativamente do aprimoramento da segurança do projeto.

O arquivo SECURITY.md tem um papel fundamental na criação de um ambiente seguro e aberto para o seu projeto. Além de estabelecer as bases para práticas responsáveis de segurança, ele também é um recurso valioso para colaboradores e usuários, contribuindo para um ecossistema de projetos mais resiliente e seguro.

Use regras de proteção de branches

As regras de proteção de branches adicionam uma camada essencial de segurança ao fluxo de trabalho de DevSecOps, evitando alterações não autorizadas ou acidentais em partes sensíveis da sua base de código. Nesta seção, vamos explicar o que são essas regras e como configurá-las no GitHub para reforçar a segurança da sua base de código.

No GitHub, as regras de proteção de branches são um conjunto de controles que os administradores de repositórios podem configurar para garantir a qualidade do código e gerenciar a colaboração. Elas permitem definir e aplicar exatamente como as alterações no código devem ser mescladas em uma branch. Esse é um aspecto fundamental da segurança de aplicações e do código, pois aplica o princípio do menor privilégio e garante que apenas usuários autorizados possam alterar a base de código.

Entre os controles que você pode aplicar com as regras de proteção de branches estão:

• Exigir revisões de pull request antes da mesclagem: isso garante que pelo menos outra pessoa revise e aprove as alterações antes que elas sejam mescladas em uma branch protegida.

• Exigir que as verificações de status sejam aprovadas antes da mesclagem: isso permite garantir que todos os testes de CI necessários sejam aprovados antes que o código seja mesclado.

• Restringir quem pode fazer push para branches correspondentes: isso permite especificar quais usuários ou equipes podem fazer push para uma branch protegida e 

• Impor um histórico linear de commits: isso mantém o histórico de commits organizado e fácil de entender.

Como configurar regras de proteção de branches

Siga estas etapas para configurar regras de proteção de branches no GitHub:

1. Acesse seu repositório no GitHub e abra a aba Settings.

2. Na barra lateral esquerda, clique em Branches.

3. Em Branch protection rules, clique em Add rule.

4. No campo Branch name pattern, informe o nome da branch que você quer proteger.

5. Em Protect matching branches, selecione os requisitos que você quer aplicar. Você pode escolher entre as opções mencionadas acima.

6. Clique em Create para salvar a nova regra de proteção de branches.

O uso eficaz das regras de proteção de branches pode melhorar significativamente a segurança e a confiabilidade da sua base de código. Por motivos de segurança, na maioria dos repositórios usados na Snyk, não é possível fazer push diretamente para a branch principal: é obrigatório usar um PR. Isso é garantido pela implementação de regras de proteção de branches.

Faça a rotação de tokens SSH e chaves pessoais

Fazer regularmente a rotação de tokens SSH e chaves pessoais é uma prática essencial para reforçar a segurança do código nos seus repositórios do GitHub. Nesta seção, você vai aprender como fazer isso e por que essa prática é importante para a segurança de aplicações, de contêineres e para DevSecOps.

Fazer a rotação de tokens SSH e chaves pessoais é uma medida proativa de segurança que ajuda a impedir o acesso não autorizado aos seus repositórios do GitHub. Se uma pessoa mal-intencionada conseguir obter seu token SSH ou suas chaves pessoais, poderá causar grandes danos à sua base de código. A rotação regular dessas credenciais dificulta a permanência de invasores nos seus repositórios e reforça a segurança do seu código open source.

Como fazer a rotação de tokens SSH e chaves pessoais

O GitHub oferece um processo simples para fazer a rotação de tokens SSH e chaves pessoais. Siga estas etapas:

1. Faça login na sua conta do GitHub.

2. Acesse Settings, Developer settings e, em seguida, Personal access tokens.

3. Clique em Generate new token.

4. Dê uma descrição ao token e selecione os escopos (ou permissões) que você quer conceder a ele.

5. Clique em Generate token.

Depois de gerar um novo token, substitua o antigo em todos os lugares onde ele é usado.

Automatize a rotação de tokens e chaves

Para equipes com muitos repositórios ou ambientes DevOps de grande escala, fazer a rotação manual de tokens SSH e chaves pode ser uma tarefa complicada. Automatizar o processo garante consistência e economiza tempo. Você pode usar o GitHub Actions ou ferramentas de pipeline de CI/CD, como o Jenkins, para automatizar a rotação.

Em resumo, fazer a rotação de tokens SSH e chaves pessoais é uma prática essencial para manter a segurança dos seus repositórios no GitHub. O objetivo não é complicar sua vida, mas garantir que seu código esteja seguro e protegido contra acessos não autorizados.

Atualize dependências automaticamente

Manter uma base de código atualizada e segura é fundamental para a segurança de aplicações, de código e de contêineres, além de DevSecOps. Um aspecto essencial é atualizar as dependências regularmente. Vulnerabilidades de segurança são encontradas com frequência em bibliotecas de terceiros desatualizadas. Por isso, é importante ter uma estratégia para atualizar dependências automaticamente e minimizar o risco de violações de segurança. Nesta seção, vamos abordar a importância de atualizar bibliotecas de terceiros e como usar ferramentas como a Snyk para automatizar o processo.

As bibliotecas de terceiros são parte integrante do desenvolvimento de software, pois permitem que desenvolvedores reutilizem código criado por outras pessoas, sem precisar reinventar a roda. No entanto, se não forem gerenciadas corretamente, elas podem se tornar um elo fraco da sua cadeia de segurança. Essas bibliotecas podem ficar desatualizadas e representar sérios riscos se contiverem vulnerabilidades que não foram corrigidas nas versões mais recentes.

Atualizar dependências manualmente pode ser uma tarefa complicada e demorada, principalmente em projetos grandes. É aí que a automação faz diferença.

Automatize atualizações de dependências com a Snyk

A Snyk é uma ferramenta poderosa que ajuda a identificar e corrigir vulnerabilidades nas suas dependências. Além de verificar vulnerabilidades, a Snyk também pode automatizar as atualizações das dependências.

Quando integrada ao GitHub, a Snyk verifica seus repositórios em busca de dependências desatualizadas e versões vulneráveis de bibliotecas. Em seguida, abre pull requests (PRs) no GitHub para atualizá-las, permitindo que você revise e mescle as atualizações de forma simplificada.

Depois de conectar o GitHub à sua conta da Snyk, verifique se a opção Automatic dependency upgrade pull requests está ativada em Integration Settings at the Organization level or in the Project Settings.

A partir daí, a Snyk vai monitorar seus repositórios e criar PRs para dependências desatualizadas, facilitando a manutenção de uma base de código segura e atualizada.

Em resumo, automatizar as atualizações de dependências é uma prática recomendada que todo desenvolvedor e profissional de DevOps deve adotar. Além de melhorar a segurança das suas aplicações, isso economiza tempo e esforço no longo prazo. Com ferramentas como a Snyk, você pode se antecipar às vulnerabilidades de segurança em bibliotecas de terceiros e manter uma base de código saudável e segura.

Use repositórios privados para dados confidenciais

Saber gerenciar dados confidenciais em plataformas como o GitHub é essencial. Uma das maneiras mais simples de protegê-los é usar repositórios privados. Nesta seção, vamos explicar a diferença entre repositórios públicos e privados e quando é melhor usar os privados.

O GitHub oferece dois tipos de repositórios: públicos e privados:

1. Repositórios públicos: como o nome indica, esses repositórios ficam visíveis para todos. Qualquer usuário do GitHub pode visualizar, clonar e bifurcar um repositório público. No entanto, apenas os colaboradores do repositório podem enviar alterações. Essa abertura favorece a colaboração e o desenvolvimento open source.

2. Repositórios privados: esses repositórios ficam visíveis apenas para o proprietário e os colaboradores que ele adicionou explicitamente. Mesmo que alguém tenha o URL de um repositório privado, não poderá ver o conteúdo sem as permissões necessárias.

Quando usar repositórios privados

Repositórios públicos podem ser ótimos para projetos open source e desenvolvimento colaborativo, mas não são adequados para dados confidenciais. Veja em quais situações você deve considerar o uso de repositórios privados:

1. Proteção de dados confidenciais: se sua base de código contiver dados confidenciais, como chaves de API, senhas ou outras informações sigilosas, ela deve ser armazenada em um repositório privado. Assim, somente colaboradores autorizados terão acesso a esses dados.

2. Código proprietário: se sua base de código for proprietária e não puder ser acessada publicamente, o melhor é usar um repositório privado. Isso costuma acontecer com aplicações de negócios e produtos de software premium.

3. Fase de desenvolvimento: quando seu projeto ainda estiver no início do desenvolvimento e não estiver pronto para ser visto publicamente, é melhor mantê-lo em um repositório privado. Assim, você controla quem tem acesso ao projeto durante essa fase.

Desative a criação de repositórios públicos

Para reforçar a segurança e proteger informações confidenciais, organizações que não precisam de repositórios públicos devem considerar desativar totalmente o acesso público. Essa medida proativa ajuda a evitar a criação acidental de repositórios acessíveis ao público e reduz o risco de exposição de dados. Ao definir repositórios privados pelo caminho Your Organizations, Settings e Member Privileges, as organizações garantem que somente usuários autorizados possam acessar os repositórios. Além de seguir as práticas recomendadas de proteção de dados, essa medida simplifica o gerenciamento de repositórios e promove um ambiente mais seguro e controlado para o código da organização.

Em resumo, usar repositórios privados para dados confidenciais é uma prática essencial de segurança no GitHub. Isso ajuda a proteger dados confidenciais e código proprietário, reforçando a segurança do seu código e suas práticas de DevSecOps. 

Escolha com cuidado os apps do GitHub

Ao escolher apps do GitHub, é essencial tomar decisões bem pensadas. Esses aplicativos, desenvolvidos por diferentes organizações e pessoas, oferecem ótimos recursos. Mas, antes de começar a usá-los, considere alguns pontos importantes:

• Verifique as permissões: resista à tentação de conceder permissões sem critério. Conceda apenas as estritamente necessárias. Limitar o acesso reduz riscos desnecessários.

• Questione o acesso: ao lidar com permissões amplas, avalie com rigor se elas são realmente necessárias. Considere as possíveis consequências caso algo dê errado. A ideia é gerenciar os riscos com critério.

• Saiba quem está por trás do app: antes de adicionar um app ao seu ambiente de desenvolvimento, faça a devida pesquisa. Verifique a legitimidade de quem o criou. Pense nisso como a avaliação de um novo integrante da equipe: confiança é fundamental.

• Verifique a segurança: a segurança de um app é a primeira linha de defesa do seu código. Qualquer falha pode deixar seu código vulnerável. Examine os protocolos de segurança para garantir uma proteção sólida.

• Monitore regularmente: manter tudo em ordem é indispensável. Avalie periodicamente se seus apps continuam sendo necessários e confiáveis. Pense nisso como uma forma de manter seu ambiente de código organizado.

Lembre-se: a segurança do seu código é assunto sério. Mantenha-se alerta, faça escolhas criteriosas e preserve a estabilidade e a segurança da sua aplicação.

Conclusão

Em resumo, exploramos o papel fundamental do GitHub no desenvolvimento moderno de software e a importância de adotar práticas recomendadas de segurança robustas. As dez diretrizes que apresentamos formam uma base sólida para proteger seus repositórios e projetos no GitHub. Juntas, elas criam uma defesa robusta contra diversas ameaças e vulnerabilidades. 

A todos os desenvolvedores e profissionais de DevOps, recomendamos que levem essas práticas de segurança a sério. A segurança não é responsabilidade de uma única equipe ou pessoa: é um compromisso coletivo que deve estar presente em todas as etapas do desenvolvimento e das operações de software. 

Como costumamos dizer em DevSecOps: "A segurança é responsabilidade de todos." Vamos fazer a nossa parte para manter nossas aplicações, nossos dados e nossos usuários o mais seguros possível. 

Com a mentalidade de aprendizado contínuo, esteja sempre aberto a novas práticas, ferramentas e processos que possam reforçar ainda mais a segurança do seu ambiente GitHub.

Boas linhas de código e mantenha-se seguro!