Compartilhar via


Implantar a integração do GitHub Advanced Security com o Microsoft Defender para Nuvem

Este guia orienta você por todas as etapas de instalação para ajudá-lo a aproveitar ao máximo a segurança de aplicativos nativos de nuvem da Microsoft integrando o GitHub Advanced Security (GHAS) e o Microsoft Defender para Nuvem (MDC).

Seguindo este guia, você:

  • Configurar seu repositório GitHub para cobertura do Microsoft Defender para Nuvem (MDC)
  • Criar um fator de risco de tempo de execução
  • Testar casos reais de uso no MDC
  • Vincular código a recursos de nuvem
  • Inicie uma campanha de segurança no GitHub, aproveitando o contexto de runtime para priorizar os alertas de segurança do GHAS com base no contexto de runtime
  • Criar questões no GitHub a partir do MDC para iniciar a remediação
  • Fechar o loop entre as equipes de Engenharia & Segurança

Pré-requisitos

Aspecto Detalhes
Requisitos ambientais - Conta do GitHub com um conector criado no Microsoft Defender para Nuvem (MDC)
- Licença de GHAS (Segurança Avançada) do GitHub
- Defender CSPM habilitado na assinatura
– GitHub Security Copilot (opcional para correção automatizada)
Funções &permissões - Permissões de administrador de segurança
- Leitor de Segurança na Assinatura do Azure (para exibir os resultados no MDC)
– Proprietário da organização do GitHub
Ambientes de nuvem - Disponível apenas em nuvens comerciais (não em US Gov, China Gov ou outras nuvens soberanas)

Prepare o seu ambiente

Etapa 1: Configurar o repositório GitHub e executar o fluxo de trabalho

Para testar a integração, use seus próprios repositórios ou um repositório GitHub de exemplo que já tenha todo o conteúdo para criar uma imagem de contêiner vulnerável.

Observação

Verifique se o repositório usado para a integração é privado.

Se você quiser usar um repositório de exemplo, clone o repositório a seguir para sua organização do GitHub. Esse repositório tem o GHAS habilitado e está integrado a um locatário do Azure com DCSPM habilitado:build25-woodgrove/mdc-customer-playbook. Esse repositório serve para os clientes testarem a integração do Microsoft Defender para Nuvem e GHAS.

No repositório, siga estas etapas:

  1. Vá para Configurações.
  2. No painel esquerdo, selecione Segredos e Variáveis>Ações.
  3. Adicione os seguintes segredos no nível do repositório ou da organização:
Variable Description
ACR_ENDPOINT O servidor de logon do Registro de Contêiner do Azure
ACR_PASSWORD A senha do Registro de Contêiner do Azure
ACR_USERNAME O nome de usuário do Registro de Contêiner do Azure

Captura de tela da interface do GitHub com o menu 'Segredos e variáveis' selecionado e o botão

Observação

Os nomes podem ser escolhidos livremente e não precisam seguir um padrão específico.

Você pode encontrar essas informações no portal do Azure seguindo estas etapas:

  1. Selecione o ACR no qual você deseja implantar.

  2. Selecione Chaves de Acesso em Configurações.

    Captura de tela do portal do Azure mostrando a página Chaves de Acesso para um registro de contêiner com os campos de servidor de logon, nome de usuário e senha visíveis.

  3. No repositório, selecione Ações.

  4. Selecione o fluxo de trabalho Compilar e Enviar por push para o ACR e execute o fluxo de trabalho.

    Captura de tela da seção Ações do repositório GitHub mostrando o histórico de fluxo de trabalho e as opções para disparar manualmente o fluxo de trabalho.

  5. Verifique se a imagem foi implantada no Registro de Contêiner do Azure.

  6. Para o repositório de exemplo fornecido: a imagem deve estar em um registro chamado mdc-mock-0001 com a marca mdc-ghas-integration.

  7. Implante a mesma imagem que um contêiner em execução no cluster. Uma maneira de concluir essa etapa é conectando-se ao cluster e usando o kubectl run comando. Este é um exemplo para o AKS:

    1. Defina a assinatura do cluster:

      az account set --subscription $subscriptionID
      
    2. Defina as credenciais para o cluster:

      az aks get-credentials --resource-group $resourceGroupName --name $kubernetesClusterName --overwrite-existing
      
    3. Implante a imagem:

      kubectl run $containerName --image=$registryName.azurecr.io/mdc-mock-0001:mdc-ghas-integration
      

Etapa 2: Criar o primeiro fator de risco – Regra Comercialmente Crítica

Um dos fatores de risco que o Defender para Nuvem detecta para essa integração é a criticidade dos negócios. As organizações podem criar regras para rotular recursos diferentes como comercialmente críticos.

  1. No portal do Microsoft Defender para Nuvem (portal do Azure), vá para Configurações de Ambiente, escolha Resource Criticality.

  2. No painel direito, selecione o link para abrir o Microsoft Defender.

    Captura de tela da interface do Microsoft Defender para Nuvem mostrando o bloco do Resource Criticality e o link abrir o portal do Microsoft Defender no painel direito.

  3. Selecione Criar uma nova classificação.

    Captura de tela da página de configurações do Microsoft Defender XDR com o link

  4. Insira um nome e uma descrição.

  5. Escolha o recurso de nuvem no criador de consultas.

  6. Escreva uma consulta para definir o Nome do Recurso igual ao nome do contêiner que você implantou no cluster para validação e selecione Avançar.

    Captura de tela do Construtor de Consultas do Microsoft Defender com Nome do Recurso igual ao filtro 'mdc-ghas-container' aplicado no recurso de nuvem.

  7. Na página Ativos de Visualização , se o Microsoft Defender já tiver detectado seu recurso, o nome do contêiner será exibido com o tipo de ativo sendo K8s-container ou K8s-pod. Mesmo que ainda não esteja visível na página de recursos de pré-visualização, prossiga para a próxima etapa. O Microsoft Defender aplica o rótulo de criticidade ao contêiner uma vez detectado. Esse processo pode levar até 24 horas.

  8. Escolha um nível de criticidade e, em seguida, examine e envie sua regra de classificação.

Etapa 3: validar se o ambiente está pronto

Observação

Pode levar até 24 horas após as etapas anteriores serem aplicadas para ver os resultados a seguir.

  1. Teste se a varredura sem agente do GitHub detecta o repositório.

  2. Vá para o Cloud Security Explorer e execute a consulta. Captura de tela do construtor de consultas no Cloud Security Explorer com filtros definidos como repositórios do GitHub e imagens de contêiner, mostrando os resultados da pesquisa.

  3. Valide se o MDC (no ACR) examinou a imagem do contêiner e a usou para criar um contêiner. Em sua consulta, adicione as condições para sua implantação específica. Captura de tela do Cloud Security Explorer mostrando uma consulta com filtros para repositórios do GitHub e imagens de contêiner, exibindo os resultados da verificação.

  4. Valide que o contêiner está em execução e que o MDC digitalizou o cluster AKS. Captura de tela do construtor de consultas do Cloud Security Explorer com filtros para repositórios do GitHub e imagens de contêiner, mostrando resultados com vulnerabilidades e uso de contêiner.

  5. Valide se os fatores de risco estão configurados corretamente no lado do MDC. Pesquise o nome do contêiner na página de inventário do MDC e você deverá vê-lo marcado como crítico.

Etapa 4: Criar uma campanha do GitHub

Como o fluxo de trabalho implanta uma imagem que cria um contêiner em execução com um dos fatores de risco (comercialmente crítico), os desenvolvedores podem ver fatores de risco no GitHub.

Observação

Depois de classificar o recurso como crítico, pode levar até 12 horas para que o MDC envie os dados para o GitHub. Saiba mais aqui.

  1. No GitHub, acesse a organização do GitHub usada para o teste de instalação.

  2. Selecione Segurança>Campanhas>Crie uma campanha a partir de filtros de verificação de código.

    Captura de tela da interface do GitHub mostrando a guia Campanhas de Segurança > com opções para criar uma campanha a partir de filtros de verificação de código ou segredo.

  3. Crie a campanha a seguir. Esta campanha mostra alertas abertos com gravidade média em que a imagem implantada do repositório está vinculada a um recurso crítico. Seu repositório de testes deve ser detectado dentro desta campanha.

    Captura de tela da interface do GitHub Campaigns mostrando filtros para alertas abertos, severidade definida como crítico e médio e risco de runtime como recurso crítico.

  4. Selecione Salvar e , em seguida, Publicar como campanha.

  5. Insira as informações necessárias e, em seguida, publique a campanha.

Etapa 5: Avaliar o código para recomendações de nuvem

Use a experiência do SDLC da Recomendação C2C e o enriquecimento dos alertas de segurança para entender o status dos problemas de segurança e atribuir as recomendações para resolução à equipe de engenharia adequada, com a ajuda da conexão entre alertas de segurança Dependabot e CVEs correspondentes na guia Recomendação de Runtime CVE Associada.

Exibir as recomendações do C2C

  1. No portal do MDC, vá para a guia Recomendações .
  2. Pesquise o nome do contêiner que você criou e abra uma das recomendações que diz: **Atualizar ***.
  3. Se você usou o repositório de exemplo, procure: Atualizar a recomendação de expansão de colchetes.
  4. Vá para a guia Insights de Remediação e visualize o diagrama de código para a nuvem.
  5. O diagrama mapeia seu contêiner em execução, para a imagem de contêiner no repositório de código, para o repositório de código de origem no GitHub.

Captura de tela da guia Remediation Insights mostrando um diagrama de etapas de desenvolvimento com as etapas Code, Build, Ship e Runtime vinculadas por linhas tracejadas.

Enriquecimento bidirecional

  1. Selecione a guia CVEs associados . Observe que alguns CVEs têm um link na coluna Alertas do GitHub relacionados.

    Captura de tela da guia CVEs associados mostrando CVE-2025-5889 com a pontuação CVSS 3.1, versão de correção 2.0.2, e um link Visualizar no GitHub em Alertas Relacionados do GitHub.

  2. Selecione o link Exibir no GitHub para abrir o alerta de segurança do GHAS relevante.

Mobilização de engenharia

Para fechar o loop entre as equipes de Segurança e Engenharia, você pode criar um problema do GitHub para um aplicativo em contêiner priorizando para a equipe de engenharia os problemas de segurança nos quais eles devem se concentrar. Essa priorização pode incluir a transmissão de descobertas que o GHAS não detectou, mas que o MDC identificou para CVEs que não fazem parte de dependências diretas, como vulnerabilidades na imagem de base, no sistema operacional ou em softwares de terceiros, como o NGINX.

O problema no GitHub é gerado automaticamente com todas as CVEs encontradas no escopo da recomendação; as versões com e sem alertas do Dependabot correspondem, incluindo outros contextos de tempo de execução no repositório de origem.

Captura de tela da lista de problemas do GitHub mostrando três entradas, incluindo

Quando você atribui o problema, o status do problema é atualizado no portal do MDC.

Captura de tela de um problema no GitHub intitulado 'Atualizar lodash' com tags de segurança e vulnerabilidade, mostrando detalhes como CVEs, fatores de risco em tempo de execução e informações de implantação.

Correções de agentes

No lado do GitHub, se você tiver uma licença do GitHub Copilot, poderá resolver o problema com a ajuda do GitHub Coding Agent:

  1. Atribua o GitHub Coding Agent ao problema.
  2. Examine a correção gerada.
  3. Se parecer razoável, aplique a correção.
  4. Observe a atualização do status do problema no MDC para Closed.