Protegendo Seus Repositórios Git: Melhores Práticas e Fontes Não Confiáveis

Proteger seus repositórios Git vai além de manter o código privado. Um repositório pode conter segredos, hooks executáveis, riscos na cadeia de suprimentos, histórico sensível e configurações que afetam todos os desenvolvedores que o clonam.

Boas práticas de segurança no Git ajudam a evitar vazamento de credenciais, automação insegura e confiança acidental em código de fontes desconhecidas. O básico é simples, mas precisa ser aplicado de forma consistente.

Proteja Segredos Antes que Cheguem ao Git

O segredo mais seguro é aquele que nunca entra no repositório. Chaves de API, chaves privadas SSH, credenciais de nuvem, senhas de banco de dados, tokens e arquivos .env devem ficar completamente fora do Git.

Adicione arquivos de segredos locais ao .gitignore:

.env
.env.*
*.pem
id_rsa
id_ed25519

Cuidado com o .env.example. Esse arquivo geralmente é útil, mas deve conter valores fictícios de exemplo:

DATABASE_URL=postgres://user:password@localhost:5432/app
API_TOKEN=replace-me

Não cole valores reais "só para testar". O histórico do Git lembra versões antigas, mesmo depois que você deleta uma linha em um commit posterior.

Se você acidentalmente commitar um segredo, trate-o como exposto. Remova-o da árvore atual, rotacione a credencial no serviço que a emitiu e decida se a limpeza do histórico é necessária. Reescrever o histórico pode ajudar a reduzir a exposição futura, mas não garante que o segredo nunca foi copiado.

Equipes também devem usar varredura de segredos. Muitas plataformas Git hospedadas oferecem varredura para padrões comuns de tokens. Ferramentas de pré-commit locais podem detectar erros mais cedo, antes que um push chegue ao servidor.

Para padrões operacionais relacionados, veja dominando variáveis de ambiente para configuração e segredos.

Reforce o Controle de Acesso e Alterações em Branches

A segurança do repositório começa com o controle de acesso. Dê às pessoas o menor acesso necessário. Alguém que apenas revisa código provavelmente não precisa de direitos de administrador. Uma conta de serviço de CI provavelmente não precisa de permissão para reescrever branches.

Revise regularmente estas configurações:

• Administradores e proprietários do repositório.
• Colaboradores com acesso de escrita.
• Chaves de deploy e usuários máquina.
• Tokens de acesso pessoal usados por automação.
• Webhooks que recebem eventos do repositório.
• Regras de proteção de branches.

Branches protegidos são um dos controles mais úteis. Para branches importantes como main, exija pull requests, verificações de status e revisão antes de mesclar. Desative force pushes, a menos que sua equipe tenha um motivo muito específico para permiti-los.

Commits ou tags assinados também podem ajudar em ambientes de maior confiança. Eles não tornam o código seguro por si só, mas podem provar que um commit ou tag de release foi criado por uma chave que sua equipe reconhece.

Use tags com cuidado para releases. Se um processo de implantação confia em tags, restrinja quem pode criá-las ou movê-las. Uma tag de release movida pode confundir auditorias e implantações.

Cuidado com Repositórios Não Confiáveis

Clonar código de uma fonte não confiável é comum. Executá-lo imediatamente é a parte arriscada. Um repositório Git pode incluir scripts de build, scripts de ciclo de vida de pacotes, Makefiles, contêineres, configuração de CI e instruções que executam código na sua máquina.

Antes de executar qualquer coisa, inspecione o repositório:

git clone --no-checkout https://example.com/project.git
cd project
git log --oneline -5
git status

Depois, verifique arquivos de alto risco:

• Scripts Shell como install.sh ou bootstrap.sh.
• Scripts de pacotes em package.json.
• Arquivos de CI em .github/workflows/, .gitlab-ci.yml ou caminhos similares.
• Dockerfiles e arquivos compose.
• Makefiles.
• Manifestos de dependências específicos de linguagem.

Não execute comandos curl | bash de configuração de um README aleatório. Se um projeto exigir um instalador, baixe-o, leia-o e execute-o em um ambiente descartável, se possível.

Os hooks do Git merecem menção especial. Hooks em .git/hooks/ normalmente não são transferidos como hooks ativos quando você clona um repositório. Isso é bom. Mas um repositório pode incluir scripts que instalam hooks para você. Leia esses scripts antes de executá-los, pois hooks podem ser executados durante commits, merges, rebases e pushes.

Para código desconhecido, use isolamento. Uma máquina virtual temporária, contêiner ou ambiente de desenvolvimento restrito reduz o raio de explosão se um script se comportar mal. Não monte suas chaves SSH, credenciais de nuvem ou kubeconfig de produção em um ambiente usado para código não confiável.

Mantenha o Histórico e os Arquivos do Repositório Limpos

A segurança é mais fácil quando o repositório está organizado. Arquivos binários grandes, arquivos gerados, segredos embutidos e dumps de configuração antigos dificultam a revisão e aumentam o risco.

Use .gitignore para arquivos locais e .gitattributes para regras de manipulação de arquivos. Por exemplo:

*.sh text eol=lf
*.png binary
*.jpg binary

Se seu projeto precisar de arquivos grandes, considere se o Git Large File Storage é apropriado. O Git padrão não é ideal para artefatos de build enormes ou arquivos de mídia. Armazená-los diretamente pode tornar os clones lentos e dificultar a limpeza de arquivos sensíveis.

Revise pull requests para mudanças sensíveis à segurança, não apenas lógica de aplicação. Fique atento a:

• Novas credenciais ou tokens.
• Novas chamadas de rede em scripts.
• Mudanças na fonte de dependências.
• Novas permissões de CI.
• Alterações em scripts de implantação.
• Mudanças amplas no .gitignore que ocultam arquivos importantes.

Preste atenção também aos submódulos. Eles apontam para repositórios externos e commits específicos. Se seu projeto os utiliza, revise URLs de submódulos e atualizações com cuidado.

Quando Envolver um Profissional

Traga um engenheiro de segurança, líder de DevOps ou responsável por resposta a incidentes se um segredo foi enviado para um repositório público, um branch protegido foi forçado inesperadamente ou um contribuidor desconhecido alterou automação de CI ou implantação.

Você também deve buscar ajuda se suspeitar que o histórico do repositório foi adulterado. Preservar evidências pode ser mais importante do que limpar rapidamente, especialmente em um ambiente corporativo.

Proteger repositórios Git se resume a confiança disciplinada. Mantenha segredos fora, limite o acesso, proteja branches importantes e inspecione código não confiável antes de executá-lo. Esses hábitos previnem a maioria dos problemas de segurança em repositórios antes que se tornem incidentes.