Skip to main content

Esta versão do GitHub Enterprise Server foi descontinuada em 2026-04-23. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a última versão do GitHub Enterprise Server. Para obter ajuda com a atualização, entre em contato com o suporte do GitHub Enterprise.

Ferramentas de investigação para incidentes de segurança

As principais ferramentas GitHub que você pode usar para investigar incidentes de segurança, qual é o melhor uso para cada ferramenta, e considerações comuns que afetam a disponibilidade dos dados.

Use essa referência para decidir quais GitHub ferramentas usar durante uma investigação de segurança, quais perguntas cada ferramenta pode responder e quais fatores podem afetar os dados que você pode ver.

Observação

A disponibilidade de cada ferramenta (e os dados que ela fornece) varia de acordo GitHub com o plano, sua função e permissões, habilitação de recursos e configuração pré-incidente (por exemplo, streaming de log de auditoria e divulgação de endereço IP exigem configuração anterior).

Exibição de atividade

Utilização

  • Obtenha uma visão geral da atividade em um repositório específico, incluindo fusões, pushes, pushes forçados, criações e exclusões de ramificações, atribuídas a atores específicos durante um período definido.
  • Correlacionar aparências suspeitas de código com pushs ou mesclagens relacionados.
  • Responda a perguntas sobre quando uma alteração foi feita, quem fez isso, em qual ramificação, e explore o diff ou o histórico de commits.

Permissions

Leia o acesso ao repositório.

Principais recursos

Anotações e limitações

  • O modo de exibição de atividade é melhor usado como uma superfície inicial de navegação e correlação; ele não tem a mesma completude ou poder de consulta que as exportações de logs de auditoria em bruto.
  • Alguns incidentes exigem correlação entre repositórios ou organizações, o que pode ser mais fácil no log de auditoria.

Logs de auditoria

Utilização

  • Responda a perguntas sobre o que mudou, quando e por quem em uma empresa ou organização.
  • Investigue os eventos que podem ter habilitado o comprometimento ou indique-o, como alterações na associação, funções, permissões ou geração ou uso de tokens de acesso, etc.
  • Atribua ações relevantes à segurança a um ator (usuário ou integração) e crie uma linha do tempo de investigação.
  • Filtrar por ator, ação, endereço IP (se habilitado) ou token, para identificar a atividade suspeita ou o uso do token de rastreamento.
  • Correlacionar a atividade em vários repositórios ou organizações.

Permissions

  • Para exibir o log de auditoria da organização, você precisa ser um proprietário da organização.
  • Para exibir o log de auditoria da empresa, você precisa ser um administrador corporativo.
  • Para exibir o log de segurança (conta pessoal), você precisa ser o proprietário da conta.
  • Para exibir dados de log de auditoria exportados para um sistema externo de SIEM (Gerenciamento de Eventos e Informações de Segurança), sistema de gerenciamento de logs ou outras ferramentas e serviços, você precisa de acesso a esse sistema.

Principais recursos

Anotações e limitações

  • GitHub fornece três logs de auditoria: logs de segurança corporativos, de organização e de usuários.
  • A GitHub interface do usuário do log de auditoria tem recursos limitados de filtragem e pesquisa . Por esse motivo, recomendamos que as empresas transmitam o log de auditoria empresarial para um SIEM externo ou sistema de gerenciamento de logs para consultas mais avançadas.
    • O streaming de log de auditoria para um SIEM externo ou sistema de gerenciamento de logs requer configuração anterior. Consulte Como transmitir o log de auditoria para sua empresa.
    • Sem o streaming de log de auditoria, você não poderá executar consultas mais complexas, como correlacionar eventos entre organizações ou repositórios ou pivotar de um token específico para todos os eventos relacionados.
    • Os dados de eventos do Git são incluídos no fluxo.
  • É recomendável transmitir eventos de solicitação de API; isso requer configuração anterior. Consulte Como transmitir o log de auditoria para sua empresa.
  • Para empresas na plataforma GitHub Enterprise Cloud, recomendamos exibir endereços IP nos logs de auditoria; isso requer configuração prévia. Consulte Exibir endereços IP no log de auditoria da sua empresa.
  • Planos diferentes GitHub têm diferentes ofertas de disponibilidade de dados e retenção de dados:
    • GitHub Free e GitHub Team os planos não podem exibir a atividade de API ou eventos Git.
    • As organizações autônomas (organizações que não fazem parte de uma empresa) não podem transmitir os logs de auditoria, não podem exibir eventos de solicitação de API e estão limitadas a 7 dias para dados de eventos do Git.
    • Para empresas em GitHub Enterprise Cloud:
      • Se sua empresa usar Enterprise Managed Users, o log de auditoria também incluirá logs de segurança do usuário (eventos relacionados a contas de usuário, como atividade de logon e uso de token).
      • Se sua empresa _não usar_Enterprise Managed Users, o GitHub log de auditoria inclui apenas eventos relacionados à conta corporativa e às organizações dentro dela.
  • Os logs de auditoria não incluem a telemetria de exibição de página ou de navegação no repositório.

Grafo de dependência

Utilização

  • Verifique se um repositório depende de um pacote vulnerável ou comprometido (ou versão).
  • Examine as dependências novas ou suspeitas que podem ter sido introduzidas durante um incidente.
  • Filtrar e explorar dependências por ecossistema ou relação (direta ou transitiva).
  • Exporte uma fatura de software de materiais (SBOM) para fins de auditoria ou para preservar evidências.

Permissions

  • Escreva ou mantenha o acesso ao repositório.

Principais recursos

Anotações e limitações

  • O grafo de dependência é gerado a partir de arquivos de manifesto/trava suportados (e envios opcionais realizados durante o tempo de build), o que pode resultar em um grafo que seja incompleto ou diferente do que foi realmente criado e implantado. Para obter a visão mais precisa, especialmente para dependências resolvidas durante a CI/build, você deve complementar o grafo de dependência com a submissão de dependências no tempo de build (ou outra proveniência de build, como SBOMs).
          GitHub pesquisa de código

Utilização

  • Pesquise indicadores de comprometimento (IoCs) em repositórios, como fluxos de trabalho mal-intencionados conhecidos ou nomes de pacote.
  • Avalie rapidamente o potencial raio de explosão verificando se padrões de código suspeitos, como segredos vazados ou snippets de código malicioso, aparecem em outros repositórios na organização.
  • Delimite a pesquisa por diferentes qualificadores que podem ser úteis durante um incidente, por exemplo:
    • Pesquise em um repositório, organização ou empresa específico (usando os repo:``org:``enterprise: qualificadores .
    • Pesquise dentro de caminhos de arquivo específicos (path:.github/workflows repo:ORG-NAME/REPO-NAME).

Permissões exigidas

  • Para pesquisar em repositórios públicos, você deve estar conectado à sua GitHub conta.
  • Para pesquisar entre repositórios privados, você deve ter acesso de leitura a esses repositórios.

Principais recursos

Anotações e limitações

  • Dá suporte à pesquisa regex.
  • Pesquisa apenas no branch padrão de um repositório. Se o código suspeito tiver sido introduzido em um branch não padrão e não tiver sido mesclado, ele não será encontrado pela pesquisa de código.
  • Você pode usar a pesquisa de código para determinar se um padrão ou IoC está presente, mas ele não fornece contexto, como quando o código foi adicionado ou por quem. Você deve usar a pesquisa de código em conjunto com outras ferramentas, como logs de auditoria, visualização de atividade, visualização de atribuição de culpa, histórico de commits e histórico de solicitações de pull de um repositório.

Visão geral de segurança e alertas de segurança

Utilização

  • Confira uma exibição de alto nível de todos os alertas de segurança (secret scanning, code scanning e Dependabot alertas) em repositórios em uma organização ou empresa.
  • Faça a triagem do que GitHub já detectou e identifique quais repositórios são afetados.
  • Acompanhe novos alertas criados durante um incidente (que pode indicar exploração ativa ou propagação).

Permissões exigidas

  • Para ver os dados das organizações no nível empresarial, um administrador corporativo deve ter a função de proprietário ou gerente de segurança da organização nas organizações relevantes.
  • Para ver os dados dos repositórios no nível da organização, a função de proprietário ou gerente de segurança da organização é necessária.

Principais recursos

Anotações e limitações

  • Alertas para segredos vazados, código vulnerável, dependências vulneráveis e malware só ficarão visíveis se os recursos relevantes estiverem habilitados e configurados antes do incidente.

Execuções de fluxo de trabalho e registros de logs

Utilização

  • Confirme o que foi executado em CI/CD em um determinado momento (como os comandos executados ou a dependência instalada).
  • Investigue execuções suspeitas de fluxo de trabalho, como aquelas disparadas por um usuário desconhecido ou em um momento incomum, para ver quais ações foram executadas, quais segredos foram acessados e qual código foi executado.
  • Determine se um fluxo de trabalho teve acesso a algum segredo.

Permissões exigidas

  • Leia o acesso ao repositório.

Principais recursos

Anotações e limitações

  • GitHub oculta automaticamente os segredos dos logs de fluxo de trabalho.
  • Por padrão, os logs de fluxo de trabalho são mantidos por GitHub 90 dias, mas você pode configurar esse período de retenção para ser maior (até 400 dias para repositórios privados).