Partilhar via

Implemente a integração do GitHub Advanced Security com o Microsoft Defender for Cloud

Este guia guia-o por todos os passos de configuração para o ajudar a tirar o máximo proveito da segurança de aplicações nativas na cloud da Microsoft, integrando o GitHub Advanced Security (GHAS) e o Microsoft Defender for Cloud (MDC).

Ao seguir este guia, você:

  • Configura o teu repositório GitHub para cobertura do Microsoft Defender for Cloud (MDC)
  • Criar um fator de risco em tempo real
  • Testar casos de uso reais no MDC
  • Código de ligação para recursos cloud
  • Inicie uma campanha de segurança no GitHub, aproveitando o contexto de runtime para priorizar os alertas de segurança GHAS com base no contexto de runtime
  • Criar problemas no GitHub a partir do MDC para iniciar a remediação
  • Fechar o ciclo entre as equipas de Engenharia e Segurança

Pré-requisitos

Aspeto Detalhes
Requisitos Ambientais - Conta GitHub com conector criado no Microsoft Defender for Cloud (MDC)
- Licença GitHub Advanced Security (GHAS)
- Defender CSPM ativado na subscrição
- GitHub Security Copilot (opcional para remediação automática)
Papéis e Permissões - Permissões de Administrador de Segurança
- Leitor de Segurança na Subscrição Azure (para visualizar as conclusões no MDC)
- Proprietário da organização GitHub
Ambientes Cloud - Disponível apenas em Nuvens Comerciais (não no Governo dos EUA, Governo da China ou outras nuvens soberanas)

Prepare seu ambiente

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

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

Observação

Certifica-te de que o repositório que usas para a integração é privado.

Se quiseres usar um repositório de exemplo, clona o repositório seguinte para a tua organização no GitHub. Este repositório tem GHAS ativado e está integrado num tenant Azure com DCSPM ativado:build25-woodgrove/mdc-customer-playbook. Este repositório destina-se aos clientes a testarem a integração com o Microsoft Defender for Cloud e o GHAS.

No repositório, siga estes passos:

  1. Vá para Configurações.
  2. No painel esquerdo, selecione Segredos e Variáveis>Ações.
  3. Adicione os seguintes segredos ao nível do repositório ou da organização:
Variable Description
ACR_ENDPOINT O servidor de login do Azure Container Registry
ACR_PASSWORD A palavra-passe do Azure Container Registry
ACR_USERNAME O nome de utilizador do Azure Container Registry

Captura de ecrã da interface do GitHub com o menu 'Segredos e variáveis' selecionado e o botão 'Novo secreto do repositório' visível.

Observação

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

Pode encontrar esta informação no portal Azure seguindo estes passos:

  1. Selecione o ACR para o qual deseja fazer a implantação.

  2. Selecione Teclas de Acesso em Definições.

    Captura de ecrã do portal Azure a mostrar a página de Chaves de Acesso para um registo de contentores com campos de servidor de login, nome de utilizador e palavra-passe visíveis.

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

  4. Seleciona o fluxo de trabalho Build and Push to ACR e executa o fluxo.

    Captura de ecrã da secção Ações do repositório do GitHub mostrando o histórico de workflow e opções para ativar manualmente o fluxo.

  5. Verifique se a imagem foi implementada no seu Azure Container Registry.

  6. Para o repositório de exemplo fornecido: A imagem deve estar num registo chamado mdc-mock-0001 com a tag mdc-ghas-integration.

  7. Implemente a mesma imagem que um contentor em execução no seu cluster. Uma forma de completar este passo é ligando-te ao cluster e usando o kubectl run comando. Aqui está um exemplo para o AKS:

    1. Defina a subscrição 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. Implemente a imagem:

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

Passo 2: Crie o primeiro fator de risco - Regra Crítica para o Negócio

Um dos fatores de risco que o Defender for Cloud deteta para esta integração é a criticidade empresarial. As organizações podem criar regras para rotular diferentes recursos como críticos para o negócio.

  1. No portal Microsoft Defender for Cloud (portal Azure), vá a Definições de Ambiente, escolha Criticidade de Recursos.

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

    Captura de ecrã da interface do Microsoft Defender para Cloud a mostrar o mosaico de Criticidade de Recursos e o link do portal Abrir o Microsoft Defender no painel direito.

  3. Selecionar Criar uma nova classificação.

    Captura de ecrã da página de definições do Microsoft Defender XDR com o link 'Criar uma nova classificação' destacado a vermelho.

  4. Introduza um nome e descrição.

  5. Escolha recurso na Cloud no construtor de consultas.

  6. Escreva uma consulta para definir o Nome do Recurso igual ao nome do contentor que implementou no seu cluster para validação e selecione Próximo.

    Captura de ecrã do Microsoft Defender query builder com Nome de Recurso igual ao filtro 'mdc-ghas-container' aplicado em Cloud resource.

  7. Na página de Pré-visualização dos Ativos , se o Microsoft Defender já detetou o seu recurso, o nome do contentor aparece com o tipo de ativo sendo K8s-container ou K8s-pod. Mesmo que ainda não seja visível na página de recursos de pré-visualização, continue com o próximo passo. O Microsoft Defender aplica a etiqueta de criticidade ao contentor assim que detetado. Este processo pode demorar até 24 horas.

  8. Escolha um nível de criticidade, depois reveja e submeta a sua regra de classificação.

Passo 3: Valide que o seu ambiente está pronto

Observação

Pode demorar até 24 horas após a aplicação dos passos anteriores para ver os resultados seguintes.

  1. Testa se a varredura sem necessidade de agente do GitHub detecta o repositório.

  2. Vai ao Cloud Security Explorer e faz a consulta. Captura de ecrã do query builder no Cloud Security Explorer com filtros definidos para repositórios do GitHub e imagens de contentores, mostrando resultados de pesquisa.

  3. Valide que o MDC (no ACR) digitalizou a imagem do contentor e usou-a para criar um contentor. Na sua consulta, adicione as condições para a sua implementação específica. Captura de ecrã do Cloud Security Explorer mostrando uma consulta com filtros para repositórios do GitHub e imagens de contentores, mostrando os resultados da varredura.

  4. Verifique que o contentor está a funcionar e que o MDC analisou o cluster AKS. Captura de ecrã do construtor de consultas Cloud Security Explorer com filtros para repositórios do GitHub e imagens de contentores, mostrando resultados com vulnerabilidades e utilização de contentores.

  5. Valide que os fatores de risco estão corretamente configurados do lado do MDC. Procure o nome do seu contentor na página de inventário do MDC e deverá vê-lo marcado como crítico.

Passo 4: Criar uma Campanha no GitHub

Como o fluxo de trabalho lança uma imagem que cria um contentor a correr com um dos fatores de risco (crítico para o negócio), os programadores podem ver os fatores de risco no GitHub.

Observação

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

  1. No GitHub, vai à organização GitHub que usaste para os testes de configuração.

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

    Captura de ecrã da interface do GitHub mostrando o separador Campanhas de Segurança > com opções para criar uma campanha a partir de filtros de código ou de análise secreta.

  3. Crie a seguinte campanha. Esta campanha mostra alertas abertos com gravidade média, onde a imagem distribuída a partir do repositório está associada a um recurso crítico. O seu repositório de testes deve ser detetado com esta campanha.

    Captura de ecrã da interface do GitHub Campaigns mostrando filtros para alertas abertos, severidade definida para crítico e médio, e risco em tempo de execução como recurso crítico.

  4. Selecione Guardar e depois Publicar como campanha.

  5. Insira a informação necessária e depois publique a campanha.

Passo 5: Avaliar Recomendações de Código para Nuvem

Utilize a experiência do SDLC da Recomendação C2C e o enriquecimento dos alertas de segurança para compreender o estado das questões de segurança e atribuir a recomendação de resolução à equipa de engenharia apropriada, através da ligação entre os alertas de segurança do Dependabot e os CVEs correspondentes na aba CVE associado de recomendação em tempo de execução.

Consulte as Recomendações C2C

  1. No portal MDC, vá à aba de Recomendações.
  2. Procura o nome do contentor que criaste e abre uma das recomendações que diz, **Atualizar ***.
  3. Se usou o repositório de exemplo, procure: Recomendação de expansão de braçadeiras atualizada.
  4. Vá ao separador Remediation Insights e visualize o código no diagrama da nuvem.
  5. O diagrama mapeia o teu contentor em execução, para a imagem do contentor no repositório de código, para o repositório de código de origem no GitHub.

Captura de ecrã do separador Remediation Insights que mostra um diagrama das fases de desenvolvimento com as fases Código, Construção, Envio e Execução ligadas por linhas tracejadas.

Enriquecimento bidirecional

  1. Selecione o separador CVEs associados . Repara que alguns CVEs têm um link na coluna Alertas Relacionados no GitHub.

    Captura de ecrã do separador CVEs Associados a mostrar CVE-2025-5889 com pontuação CVSS 3.1, versão de correção 2.0.2, e uma ligação Ver no GitHub em Alertas Relacionados.

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

Mobilização de engenharia

Para fechar o ciclo entre as equipas de Segurança e Engenharia, pode criar um problema no GitHub para uma aplicação containerizada, priorizando para a equipa de engenharia as questões de segurança em que devem focar-se. Esta priorização pode incluir conclusões passageiras que o GHAS não detetou, mas que o MDC detetou para CVEs que não fazem parte de dependências diretas (por exemplo, vulnerabilidades na imagem base, sistema operativo ou software de terceiros como o NGINX).

O tíquete do GitHub é gerado automaticamente com todos os CVEs encontrados no âmbito da recomendação, incluindo aqueles que têm e não têm alertas do Dependabot, correspondendo e incluindo também outro contexto de tempo de execução no repositório de origem.

Captura de ecrã da lista de problemas do GitHub mostrando três entradas, incluindo 'Update brace-expansion' e 'Update openssl' marcadas com etiquetas de segurança e vulnerabilidade.

Quando atribuis o problema, o estado do problema atualiza-se no portal MDC.

Captura de ecrã de uma edição do GitHub intitulada 'Atualizar lodash' com etiquetas de segurança e vulnerabilidades, mostrando detalhes como CVEs, fatores de risco em tempo de execução e informações de implementação.

Correções agenticas

Do lado do GitHub, se tiver uma licença GitHub Copilot, pode resolver o problema com a ajuda do GitHub Coding Agent:

  1. Atribui o GitHub Coding Agent ao problema.
  2. Revê a correção gerada.
  3. Se parecer razoável, aplica a correção.
  4. Observe a atualização do estado do problema em MDC para Fechado.

Conteúdo relacionado

  • Last updated on