Como configurar o GitHub do jeito certo: checklist em 8 passos
GitHub mal configurado é a porta mais comum de incidente em SMB. 8 passos que squad sênior aplica no dia 1 do projeto cobrem 90% do risco. Veja o checklist completo — e por que essa configuração é entregue de graça em todo squad Revin.
Por Victhor Araújo
Victhor Araújo
GitHub configurado por default vem com proteção mínima. Toda startup começa assim. Mas a maioria nunca volta para ajustar — e GitHub mal configurado é o vetor de ataque mais comum em SMB em 2026: token vazado, branch sem proteção, segredo comitado, integração sem revisão.
Squad sênior configura GitHub corretamente no dia 1 do projeto. São 8 passos que cobrem 90% do risco de origem de repositório. A Revin executa esses 8 passos em todos os clientes como parte do onboarding — sem cobrar à parte, sem virar projeto separado de "security review".
Para CTOs, tech leads e founders que ainda têm GitHub com configuração padrão, ou que abriram conta há 1+ ano sem revisar.
Sem branch protection, todo PR pode subir direto na main. Sem code review obrigatório, qualidade vira opcional
✅ Os 8 passos do checklist
1. Branch protection na main / master
Ative: require pull request before merge, require 1+ aprovação de code review, dismiss stale approvals on new commits, require status checks (CI), include administrators, restrict force pushes. Tempo: 5 min.
2. Required status checks com CI obrigatório
Defina pipeline mínimo no GitHub Actions: lint, type check, test. Bloqueio de merge se algum falhar. Sem CI obrigatório, qualquer dev pode subir código quebrado. Tempo: 30-60 min para pipeline básico.
3. Secret scanning ativado
Settings → Security → Secret scanning: ON. GitHub detecta automaticamente AWS keys, tokens, senhas em commits. Alerta imediato. Free para repos públicos; pago (e crítico) para privados. Tempo: 2 min.
4. Dependabot configurado
Settings → Security → Dependabot alerts e security updates: ON. Detecta dependência vulnerável e cria PR de fix automaticamente. Sem isso, CVE acumula silenciosamente. Tempo: 5 min.
5. Code scanning com CodeQL
Para repos com lógica sensível, ativa Code scanning → CodeQL (free para open-source, pago em privado mas vale para B2B SaaS). Identifica SQL injection, XSS, lógica insegura. Tempo: 15-30 min.
6. Token policy: PAT de curta duração
Settings → Personal access tokens: prazo máximo de 90 dias. Rotação automática via GitHub App / workflows preferida. Token sem expiração = token esquecido = porta aberta. Tempo: 15 min para mapear e ajustar.
7. Auditoria de membros e equipes
Settings → People: revogue acesso de ex-funcionários (geralmente esquecido). Revise permissões: ninguém precisa de Owner se não for fundador/CTO. Tempo: 30 min para org com 20-50 pessoas.
8. Webhooks revisados e SSO obrigatório
Settings → Webhooks: liste todos, identifique destino, remova os que ninguém reconhece (porta de exfiltration comum). Settings → Authentication security: SSO obrigatório com SAML para org. Tempo: 30-60 min.
GitHub bem configurado é o controle de segurança mais barato e mais ignorado em SMB
📊 Total de tempo e custo
Total de implementação: 2-4 horas para org pequena, 4-8 horas para org com 20-50 repositórios. Custo direto: zero (todos os passos têm versão gratuita ou já pagos no plano padrão GitHub Team/Enterprise).
Custo indireto: incidente evitado. Em 2025, incidentes públicos de token GitHub vazado custaram, em média, USD 100k-500k em recuperação direta. 8 passos para evitar.
🚧 Os 3 erros mais comuns
- Adiar para "quando tivermos security engineer": startup nunca chega nesse momento sozinha.
- Aplicar parcialmente: 4 de 8 passos não cobrem; é tudo ou pouco.
- Configurar uma vez e nunca revisar: dependências mudam, integrações novas surgem. Revisão trimestral é necessária.
📢 Quer auditoria + remediação do GitHub em 1 dia? Agende um Diagnostic Sprint — a Revin executa os 8 passos como parte do onboarding padrão.
🎯 Conclusão: GitHub é commodity; configuração é diferencial
Todo mundo usa GitHub. Quase ninguém configura direito. Os 8 passos acima custam 1 dia e cobrem 90% do risco de origem — é o controle de segurança mais barato e mais ignorado em SMB.
📢 A Revin entrega essa configuração em todos os clientes no dia 1. Conheça o modelo Security Foundations.
6 min de leitura
Conteúdos do Artigo:
Pronto para elevar o seu negócio?
Agendar uma reunião
Lemos 31 bases de código que chegaram quebradas. Os números se repetem.
Toda vez que a Revin entra pra resgatar um projeto, a primeira coisa é ler o código de fora pra dentro. Juntei o que encontramos em 31 dessas leituras nos últimos 18 meses: cobertura de teste, deploy, segredo exposto, quem entende o quê. A amostra é torta de propósito, e talvez por isso seja útil.
Raquel Reis
Segurança não é uma feature. É um jeito de trabalhar.
Tem uma frase que aparece em quase toda proposta de software que eu leio: "segurança a gente trata depois". Esse "depois" tem data e tem preço, e quase nunca é quem prometeu que paga a conta. Por que segurança é hábito de time, não item de backlog, e como dá pra enxergar isso antes de assinar.
Raquel Reis
Eu recusei um contrato de R$ 1,2 milhão. Faria de novo.
Outubro de 2025: chega no meu WhatsApp o que seria o maior contrato da história da Revin. Seis devs, doze meses, escopo aberto. Eu li duas vezes e disse não. Aqui eu conto o que tinha naquela proposta, por que comprar hora de dev é o jeito mais caro de construir software, e o que aconteceu depois.
Victhor Araújo
O teatro do roadmap: por que o Gantt bonito esconde um squad que não entrega
O slide do roadmap está lindo: barras coloridas, marcos alinhados, tudo "no prazo". Mas o produto não anda. Gestão-teatro é a arte de parecer que entrega sem entregar. 6 sinais de que você está pagando por show, não por software.
Victhor Araújo