Blog Azure Cloud

Priorización de alertas de seguridad con contexto de ejecución usando Dynatrace

Priorización de alertas de seguridad con Dynatrace en entornos Kubernetes

Introducción

GitHub ha anunciado la disponibilidad general de una integración que permite usar contexto de ejecución de Dynatrace para priorizar alertas de GitHub Advanced Security. El objetivo es ayudar a los equipos a distinguir qué vulnerabilidades afectan a artefactos realmente desplegados y cuáles presentan señales de mayor riesgo en un entorno Kubernetes.

Este enfoque no sustituye al análisis de seguridad tradicional, pero añade una capa práctica de priorización: no todas las alertas tienen el mismo impacto operativo si una vulnerabilidad está presente en código no desplegado, en una imagen activa, en un servicio expuesto a Internet o en un componente que accede a datos sensibles.

Qué aporta el contexto de ejecución

En muchos programas de seguridad de aplicaciones, el volumen de alertas puede ser elevado. GitHub Advanced Security ya permite detectar problemas mediante capacidades como code scanning y Dependabot alerts. La integración con Dynatrace añade información procedente del entorno de ejecución para ayudar a responder preguntas como:

  • ¿La alerta afecta a un artefacto desplegado?
  • ¿La imagen de contenedor está vinculada con un repositorio concreto?
  • ¿El componente se ejecuta en un entorno Kubernetes?
  • ¿Existen señales de riesgo en runtime, como exposición pública a Internet?
  • ¿El artefacto tiene acceso a activos de datos sensibles?

Según el anuncio oficial de GitHub, al conectar Dynatrace con GitHub se muestra contexto de despliegue para imágenes de contenedor que Dynatrace puede mapear a repositorios, junto con señales de riesgo en tiempo de ejecución.

Alertas compatibles

La integración permite usar la visibilidad de despliegue y las señales de riesgo de runtime para filtrar y priorizar:

  • alertas de code scanning;
  • alertas de Dependabot;
  • alertas incluidas en security campaigns.

Esto resulta especialmente útil cuando el equipo necesita reducir una lista amplia de hallazgos a un conjunto más accionable, priorizando aquello que afecta a artefactos desplegados y que además presenta condiciones de riesgo relevantes en producción o entornos equivalentes.

Filtros de priorización

GitHub indica que el contexto puede utilizarse directamente en las páginas de alertas y en campañas de seguridad. Un ejemplo de filtro es:

has:deployment AND runtime-risk:internet-exposed

Este filtro permite centrarse en vulnerabilidades que afectan a artefactos desplegados y que, además, están asociados a exposición pública a Internet.

Las señales de riesgo mencionadas oficialmente son:

  • runtime-risk:internet-exposed: exposición a Internet pública.
  • runtime-risk:sensitive-data: acceso a activos de datos sensibles.

En la práctica, estos filtros ayudan a diferenciar entre una vulnerabilidad crítica desde el punto de vista del CVSS o del paquete afectado y una vulnerabilidad crítica para el negocio por estar presente en un componente desplegado y expuesto.

Ejemplo de uso

Imaginemos un equipo que recibe varias alertas de Dependabot para una dependencia vulnerable presente en distintos repositorios. Sin contexto adicional, todas las alertas pueden parecer igual de urgentes.

Con contexto de ejecución de Dynatrace en GitHub Advanced Security, el equipo puede priorizar primero las alertas que cumplan condiciones como:

  • el artefacto afectado está desplegado;
  • la imagen de contenedor se ha asociado correctamente con el repositorio;
  • el servicio tiene exposición pública a Internet;
  • el componente accede a datos sensibles.

Así, la remediación puede enfocarse inicialmente en los casos con mayor exposición real, sin dejar de planificar la corrección del resto de vulnerabilidades.

Relevancia para entornos Kubernetes y AKS

El anuncio se centra en entornos Kubernetes. Por tanto, para organizaciones que ejecutan cargas de trabajo en Kubernetes —incluido Azure Kubernetes Service cuando aplique— este tipo de integración puede ayudar a conectar tres planos que a menudo se gestionan por separado:

  1. Código y dependencias, donde se detectan vulnerabilidades mediante GitHub Advanced Security.
  2. Artefactos desplegados, especialmente imágenes de contenedor.
  3. Contexto de ejecución, observado por Dynatrace en el entorno Kubernetes.

La utilidad principal no está en “descubrir” una vulnerabilidad nueva, sino en aportar contexto para decidir qué debe corregirse antes.

Consideraciones importantes

Antes de adoptar este enfoque conviene tener en cuenta varios puntos:

  • La integración está anunciada como disponible de forma general para clientes de GitHub Enterprise Cloud.
  • Requiere conectar Dynatrace con GitHub Advanced Security.
  • La calidad de la priorización depende de que Dynatrace pueda mapear correctamente imágenes de contenedor con repositorios.
  • Las señales de runtime deben interpretarse como ayuda para priorizar, no como sustituto de una política completa de gestión de vulnerabilidades.
  • Una alerta sin exposición pública no debe ignorarse automáticamente: puede seguir siendo relevante por movimiento lateral, cambios futuros de despliegue o exposición indirecta.

Buenas prácticas de adopción

Para sacar partido al contexto de ejecución sin convertirlo en una fuente adicional de ruido, es recomendable:

  • Definir criterios claros de priorización: por ejemplo, tratar primero alertas con has:deployment y runtime-risk:internet-exposed.
  • Revisar periódicamente que el mapeo entre imágenes, repositorios y despliegues sea correcto.
  • Usar campañas de seguridad para agrupar remediaciones de alto impacto.
  • Mantener trazabilidad entre alerta, repositorio, imagen afectada y entorno desplegado.
  • Evitar que la priorización contextual se convierta en una excusa para acumular deuda de seguridad en vulnerabilidades no desplegadas.

Conclusión

La integración entre Dynatrace y GitHub Advanced Security introduce una mejora relevante en la gestión de alertas: permite priorizar no solo por severidad estática, sino también por presencia en artefactos desplegados y señales de riesgo en tiempo de ejecución.

Para equipos que trabajan con Kubernetes, este contexto puede ayudar a enfocar la remediación en los componentes que realmente están activos y presentan mayor exposición. El valor está en reducir el tiempo entre detección y decisión, manteniendo una visión más cercana al riesgo operativo real.

Fuente