Como sanitizar logs do GitHub antes de partilhar

Os logs do GitHub Actions são uma evidência útil quando uma compilação falha, mas também podem conter mais contexto do que o suporte ou um assistente de IA precisa: URL do repositório, branch, host interno, caminho local, título de pull request, email, cabeçalho de autorização ou um token impresso por um comando.

Trabalhe numa cópia, remova o contexto privado desnecessário, reveja o resultado e só depois o partilhe. Isto reduz a divulgação, mas não substitui a resposta a incidentes: se aparecer um segredo ativo no log, revogue-o ou faça a rotação junto do fornecedor primeiro.

O que verificar

Procure na cópia:

Mantenha a mensagem de erro, o código de saída, as versões relevantes e o input mínimo. Substitua os valores por marcadores estáveis como <GITHUB_TOKEN> ou <HOST_INTERNO>, preservando a forma do problema sem revelar o valor literal.

Fluxo local

  1. Copie o log para um ficheiro local temporário e mantenha o original no ambiente seguro.
  2. Procure token, secret, password, Authorization, BEGIN PRIVATE KEY, URLs, hosts e emails. Reveja também cadeias opacas longas.
  3. Substitua os valores sensíveis por marcadores tipificados, reutilizando o mesmo marcador para valores repetidos.
  4. Remova passos sem relação, corpos de pedidos e dumps do ambiente.
  5. Leia o ficheiro final do princípio ao fim, incluindo blocos de código, linhas próximas e anexos.
  6. Partilhe a cópia sanitizada no canal de suporte aprovado e registe os tipos de valores removidos.

O ScrubForge pode ajudar na limpeza local de uma cópia de log ou configuração. O rascunho fica no separador do navegador até decidir copiar o resultado. Reveja-o na mesma: nenhuma ferramenta sabe automaticamente que identificadores internos a sua organização pode divulgar.

O que o masking do GitHub não garante

O manual de Secrets do GitHub documenta a ocultação automática de valores secretos suportados nos logs dos workflows, mas isso não é uma revisão completa. Valores transformados, codificados, divididos ou estruturados podem não ser reconhecidos. O GitHub recomenda também mascarar valores sensíveis que não estejam guardados como GitHub Secrets e evitar comandos que imprimam segredos.

Se um workflow tiver de usar um segredo externo para um diagnóstico, mascare-o antes de qualquer comando o poder imprimir. Mesmo assim, reveja o log antes de o exportar: pode revelar nomes de repositórios, topologia, dados de utilizadores ou um valor reconstruído.

Se um segredo já foi exposto

Revogue-o ou faça a rotação segundo o procedimento do fornecedor, descubra onde o log foi guardado e reveja os acessos. Apagar uma linha da vista atual não remove cópias em artefactos, caches, tickets, exportações de chat ou no histórico do repositório. Se o segredo entrou no histórico Git, siga depois da revogação os passos de coordenação e reescrita indicados pelo GitHub.

Checklist final

  1. Todos os valores semelhantes a credenciais foram removidos ou substituídos?
  2. Os segredos ativos expostos foram revogados ou rodados?
  3. URLs, hosts internos e dados pessoais são necessários para o diagnóstico?
  4. Anexos, capturas de ecrã e comandos colados também foram revistos?
  5. O log mantém o erro, as versões e o contexto de reprodução?

Veja também como sanitizar uma configuração Palo Alto PAN-OS antes de a partilhar e o ScrubForge.

Perguntas frequentes

É suficiente apagar um token de um log do GitHub?

Não. Considere o segredo ativo comprometido, revogue-o ou faça a rotação e depois limpe a cópia a partilhar.

O GitHub oculta todos os segredos nos logs do Actions?

Não. Valores suportados podem ser mascarados, mas os transformados ou estruturados podem escapar. Reveja os logs e mascare explicitamente os valores gerados.

O que devo remover antes de partilhar um log?

Tokens, cabeçalhos de autorização, URLs privadas, hosts internos, dados pessoais e payloads desnecessários.

Posso sanitizar logs localmente?

Sim, mas reveja manualmente o resultado e trate os segredos ativos separadamente.