Em menos de 45 dias, o GitHub transformou um gargalo de segurança em uma vantagem competitiva interna: todos os 14 mil repositórios corporativos da empresa agora têm um responsável validado ou foram automaticamente arquivados. A mudança, liderada pelo engenheiro de segurança Michael Recachinas, eliminou a busca manual por proprietários e reduziu riscos em workflows críticos como secret scanning, conformidade e resposta a incidentes.
O problema: 11 mil repositórios sem dono claro
Até o início de 2025, o GitHub somava mais de 11 mil repositórios ativos sem indicação de proprietário. Enquanto projetos ligados a serviços em produção eram rastreados no Service Catalog, documentações, ferramentas internas e protótipos não possuíam qualquer vínculo de responsabilidade. O efeito colateral aparecia sempre que surgia um alerta de segredo vazado: “girar” a credencial sem saber quem aprovaria a ação gerava downtime, retrabalho e muita frustração.
Por que isso importa para você?
Se a sua equipe desenvolve microserviços, mantém infraestrutura como código ou simplesmente hospeda a Wiki do time no GitHub, a ausência de um owner confiável pode atrasar correções de segurança, impactar SLAs ou até violar requisitos de compliance. Em empresas menores, o risco é parecido: um experimento de 2018 esquecido no repositório pode expor segredos válidos ou bibliotecas vulneráveis que ninguém mais monitora.
A arquitetura da solução
O GitHub avaliou opções como armazenar um arquivo OWNER.md em cada repo, mas escolheu as Custom Properties — metadados nativos, pesquisáveis via API e aplicáveis por regras organizacionais. Foram criados dois campos:
- ownership-type: define a categoria do dono (Service Catalog, Equipe ou Hubber individual).
- ownership-name: nome do serviço, time ou usuário, com validação automática.
Um job em Kubernetes sincroniza diariamente o Service Catalog com os repositórios, preenchendo automaticamente os casos ligados a serviços (≈1 500 repos). Para o restante, um aplicativo GitHub cria uma issue de aviso; se o dono não for definido em 30 dias, o repositório é arquivado — um estado reversível e sem perda de dados.
Automação com freio de segurança
Para não arquivar projetos legítimos por engano, a equipe implementou dois guardrails:
- Low-water mark: se o número de arquivamentos em um ciclo supera o limite pré-definido, o processo aborta e dispara alerta no Datadog.
- @-menções inteligentes: administradores e colaboradores com write recebem notificação direta, garantindo visibilidade imediata.
Resultados: inventário limpo e ciclo curto de 1 h
Concluída a etapa inicial, o inventário se estabilizou em 3 000 repositórios ativos versus 11 000 arquivados — muitos sem commit há anos. O tempo de detecção para repositórios que perdem o dono caiu de 30 dias para apenas 1 hora. A superfície de ataque diminuiu e a busca por proprietários deixou de ocupar horas de engenheiros de segurança.
Imagem: Internet
Como replicar na sua organização
Quer o mesmo nível de controle? Segue um roteiro resumido:
- Defina sua taxonomia: serviço, time, pessoa — escolha o que faz sentido.
- Crie propriedades personalizadas: use listas suspensas para evitar erro de digitação.
- Sincronize seu catálogo de serviços: comece populando o que já está mapeado.
- Exija proprietário na criação de repositório: limpe o backlog uma única vez; mantenha-o limpo para sempre.
- Implemente um período de carência: 30 dias é razoável; arquive repositórios ignorados.
- Adicione salvaguardas: monitore anomalias e garanta notificação direta aos responsáveis.
Próximos passos: de código a hardware
Manter repositórios sob controle é tão essencial quanto escolher o mouse ou o teclado mecânico certo para a sua produtividade. Processos bem definidos evitam interrupções, da mesma forma que periféricos confiáveis evitam dores de cabeça durante aquela maratona de debug. Adotar práticas de governança hoje prepara o terreno para escalar seu stack — seja de software, seja de hardware — com segurança.
Com essa iniciativa, o GitHub mostra que, mesmo em ambientes altamente distribuídos, a propriedade de código pode (e deve) ser tratada como atributo de primeira classe. A boa notícia é que qualquer organização pode aplicar o mesmo conceito usando apenas funcionalidades nativas da própria plataforma.
Com informações de GitHub Engineering Blog
