Como manter um repositório GitHub seguro

• 8 minutos

Aqui, discutiremos algumas das ferramentas de segurança e técnicas essenciais disponíveis para os administradores do repositório do GitHub.

A importância de uma estratégia de desenvolvimento segura

A segurança do aplicativo é importante. Os serviços de notícias frequentemente carregam histórias sobre alguma violação dos sistemas de uma empresa e dados privados de empresas e clientes que foram roubados.

Então, quais são os problemas a serem considerados ao planejar uma estratégia de desenvolvimento segura? Claramente, precisamos proteger as informações de serem divulgadas para pessoas que não deveriam ter acesso a ela, mas, mais importante, precisamos garantir que as informações só sejam alteradas ou destruídas quando forem apropriadas.

Precisamos garantir que autentiquemos corretamente quem está acessando os dados e se eles têm as permissões corretas para fazer isso. Através de dados históricos, arquivos ou logs, é necessário encontrar evidências quando algo está errado.

Há muitos aspectos para criar e implantar aplicativos seguros. Aqui estão três itens a serem considerados:

• Há um problema de conhecimento geral: Muitos desenvolvedores e outros membros da equipe acham que compreendem a segurança, mas isso não é verdade. A segurança cibernética é uma disciplina em constante evolução. É essencial ter um programa de educação e treinamento contínuo.

• O código deve ser criado corretamente e com segurança: É preciso garantir que o código seja criado corretamente e implemente com segurança os recursos necessários. Além disso, é fundamental garantir que os recursos tenham sido projetados com a segurança.

• Os aplicativos devem estar em conformidade com regras e regulamentos: É necessário garantir que o código esteja em conformidade com as regras e regulamentações que precisam ser atendidas. Precisamos testar a conformidade durante a criação do código, bem como retestar periodicamente, mesmo após a implantação.

Segurança em cada etapa

A segurança não é algo que você pode simplesmente adicionar posteriormente a um aplicativo ou a um sistema. O desenvolvimento seguro deve fazer parte de cada fase do ciclo de vida do desenvolvimento de software. Esse conceito é ainda mais importante para aplicativos críticos e aqueles que processam informações confidenciais ou altamente confidenciais.

Na prática, para responsabilizar as equipes pelo que desenvolvem, os processos precisam mudar para a esquerda ou ser concluídos anteriormente no ciclo de vida de desenvolvimento. Ao mover as etapas de um portão final no momento da implantação para uma etapa anterior, menos erros serão cometidos e os desenvolvedores poderão avançar mais rapidamente.

Os conceitos de segurança do aplicativo não eram um foco para desenvolvedores no passado. Além dos problemas de educação e treinamento, isso aconteceu porque as organizações enfatizavam o desenvolvimento rápido de recursos.

Com a introdução das práticas DevOps, é muito mais fácil integrar os testes de segurança ao pipeline. Em vez de ser uma tarefa executada por especialistas em segurança, o teste de segurança deve ser apenas parte dos processos de entrega diários.

De modo geral, quando o tempo de retrabalho é levado em conta, a adição de segurança às suas práticas de DevOps mais cedo no ciclo de vida de desenvolvimento permite que as equipes de desenvolvimento detectem os problemas muito antes. Identificar problemas mais cedo pode reduzir o tempo total necessário para desenvolver softwares de qualidade.

A abordagem "shift left" é uma mudança de processo, mas não é um único controle ou ferramenta específica. Trata-se de tornar toda a segurança mais centrada no desenvolvedor e fornecer feedback de segurança aos desenvolvedores onde eles estão.

Recursos da guia Segurança

O GitHub oferece recursos de segurança que ajudam a manter os dados seguros em repositórios e entre organizações. Para localizar a guia de segurança:

1. No GitHub.com, vá para a página principal do repositório.

2. No nome do repositório, selecione Segurança.

Na guia Segurança, você pode adicionar recursos ao fluxo de trabalho do GitHub para ajudar a evitar vulnerabilidades no repositório e na base de código. Esses recursos incluem:

• Políticas de segurança que permitem especificar como relatar uma vulnerabilidade de segurança em seu projeto adicionando um arquivo SECURITY.md ao repositório.
• Alertas do Dependabot que notificam quando o GitHub detecta que seu repositório está usando uma dependência vulnerável ou malware.
• Avisos de segurança que você pode usar para discutir, corrigir e publicar informações de maneira privada sobre vulnerabilidades de segurança em seu repositório.
• Digitalização de código que ajuda você a encontrar, fazer triagem e corrigir vulnerabilidades e erros em seu código.

Para obter mais informações, consulte Recursos de segurança do GitHub.

Em seguida, exploramos alguns desses recursos e aprendemos maneiras de distribuir responsabilidades operacionais e de segurança em todas as fases do ciclo de vida de desenvolvimento de software.

Comunicar uma política de segurança com o SECURITY.md

Os benefícios da comunidade do GitHub são substanciais, mas também têm riscos potenciais. O fato de que qualquer pessoa pode propor correções de bugs publicamente acarreta certas responsabilidades. O mais importante é a divulgação responsável de informações que podem levar a explorações de segurança antes da correção de bugs subjacentes. Os desenvolvedores que desejam relatar ou solucionar problemas de segurança procuram um arquivo SECURITY.md na raiz de um repositório para divulgar suas preocupações com responsabilidade. Fornecer diretrizes nesse arquivo acelera a resolução dessas questões críticas.

Para saber mais sobre o SECURITY.md, confira Adicionar uma política de segurança a um repositório.

Avisos de Segurança do GitHub

Os Avisos de Segurança do GitHub permitem que os responsáveis pelo repositório discutam e corrijam de modo privado as vulnerabilidades de segurança em um projeto. Após os mantenedores de repositório colaborarem em uma correção, podem publicar o aviso de segurança para divulgar publicamente a vulnerabilidade de segurança à comunidade do projeto. Ao publicar avisos de segurança, os mantenedores de repositório facilitam para sua comunidade atualizar as dependências de pacotes e a pesquisar sobre as consequências das vulnerabilidades de segurança. O GitHub armazena os avisos publicados na lista Vulnerabilidades e Exposições Comuns (CVE). Essa lista é usada para notificar automaticamente os repositórios afetados que usam software com uma vulnerabilidade listada. Para obter mais informações, consulte Sobre os avisos de segurança do repositório.

Manter arquivos confidenciais fora do repositório com .gitignore

É fácil para os desenvolvedores ignorar arquivos incluídos em uma confirmação. Às vezes, esses arquivos ignorados são benignos, como arquivos de build intermediários. No entanto, há sempre o risco de alguém fazer commit de dados confidenciais inadvertidamente. Por exemplo, alguém poderia fazer commit uma chave de API ou dados de configuração privada que atores mal-intencionados poderiam usar. Uma técnica para ajudar a evitar esse risco é criar e manter arquivos .gitignore. Esses arquivos instruem as ferramentas de cliente, como o utilitário de linha de comando git, a ignorar caminhos e padrões ao agregar arquivos para uma confirmação.

O exemplo a seguir ilustra alguns dos casos de uso comuns para ignorar arquivos:

# User-specific files - Ignore all files ending in ".suo"
*.suo

# Mono auto generated files - Ignore all files starting with "mono_crash."
mono_crash.*

# Build results - Ignore all files in these folders found at any folder depth
[Dd]ebug/
[Rr]elease/
x64/
x86/

# Root config folder - Ignore this directory at the root due to leading slash
# Removing the slash would ignore "config" directories at all depths 
/config

# Ignore intermediate JS build files produced during TypeScript build at any 
# folder depth under /Web/TypeScript. This won't ignore JS files elsewhere. 
/Web/TypeScript/**/*.js

Seu repositório pode incluir vários arquivos .gitignore. As configurações são herdadas de diretórios pai, com a substituição de campos em novos arquivos .gitignore que têm precedência sobre as configurações pai de suas pastas e subpastas. É um esforço significativo manter o arquivo .gitignore raiz, embora adicionar um arquivo .gitignore em um diretório de projeto possa ser útil quando esse projeto tem requisitos específicos que são mais fáceis de manter separadamente do pai, como arquivos que não devem ser ignorados.

Para saber mais sobre o .gitignore, confira Ignorar arquivos. Confira também a coleção de arquivos .gitignore iniciais oferecidos para várias plataformas no repositório gitignore.

Remover dados confidenciais de um repositório

Embora os arquivos .gitignore possam ser úteis para ajudar os colaboradores a evitar fazer commit de dados confidenciais, é apenas uma boa sugestão. Os desenvolvedores ainda poderão encontrar soluções alternativas para adicionar arquivos se quiserem. Às vezes, os arquivos podem não ser notados porque não atendem à configuração do arquivo .gitignore. Os participantes do projeto sempre precisam sempre estar atentos a commits que contenham dados que não devem estar incluídos no repositório ou no histórico.

Regras de proteção de branch

Você pode criar uma regra de proteção de branch para impor determinados fluxos de trabalho para um ou mais branches. Por exemplo, você pode exigir uma revisão de aprovação ou verificações de status aprovadas para todas as solicitações de pull mescladas no branch protegido.

Você pode usar os fluxos de trabalho que protegem o branch para:

• Execute uma compilação para verificar se as alterações de código podem ser compiladas
• Executar um linter para verificar se há erros de digitação e se o código está em conformidade com as convenções de codificação internas
• Executar testes automatizados para verificar se há alterações de comportamento do código
• E assim por diante

Adicionar um arquivo CODEOWNERS

Ao adicionar um arquivo CODEOWNERS ao repositório, você pode atribuir membros individuais da equipe ou equipes inteiras como proprietários do código a caminhos no repositório. Esses proprietários de código são então necessários para revisões de solicitação de pull em quaisquer alterações em arquivos em um caminho para o qual eles estão configurados.

# Changes to files with the js extensions need to be reviewed by the js-owner user/group:
*.js    @js-owner

# Changes to files in the builds folder need to be reviewed by the octocat user/group:
/build/ @octocat

Você pode criar o arquivo CODEOWNERS na raiz do repositório ou nas pastas docs ou .github.