Mudança de proprietário do repositório: audite o acesso antes da transferência

A mudança de proprietário de um repositório é um evento de segurança, mesmo quando a transferência parece uma simples tarefa de organização. O repositório pode passar para uma nova equipe em uma tarde, mas as permissões ao redor dele podem continuar associadas a mantenedores que saíram, automações aposentadas, contas antigas na nuvem e credenciais que ninguém acessa há meses.

Já vi equipes considerarem uma transferência concluída depois de mudar o proprietário do repositório e remover duas pessoas da página de colaboradores. Então um job de implantação esquecido continua publicando com um token pessoal, uma chave SSH órfã ainda lê código privado ou um app antigo de hospedagem Git mantém autoridade para alterar pull requests. A página do repositório parecia limpa. O plano de controle real não estava.

A regra prática é simples: só transfira a propriedade depois de conseguir identificar cada identidade e serviço que pode causar um efeito relevante. «Relevante» inclui ler código não público, enviar commits, abrir ou aprovar pull requests, alterar definições de build, acessar segredos, publicar pacotes, implantar software e alterar o próprio acesso.

Transferir um repositório não transfere a responsabilidade

O proprietário de um repositório é um rótulo administrativo. Responsabilidade significa que uma pessoa atual consegue explicar a que o repositório se conecta, por que cada conexão existe, quem a mantém e como revogá-la durante um incidente.

São coisas diferentes. As permissões da hospedagem Git descrevem o acesso dentro de um serviço. Os projetos modernos também dependem de executores de CI, registros de pacotes, funções na nuvem, apps de análise de código, bots de release, publicadores de documentação, notificações de chat, provedores de DNS e armazenamentos de artefatos. Cada sistema tem suas próprias identidades e sua própria memória do projeto.

Essa diferença importa principalmente quando um projeto muda de equipe por causa de uma reorganização, aquisição, migração de plataforma interna ou rotatividade de pessoal. A equipe que recebe o projeto tende a se concentrar em manter o build funcionando. A equipe que sai tende a se concentrar em remover seus nomes. Nenhuma das duas tarefas prova que o controle foi transferido com segurança.

Defina o limite de responsabilidade antes que alguém altere os acessos. Ele deve identificar:

• o responsável técnico da equipe que recebe o projeto e assume a responsabilidade operacional
• o responsável de negócio que decide quem pode acessar o código e os releases
• o contato para incidentes que pode autorizar uma revogação urgente
• a fonte oficial para membros do repositório e identidades de serviços
• a data em que a equipe anterior perde a autoridade

Não use uma caixa de e-mail compartilhada ou um nome genérico de equipe como responsável final. Um grupo pode receber mensagens, mas não pode tomar uma decisão às 2 da manhã. Identifique pessoas pelo nome e revise esse registro quando a equipe mudar.

Há outro ponto desconfortável: um projeto sem responsável atual não deve manter acesso amplo à produção apenas porque ainda consegue gerar builds. Se ninguém puder responder com segurança pelas credenciais de implantação, pause os releases ou reduza as permissões até que alguém possa fazê-lo. A disponibilidade não é desculpa para preservar uma autoridade desconhecida.

Crie um inventário a partir dos efeitos, não da página do repositório

Um inventário de acesso útil começa pelas ações que podem acontecer e depois volta até as identidades capazes de causá-las. Começar pela lista de colaboradores é mais rápido, mas deixa muita coisa de fora.

Pergunte o que pode acontecer com este projeto sem que um desenvolvedor esteja sentado diante do site de hospedagem Git. Um commit pode chegar de um bot. Um workflow de CI pode obter um token da nuvem. Um pacote pode ser publicado depois que uma tag aparece. Um receptor de webhook pode iniciar uma implantação em produção. Um app de revisão de código pode escrever comentários ou alterar verificações. Cada efeito aponta para uma permissão que precisa de um responsável.

Use uma tabela de trabalho com cinco colunas: capacidade, identidade, local da credencial, responsável atual e procedimento de revogação. O procedimento de revogação merece sua própria coluna porque «excluir o token» muitas vezes não é o procedimento real. Talvez seja necessário desinstalar um app, remover uma regra de confiança na nuvem, excluir uma chave de implantação, invalidar um token de registro ou alterar um segredo de webhook nas duas pontas.

Uma primeira revisão deve abranger estas categorias:

• Identidades humanas, incluindo colaboradores diretos, equipes da organização, colaboradores externos e administradores da organização.
• Identidades não humanas, incluindo usuários de máquina, contas de serviço, identidades de executores de CI e instalações de aplicativos.
• Credenciais, incluindo chaves SSH de implantação, tokens de acesso pessoais, chaves privadas de apps, segredos de webhook, tokens de registros e credenciais da nuvem.
• Caminhos de execução, incluindo arquivos de workflow, referências a workflows reutilizáveis, grupos de executores, ambientes de implantação, scripts de release e jobs agendados.
• Saídas de dados, incluindo webhooks, publicação de pacotes, publicação de documentação, backups, mirrors, integrações de issues e serviços de notificação.

O inventário deve explicar a finalidade da credencial em linguagem simples. «Token de CI» não é suficiente. «Ler o código e publicar o pacote interno de linha de comando quando uma tag de release assinada for enviada» informa ao próximo mantenedor o que testar e qual risco surge se algo falhar.

Você encontrará entradas que ninguém reconhece. Não deixe um nome plausível mantê-las ativas. Peça evidências: onde estão configuradas, qual job as usou recentemente, o que podem fazer e quem será responsável por elas depois da transferência. Se a resposta continuar vaga, programe a remoção. Credenciais desconhecidas costumam se tornar conhecidas somente depois de um incidente.

Credenciais pessoais tornam a transferência frágil

Qualquer caminho de produção ou release que dependa do token pessoal de um mantenedor já deveria ter sido substituído. A mudança de projeto apenas expõe a fragilidade.

Credenciais pessoais criam dois modos de falha. O primeiro é óbvio: o antigo mantenedor pode continuar com acesso depois de deixar o projeto. O segundo é mais comum: a conta é desativada ou o token expira, e um caminho de release quebra justamente quando a equipe que recebeu o projeto mais precisa dele. Muitas equipes respondem pedindo ao antigo mantenedor que crie outro token. Isso resolve a falha imediata e torna a dependência ainda mais forte.

Substitua credenciais pessoais por uma identidade de serviço somente quando o serviço realmente precisar de uma identidade duradoura. Dê a ela o menor conjunto de permissões capaz de realizar sua função documentada. Um publicador de releases pode precisar de permissão para publicar um pacote. Não precisa de administração ampla da organização nem de acesso a todos os repositórios.

Não confunda um usuário de máquina com uma identidade de serviço bem administrada. Um usuário de máquina é apenas uma conta usada pela automação. Ele ainda pode ter uma senha desconhecida, um e-mail pessoal de recuperação, associação ampla e nenhum responsável. Trate-o como uma identidade normal, com um ciclo de vida: crie-o deliberadamente, documente seu responsável, revise suas associações e remova-o quando sua função terminar.

É aqui que falha o conselho popular de «usar apenas uma conta compartilhada de automação». Ele é popular porque faz a automação funcionar rapidamente e evita o esforço de entender cada integração. Também concentra permissões sem relação entre si em uma única identidade. Quando um projeto muda de equipe, ninguém consegue revogar o acesso dele sem colocar em risco todos os outros projetos que dependem da mesma conta.

Separe as identidades por finalidade operacional. Um leitor de builds, um publicador de releases e um responsável por implantações em produção geralmente precisam de privilégios e responsáveis diferentes. Essa separação torna a revogação menos arriscada e a investigação de incidentes mais clara.

Verifique também os tokens pertencentes a usuários fora do host Git. Um script de implantação pode ler um token de um segredo de CI, mas esse token pode pertencer à conta de nuvem de alguém que saiu. O local do segredo não informa sua autoridade. Siga-o até o emissor e examine as permissões ali.

Chaves de implantação e instalações de apps precisam de revisões separadas

Chaves de implantação, apps de hospedagem Git e integrações OAuth fornecem acesso ao repositório, mas falham de maneiras diferentes. Tratá-los como uma única lista leva a revogações mal feitas.

Uma chave de implantação geralmente é uma chave pública SSH associada a um repositório. Ela pode conceder acesso de leitura ou escrita, dependendo de como foi configurada. Seu ponto forte é a associação restrita. Sua fraqueza é a identidade limitada: a chave diz pouco sobre o sistema que guarda a parte privada. Se um comentário diz «servidor de build» e esse servidor mudou de mãos duas vezes, o registro do repositório não vai ajudá-lo.

Para cada chave de implantação, confirme quatro fatos: onde a chave privada está, qual processo a usa, se ela precisa de permissão de escrita e quem é responsável pelo host ou cofre de segredos que a armazena. Remova o acesso de escrita das chaves que apenas baixam o código. Remova qualquer chave que você não consiga associar a um sistema ativo e a um responsável identificado.

Uma instalação de aplicativo apresenta o problema oposto. Em geral, ela tem identidade, permissões e histórico de eventos melhores, mas pode estar instalada em muitos repositórios. Removê-la de um projeto pode não interromper um serviço relacionado em outro local. Examine as permissões solicitadas pelo app, o escopo da instalação, o processo de rotação da chave privada, as URLs de callback e a conta da organização que pode alterar a instalação.

A documentação do GitHub separa as chaves de implantação dos GitHub Apps por um bom motivo. As chaves de implantação são associadas a repositórios, enquanto um app recebe permissões por meio de uma instalação e usa suas próprias credenciais. Não presuma que excluir uma chave de implantação afeta o acesso de um app, ou que desinstalar um app invalida uma chave SSH. São caminhos de autoridade independentes.

As integrações OAuth merecem a mesma desconfiança. Elas podem agir em nome de um usuário, em vez de usar uma identidade dedicada de aplicativo. Durante uma transferência, determine se a autorização da integração depende de um antigo mantenedor. Se depender, transfira-a para uma identidade de serviço compatível ou remova-a. Esperar alguém deixar a empresa não é um plano de revogação.

Arquivos de workflow podem conceder mais autoridade do que seus nomes sugerem

Um workflow que parece executar testes ainda pode obter credenciais, chamar workflows reutilizáveis, gravar no repositório ou acionar sistemas de implantação. Leia o arquivo antes de decidir que seu acesso é inofensivo.

Examine toda a configuração executável do repositório, não apenas o workflow que faz os releases. Isso inclui definições de CI, scripts chamados por essas definições, configurações de atualização de dependências, manifestos de implantação, código de infraestrutura, configurações de publicação de pacotes e scripts acionados por comentários ou pull requests.

Preste atenção aos pontos em que um job atravessa um limite de confiança. Exemplos comuns incluem um workflow que troca um token de identidade por uma função na nuvem, um job que executa código de um pull request com permissão de escrita no repositório ou um workflow reutilizável obtido de outro repositório. O nome do workflow pode dizer «lint». As permissões contam a verdade.

A documentação de Actions do GitHub alerta que pull_request_target é executado no contexto do repositório base e pode acessar privilégios que um workflow comum de pull request não tem. Esse evento não é automaticamente errado. O problema é combiná-lo com código de pull request não confiável ou scripts que um usuário externo pode influenciar. Durante uma transferência, encontre esses workflows e faça com que a equipe que recebe o projeto os aceite explicitamente.

Uma busca simples no repositório encontra muitas referências óbvias. Execute-a localmente depois de baixar todo o histórico do repositório necessário para a inspeção:

git grep -nE '(AWS_|AZURE_|GCP_|TOKEN|SECRET|DEPLOY|PUBLISH|ssh |curl |webhook)' -- \\
  '.github' '.gitlab-ci.yml' 'scripts' 'infra' 'package.json' 2\u003e/dev/null

Espere uma saída parecida com esta:

.github/workflows/release.yml:42:  id-token: write
scripts/publish.sh:18: curl -H "Authorization: Bearer $REGISTRY_TOKEN"
infra/deploy.sh:9: ssh -i "$DEPLOY_KEY" "$DEPLOY_HOST"

O comando não prova que existe um segredo ou que um job é perigoso. Ele cria uma fila de revisão. Siga cada resultado até o emissor da credencial, o escopo da permissão e o caminho de falha. Procure também referências a workflows fora do repositório, porque o código pode herdar autoridade por meio de um workflow reutilizável que este repositório não controla.

Não conceda padrões amplos apenas para fazer um workflow herdado passar. Corrija as permissões declaradas pelo job e teste a única ação que ele precisa realizar. Uma transferência é um bom momento para remover permissões que sobreviveram apenas porque ninguém queria mexer em um pipeline antigo.

Revogue em uma ordem que preserve evidências e evite interrupções

A revogação precisa de sequência. Se você excluir tudo primeiro, pode perder as evidências necessárias para identificar uma dependência ativa. Se esperar uma documentação perfeita, o acesso antigo pode permanecer indefinidamente.

Congele as mudanças discricionárias durante a revisão. O responsável que recebe o projeto deve saber se uma nova instalação de app, uma nova chave de implantação ou um novo administrador da organização aparece antes que a linha de base esteja completa. Isso não exige interromper o desenvolvimento normal, mas exige visibilidade das mudanças.

Faça uma exportação ou um snapshot registrado de membros, listas de colaboradores externos, chaves de implantação, instalações de apps, webhooks, metadados de segredos de CI, relações de confiança na nuvem e eventos recentes de auditoria. Não armazene valores de segredos no registro. Armazene identificadores, escopos, responsáveis, contexto de criação quando disponível e o momento em que foram inspecionados.

Depois, siga esta ordem:

1. Remova o acesso direto de antigos mantenedores e reduza os antigos administradores da organização quando a transferência exigir isso.
2. Desative ou desinstale integrações desconhecidas e revogue chaves de implantação sem responsável ativo.
3. Substitua credenciais pessoais conhecidas por identidades de serviço e teste o caminho exato de build, publicação ou implantação.
4. Troque segredos compartilhados, como segredos de webhook, chaves privadas de aplicativos e credenciais de registros, depois que a substituição funcionar.
5. Revise eventos de auditoria e jobs que falharam por um período compatível com o ritmo de releases do projeto e remova as exceções temporárias.

A ordem separa autoridade desconhecida de dependências conhecidas. Uma chave de implantação desconhecida não fornece nenhuma função sustentada, então remova-a cedo. Uma credencial de release conhecida precisa ser substituída primeiro, caso contrário você transforma uma correção de segurança em uma interrupção evitável.

Use um caminho de emergência planejado para uma substituição que falhar. Ele deve indicar quem pode restaurar o serviço, por quanto tempo a exceção permanece válida e como a equipe a registrará. Não restaure o token amplo de um mantenedor que saiu porque o release está atrasado. Crie uma credencial temporária e restrita sob a responsabilidade atual, registre a exceção e remova-a depois do reparo.

O acesso dos agentes deve seguir o mesmo limite de responsabilidade

Agentes autônomos de programação podem editar código, chamar APIs, usar SSH, publicar artefatos e afetar a infraestrutura por meio das ferramentas associadas a eles. Uma transferência de repositório que ignora o acesso dos agentes deixa uma grande lacuna na revisão.

Não pergunte apenas quais pessoas podem executar um agente. Pergunte quais processos de agente podem agir em nome do repositório, quais ferramentas podem chamar, quais credenciais essas ferramentas usam e se um revisor conseguirá reconstruir uma ação específica depois. Um agente executado a partir do shell de um desenvolvedor, de um job de CI ou de um executor remoto pode ter autoridades diferentes, mesmo usando o mesmo modelo.

Mantenha credenciais de longa duração fora do prompt e dos arquivos de trabalho do agente. Passar um segredo por variáveis de ambiente ou pela saída de uma ferramenta torna esse segredo disponível para logs, subprocessos, commits acidentais e para o próprio contexto do agente. Ocultar um valor em um visualizador de logs não torna o limite entre processos seguro.

Para equipes que usam o Sallyport, o app para Mac pode manter as credenciais HTTP e SSH em seu cofre criptografado enquanto um agente compatível com MCP solicita uma ação por meio do shim local, em vez de receber a credencial. Os registros de sessão e atividade dão ao responsável que recebe o projeto registros separados das execuções dos agentes e das chamadas individuais, algo mais útil que uma transcrição quando uma transferência precisa ser revisada.

Durante a transição, revogue sessões de agentes associadas a estações de trabalho ou processos antigos e faça com que o novo responsável aprove novas execuções. Depois, examine o uso de cada credencial: uma busca de código somente leitura e uma implantação em produção não devem seguir a mesma expectativa de aprovação. A ideia não é tornar cada comando difícil. É tornar as chamadas poderosas visíveis para alguém que responda pelas consequências.

Um inventário escrito dos agentes deve incluir o escopo do repositório, o local de execução, os canais de ferramentas, o responsável pela credencial, o responsável pela ação e a ação de revogação de emergência. Se você não consegue preencher esses campos, o agente tem um acesso que o projeto não pode transferir com responsabilidade.

Os registros de auditoria precisam mostrar quem alterou o controle

Um log que diz «token usado» é insuficiente depois de uma mudança de proprietário. Você precisa saber de quem era o token, qual processo o usou, o que fez, qual repositório foi alvo e se a ação era permitida sob a nova responsabilidade.

Mantenha juntos no arquivo de transferência ou no sistema de incidentes os eventos de auditoria do repositório, os registros de execução de CI, os registros de auditoria da nuvem, os eventos do registro de pacotes e os registros das ações dos agentes. Eles não terão o mesmo formato, e tudo bem. O importante é ter uma referência temporal comum e identificadores suficientes para acompanhar um evento entre os sistemas.

Teste os registros antes de declarar a transferência concluída. Faça uma alteração inofensiva por cada caminho compatível: um push normal de desenvolvedor, um evento de automação de pull request, um job agendado se existir, uma publicação de pacote em um destino que não seja de produção quando disponível e uma ação de agente que exija aprovação. Confirme que a equipe que recebeu o projeto consegue encontrar as evidências sem ligar para os antigos mantenedores.

Evidências contra adulteração são úteis, mas não substituem retenção e controle de acesso. Um log somente para inclusão informa se alguém alterou um registro. Ele não ajuda se a fonte do evento nunca registrou a chamada, se a retenção do log expirou ou se nenhuma pessoa atual consegue ler o registro durante um incidente.

Defina uma data de revisão depois da mudança. A primeira revisão encontra automações que rodam apenas semanal ou mensalmente, e a segunda encontra pessoas que pedem uma exceção porque algo parou de funcionar. Essas exceções são material de diagnóstico. Cada uma revela uma dependência que o inventário inicial não encontrou.

A equipe que recebe o projeto deve conseguir remover todos os caminhos de acesso

Uma transferência está concluída quando a equipe que recebe o projeto consegue revogar todos os caminhos de acesso relevantes sem precisar que a equipe antiga explique um segredo, encontre uma máquina ou aprove uma mudança. Esse padrão é mais rigoroso que uma tela de transferência do repositório e evita a falha que continua se repetindo: a propriedade muda no papel enquanto o controle permanece espalhado em outros lugares.

Comece pelo artefato menos atraente, o inventário de acesso. Coloque um responsável e um procedimento de revogação ao lado de cada serviço conectado. Depois, remova as entradas que não têm nenhum dos dois. O trabalho parece tedioso até a primeira rotação urgente de credenciais. Nesse momento, o inventário é a diferença entre um reparo contido e uma semana de tentativas.