Compartir a través de

Implementación de la integración de Advanced Security de GitHub con Microsoft Defender for Cloud

Esta guía le guía por todos los pasos de configuración para ayudarle a sacar el máximo partido de la seguridad de aplicaciones nativas de la nube de Microsoft mediante la integración de GitHub Advanced Security (GHAS) y Microsoft Defender for Cloud (MDC).

Siguiendo esta guía, podrá:

  • Configuración del repositorio de GitHub para la cobertura de Microsoft Defender for Cloud (MDC)
  • Creación de un factor de riesgo en tiempo de ejecución
  • Prueba de casos de uso reales en MDC
  • Vinculación de código a recursos en la nube
  • Inicie una campaña de seguridad en GitHub, aprovechando el contexto en tiempo de ejecución para priorizar las alertas de seguridad de GHAS en función del contexto en tiempo de ejecución.
  • Crear incidencias de GitHub desde MDC para iniciar la solución
  • Cierre el bucle entre los equipos de ingeniería y seguridad

Prerrequisitos

Aspecto Detalles
Requisitos del entorno - Cuenta de GitHub con un conector creado en Microsoft Defender for Cloud (MDC)
- Licencia de Seguridad avanzada de GitHub (GHAS)
- CSPM de Defender habilitado en la suscripción
- GitHub Security Copilot (opcional para la corrección automatizada)
Roles y permisos - Permisos de administrador de seguridad
- Lector de seguridad en la suscripción de Azure (para ver los resultados en MDC)
- Propietario de la organización de GitHub
Entornos en la nube - Disponible solo en nubes comerciales (no en US Gov, China Gov u otras nubes soberanas)

Preparación del entorno

Paso 1: Configuración del repositorio de GitHub y ejecución del flujo de trabajo

Para probar la integración, use sus propios repositorios o un repositorio de GitHub de ejemplo que ya tenga todo el contenido para compilar una imagen de contenedor vulnerable.

Nota:

Asegúrese de que el repositorio que usa para la integración es privado.

Si desea usar un repositorio de ejemplo, clone el siguiente repositorio en su organización de GitHub. Este repositorio tiene GHAS habilitado y se incorpora a un inquilino de Azure con DCSPM habilitado:build25-woodgrove/mdc-customer-playbook. Este repositorio es para que los clientes prueben la integración de Microsoft Defender for Cloud y GHAS.

En el repositorio, siga estos pasos:

  1. Vaya a Configuración.
  2. En el panel izquierdo, seleccione Secretos y Variables>Acciones.
  3. Agregue los siguientes secretos en el nivel de repositorio o organización:
Variable Description
ACR_ENDPOINT Servidor de inicio de sesión de Azure Container Registry
ACR_PASSWORD Contraseña de Azure Container Registry
ACR_USERNAME Nombre de usuario de Azure Container Registry

Captura de pantalla de la interfaz de GitHub con el menú

Nota:

Los nombres se pueden elegir libremente y no es necesario seguir un patrón específico.

Puede encontrar esta información en Azure Portal siguiendo estos pasos:

  1. Seleccione el ACR en el que desea realizar la implementación.

  2. Seleccione Claves de acceso en Configuración.

    Captura de pantalla del portal de Azure en la que se muestra la página Claves de acceso de un registro de contenedores con los campos de servidor de inicio de sesión, nombre de usuario y contraseña visibles.

  3. En el repositorio, seleccione Acciones.

  4. Seleccione el flujo de trabajo Build and Push to ACR (Compilar y subir a ACR) y ejecute el flujo de trabajo.

    Captura de pantalla de la sección Acciones del repositorio de GitHub que muestra el historial de flujos de trabajo y las opciones para desencadenar manualmente el flujo de trabajo.

  5. Compruebe que la imagen se implementó en Azure Container Registry.

  6. Para el repositorio de ejemplo proporcionado: la imagen debe estar en un registro denominado mdc-mock-0001 con la etiqueta mdc-ghas-integration.

  7. Despliegue la misma imagen como un contenedor en funcionamiento en su clúster. Una manera de completar este paso es conectarse al clúster y usar el kubectl run comando . Este es un ejemplo de AKS:

    1. Establezca la suscripción del clúster:

      az account set --subscription $subscriptionID

    2. Establezca las credenciales del clúster:

      az aks get-credentials --resource-group $resourceGroupName --name $kubernetesClusterName --overwrite-existing

    3. Implemente la imagen:

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

Paso 2: Creación del primer factor de riesgo: regla crítica para la empresa

Uno de los factores de riesgo que Defender for Cloud detecta para esta integración es la importancia empresarial. Las organizaciones pueden crear reglas para etiquetar distintos recursos como críticos para la empresa.

  1. En El portal de Microsoft Defender for Cloud (Azure Portal), vaya a Configuración del entorno y elija Importancia del recurso.

  2. En el panel derecho, seleccione el vínculo para abrir Microsoft Defender.

    Captura de pantalla de la interfaz de Microsoft Defender for Cloud en la que se muestra el mosaico de Importancia crítica de los recursos y el enlace para abrir el portal de Microsoft Defender en el panel derecho.

  3. Seleccione Crear una nueva clasificación.

    Captura de pantalla de la página de configuración de XDR de Microsoft Defender con el vínculo

  4. Escriba un nombre y una descripción.

  5. Elija Recurso en la nube en el generador de consultas.

  6. Escriba una consulta para establecer Nombre de recurso igual al nombre del contenedor que implementó en el clúster para su validación y seleccione Siguiente.

    Captura de pantalla del generador de consultas de Microsoft Defender con el nombre de recurso igual al filtro

  7. En la página Recursos de vista previa , si Microsoft Defender ya detectó el recurso, el nombre del contenedor se muestra con el tipo de recurso que es K8s-container o K8s-pod. Incluso si aún no está visible en la página de recursos de vista previa, continúe con el paso siguiente. Microsoft Defender aplica la etiqueta de importancia crítica al contenedor una vez detectado. Este proceso puede tardar hasta 24 horas.

  8. Elija un nivel de importancia crítica y revise y envíe la regla de clasificación.

Paso 3: Validar que el entorno está listo

Nota:

Después de aplicar los pasos anteriores, pueden pasar hasta 24 horas para ver los siguientes resultados.

  1. Pruebe que el examen sin agente de GitHub recoge el repositorio.

  2. Vaya a Cloud Security Explorer y realice la consulta. Captura de pantalla del generador de consultas en Cloud Security Explorer con filtros establecidos en repositorios de GitHub e imágenes de contenedor, en la que se muestran los resultados de la búsqueda.

  3. Compruebe que el MDC (en ACR) ha examinado la imagen de contenedor y la ha usado para crear un contenedor. En tu consulta, añade las condiciones para tu implementación específica. Captura de pantalla de Cloud Security Explorer que muestra una consulta con filtros para repositorios de GitHub e imágenes de contenedor, donde se indican los resultados del escaneo.

  4. Verifique que el contenedor se está ejecutando y que MDC examinó el clúster de AKS. Captura de pantalla del generador de consultas de Cloud Security Explorer con filtros para repositorios y imágenes de contenedor de GitHub, en la que se muestran los resultados con vulnerabilidades y uso de contenedores.

  5. Compruebe que los factores de riesgo están configurados correctamente en MDC. Busque el nombre del contenedor en la página de inventario de MDC y debería verlo marcado como crítico.

Paso 4: Crear una campaña de GitHub

Dado que el flujo de trabajo implementa una imagen que crea un contenedor en ejecución con uno de los factores de riesgo (crítico para la empresa), los desarrolladores pueden ver factores de riesgo en GitHub.

Nota:

Después de clasificar el recurso como crítico, el MDC puede tardar hasta 12 horas en enviar los datos a GitHub. Obtenga más información aquí.

  1. En GitHub, vaya a la organización de GitHub que usó para las pruebas de configuración.

  2. SeleccioneSeguridad>Campañas>Crear una campaña a partir de filtros de análisis de código.

    Captura de pantalla de la interfaz de GitHub que muestra la pestaña Campañas de seguridad > con opciones para crear una campaña a partir de filtros de análisis de código o secretos.

  3. Cree la siguiente campaña. Esta campaña muestra alertas abiertas con gravedad media en la que la imagen implementada desde el repositorio está vinculada a un recurso crítico. El repositorio de pruebas debería ser detectado con esta campaña.

    Captura de pantalla de la interfaz campañas de GitHub en la que se muestran filtros para alertas abiertas, gravedad establecida en crítico y medio y riesgo en tiempo de ejecución como recurso crítico.

  4. Seleccione Guardar y, a continuación, Publicar como campaña.

  5. Escriba la información necesaria y, a continuación, publique la campaña.

Paso 5: Evaluar las recomendaciones de código a la nube

Use la experiencia de SDLC de recomendación de C2C y el enriquecimiento de alertas de seguridad para comprender el estado de los problemas de seguridad y asignar la recomendación para la resolución al equipo de ingeniería pertinente con la ayuda de la conexión entre las alertas de seguridad de Dependabot y las CVE coincidentes en la pestaña CVE asociado de la recomendación de tiempo de ejecución.

Ver las recomendaciones de C2C

  1. En el portal de MDC, vaya a la pestaña Recomendaciones .
  2. Busque el nombre del contenedor que creó y abra una de las recomendaciones que dice **Actualizar ***.
  3. Si usó el repositorio de ejemplo, busque: Actualización de la recomendación sobre expansión de llaves.
  4. Vaya a la pestaña Información de corrección y vea el código en el diagrama de nube.
  5. El diagrama mapea el contenedor en ejecución actualmente, la imagen del contenedor en el repositorio de código, y el repositorio de código de origen en GitHub.

Captura de pantalla de la pestaña Información de corrección que muestra un diagrama de fases de desarrollo con fases de código, compilación, envío y tiempo de ejecución vinculados por líneas discontinuas.

Enriquecimiento bidireccional

  1. Seleccione la pestaña CVEs asociados . Observe que algunos CVE tienen un vínculo en la columna Alertas de GitHub relacionadas.

    Captura de pantalla de la pestaña CVEs asociados que muestra CVE-2025-5889 con la puntuación 3.1 de CVSS, corrección de la versión 2.0.2 y un vínculo Ver en GitHub en Alertas de GitHub relacionadas.

  2. Seleccione el vínculo Ver en GitHub para abrir la alerta de seguridad de GHAS correspondiente.

Movilización de ingeniería

Para cerrar el bucle entre los equipos de seguridad e ingeniería, puede crear un problema de GitHub para una aplicación en contenedor que priorice para el equipo de ingeniería los problemas de seguridad en los que deben centrarse. Esta priorización puede incluir el paso de los resultados que GHAS no ha recogido, pero que MDC detectó para los CVE que no forman parte de las dependencias directas (por ejemplo, vulnerabilidades en la imagen base, sistema operativo o software de terceros como NGINX).

El problema de GitHub se genera automáticamente con todos los CVE encontrados en el ámbito de la recomendación, incluyendo aquellos con y sin alertas de Dependabot, coincidiendo con otros contextos de tiempo de ejecución en el repositorio de origen.

Captura de pantalla de la lista de problemas de GitHub en la que se muestran tres entradas, como

Al asignar el problema, el estado del problema se actualiza en el portal de MDC.

Captura de pantalla de una incidencia de GitHub titulada

Correcciones agentivas

En el lado de GitHub, si tiene una licencia de GitHub Copilot, puede resolver el problema con la ayuda del Agente de codificación de GitHub:

  1. Asigne el agente de codificación de GitHub al problema.
  2. Revise la corrección generada.
  3. Si parece razonable, aplique la corrección.
  4. Observe la actualización del estado del problema en MDC en Cerrado.

Contenido relacionado

  • Last updated on