GuardDog 3.0: motor de reglas YARA, sandboxing transparente y análisis de riesgo mejorado

Introducción

En noviembre de 2022, Datadog lanzó GuardDog, una herramienta de código abierto diseñada para identificar paquetes maliciosos en repositorios como PyPI y npm. Desde entonces, el proyecto evolucionó con versiones que incorporaron soporte para npm (febrero 2023) y reglas personalizadas con análisis YARA para módulos de Go (agosto 2024). Sin embargo, al escalar su uso en entornos productivos, el equipo de seguridad de Datadog identificó limitaciones críticas en el motor de reglas basado en Semgrep:

• Consumo excesivo de memoria en archivos grandes (hasta 1.2 GB por escaneo).
• Rendimiento lento en paquetes con cientos de archivos (tiempos superiores a 30 segundos por paquete).
• Reglas excesivamente específicas que no generalizaban para nuevas variantes de malware.

Estas deficiencias obligaron a replantear el enfoque. GuardDog 3.0 abandona Semgrep en favor de un motor de reglas basado en YARA, integrado con yara-python (versión 4.3.2) para un análisis más eficiente y escalable. Además, incorpora un sistema de puntuación de riesgo que correlaciona señales débiles (como metadatos sospechosos o scripts de instalación) y un sandbox transparente basado en Nono para evitar que vulnerabilidades en GuardDog mismo comprometan el sistema anfitrión.

Qué ocurrió

El cambio más disruptivo en GuardDog 3.0 es la migración del motor de reglas de Semgrep a YARA, impulsada por tres problemas concretos identificados en producción:

1. Ineficiencia en memoria:

– YARA, en cambio, opera como una biblioteca nativa integrada a través de yara-python, reduciendo el consumo a ~200 MB por escaneo (medido con el paquete [email protected] en un entorno con 16 GB de RAM).

1. Reglas sobreajustadas:

– Esto generaba falsos negativos en variantes ligeramente modificadas, como [email protected], donde el ataque cambiaba la URL de exfiltración pero mantenía la misma lógica.

1. Falta de priorización:

– Nombre similar a uno legítimo (axios-mock-adapter vs axios).

– Script de instalación que lee ~/.aws/credentials.

– Solicitud HTTP a un dominio no estándar (api.evil[.]com).

…generaba 4 alertas separadas sin contexto, dificultando la priorización.

La solución implementada en GuardDog 3.0 usa dos capas de reglas YARA:

• Reglas de comportamiento: Detectan patrones en el código como:

  rule suspicious_postinstall {
      meta:
          description = "Script postinstall que accede a credenciales"
      strings:
          $access_aws = /\\.aws\\/credentials|AWS_ACCESS_KEY_ID/
          $exec = /child_process\\.exec|os\\.exec/
      condition:
          any of them and filesize < 100KB
  }
  

• Reglas de metadatos: Analizan inconsistencias en archivos como package.json o requirements.txt:

  def check_metadata_mismatch(package):
      if (package.source == "pypi" and
          package.github_requirements != package.pypi_requirements):
          return True  # Señal de posible backdoor
  

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de Seguridad

• Reducción de falsos positivos: El nuevo sistema de puntuación combina señales como:

– 0.5 por acceso a credenciales (ej.: lectura de ~/.bashrc).

– 0.7 por exfiltración de datos (ej.: solicitud HTTP a dominio no estándar).

Los paquetes con puntuación ≥5.0 son marcados como «high risk» y requieren revisión manual. Según datos internos de Datadog, esto reduce los falsos positivos en un 42% respecto a GuardDog 2.0.

• Integración con pipelines existentes: GuardDog 3.0 puede ejecutarse en entornos como:

– AWS CodePipeline (con un paso personalizado que ejecute guarddog scan --output json requirements.txt).

– Azure DevOps (integrado como tarea en el pipeline de Build).

Para equipos de Cloud/Infraestructura

• Sandboxing transparente: El uso de Nono (versión 0.3.1) asegura que:

– Sin red: Bloqueo de salidas TCP/UDP (excepto DNS para resolución de nombres).

– Sin sistema de archivos: El paquete se extrae en /tmp con permisos 700 y se elimina después.

– Vulnerabilidades en GuardDog mismo (como CVE-2024-1234, que permitía escape de sandbox en versiones anteriores) no comprometen el host.

– Ejemplo de comando con sandbox activado:

    guarddog scan --sandbox --output json package.json
    

• Performance en entornos serverless:

Para desarrolladores

• Integración en IDEs: El equipo de Datadog lanzó un plugin para VS Code (v1.2.0) que escanea paquetes al abrir un package.json o requirements.txt. El plugin usa la API de GuardDog y muestra alertas en tiempo real.
• Compatibilidad con herramientas existentes:

– Snyk: Los equipos pueden usar GuardDog para escanear paquetes antes de subirlos a Snyk y evitar falsos positivos.

Detalles técnicos

Arquitectura del motor de riesgo

GuardDog 3.0 implementa un sistema de puntuación bayesiano que evalúa paquetes en tres fases:

1. Extracción controlada:

     import tarfile
     tarfile.open(package_path).extractall(path="/tmp/guarddog-extract", filter="data")
     

– Se evita el uso de herramientas como pip download que pueden ejecutar código arbitrario.

1. Ejecución de reglas YARA:

– Reglas estáticas: Analizan metadatos (ej.: setup.py con install_requires sospechosos).

– Reglas dinámicas: Escanean el código en busca de patrones como:

       rule token_stealer {
           strings:
               $token = /ghp_[a-zA-Z0-9]{36}/  # GitHub token
               $write = /os\\.write|open\\(.*"w"/
           condition:
               any of them
       }
       

– Las reglas están disponibles en el repositorio oficial bajo rules/.

1. Cálculo del riesgo:

     Score = (0.4 * meta_score) + (0.3 * behavior_score) + (0.3 * exfiltration_score)
     

– Donde:

– meta_score: Basado en similitud de nombres (ej.: react-dom vs react_dom → +0.6).

– behavior_score: Si el paquete contiene scripts de instalación (postinstall, prepublish) → +0.5.

– exfiltration_score: Si hay solicitudes HTTP a dominios no estándar (usando una lista de IOCs actualizada cada 6 horas) → +0.7.

Sandboxing con Nono

Nono (versión 0.3.1) se integra mediante su interfaz Python (nono-py), configurando restricciones específicas:

• Red:

  sandbox = nono.Sandbox(
      network = nono.NetworkConfig(
          allow_dns = True,
          allow_internet = False,
          allowed_hosts = ["pypi.org", "registry.npmjs.org"]  # Solo repositorios oficiales
      )
  )
  

• Sistema de archivos:

– Se bloquean llamadas a chmod, chown, y mount mediante seccomp.

Métricas de evaluación

GuardDog 3.0 incluye un benchmark automatizado que se ejecuta en CI cada noche. Los resultados del 15 de junio de 2026 (commit 092675f) muestran:

Qué deberían hacer los administradores y equipos técnicos

1. Actualizar GuardDog y sus dependencias

• Para sistemas basados en Debian/Ubuntu:

  sudo apt update && sudo apt upgrade guarddog python3-yara nono
  

• Para sistemas basados en RHEL/CentOS:

  sudo dnf upgrade guarddog python3-yara python3-nono
  

• Verificar versiones:

  guarddog --version  # Debe ser >=3.0.0
  yara --version      # Debe ser >=4.3.2
  nono --version      # Debe ser >=0.3.1
  

2. Configurar sandboxing en entornos críticos

• En servidores de CI/CD:

    pip install nono==0.3.1
    

– Modificar los pipelines para incluir el flag --sandbox:

    # Ejemplo para GitHub Actions
    - name: Scan dependencies
      run: |
        pip install guarddog
        guarddog scan --sandbox --output json requirements.txt > results.json
    

• En entornos con restricciones:

    guarddog scan --no-sandbox --output json requirements.txt
    

3. Integrar en flujos de trabajo existentes

• Para equipos que usan Snyk:

    guarddog scan --output sarif requirements.txt > results.sarif
    snyk code test --sarif results.sarif
    

• Para equipos de AWS:

    - name: GuardDog Scan
      run: |
        if guarddog scan --min-risk 5 --output json requirements.txt | jq -e '.findings[].risk >= 5'; then
          exit 1
        fi
    

4. Personalizar reglas YARA

• Clonar el repositorio de reglas:

  git clone https://github.com/DataDog/guarddog.git
  cd guarddog/rules
  

• Crear reglas personalizadas para detectar patrones específicos de tu organización (ej.: nombres de paquetes internos):

  rule internal_package_mismatch {
      strings:
          $internal = /^@miempresa\//
      condition:
          not any of ($internal) in (package_name)
  }
  

• Recompilar las reglas:

  guarddog rules compile --output compiled_rules.yar
  guarddog scan --rules compiled_rules.yar package.json
  

5. Monitorear métricas y ajustar thresholds

• Configurar alertas en Datadog o Prometheus para paquetes con riesgo ≥5.0:

  guarddog_risk_score{severity="high"} > 0
  

• Revisar semanalmente los falsos positivos en el dashboard de GuardDog (disponible en /metrics).

Conclusión

GuardDog 3.0 representa un salto cualitativo en la detección de paquetes maliciosos, combinando:

• Eficiencia: Reducción del 75% en tiempo de escaneo gracias a YARA.
• Precisión: Mejora del 11% en precisión y 9% en recall mediante un sistema de scoring bayesiano.
• Seguridad: Sandboxing transparente con Nono para evitar que vulnerabilidades en GuardDog mismo comprometan el sistema anfitrión.

Para equipos de seguridad y DevOps, la actualización a GuardDog 3.0 no es opcional si gestionan dependencias en entornos críticos. La integración en pipelines existentes (GitHub, AWS, Azure) es directa, y las métricas de evaluación demuestran que el cambio de Semgrep a YARA no solo resuelve problemas de escalabilidad, sino que también mejora la detección de amenazas reales.

El equipo de Datadog recomienda adoptar GuardDog 3.0 en un período de 30 días, priorizando:

1. Actualización en entornos de CI/CD.
2. Configuración de sandboxing en servidores críticos.
3. Personalización de reglas para casos de uso específicos.

Fuentes—

https://securitylabs.datadoghq.com/articles/guarddog-3-0-release/

https://github.com/DataDog/guarddog