Threat intel para ingenieros: comprueba tu stack, ignora el resto

23.09.20264 min de lecturaEquipo Atalaia

A los equipos de ingeniería les dicen que "consuman threat intelligence". En la práctica eso significa un feed de avisos, entradas de blogs de proveedores e informes de actores, casi todo sin relación con el software que ejecutan. El resultado es fatiga de alertas o un feed que nadie lee.

Nuestra postura es simple. Para un equipo de ingeniería, la threat intelligence es útil cuando responde rápido a una pregunta: ¿esto está en nuestro stack y es alcanzable? Todo lo que no ayude a responderla puede esperar o sobrar.

Qué significa el threat intel para los ingenieros

A un SOC o a un equipo de inteligencia dedicado le importan los actores, las campañas y los indicadores. Ese trabajo es valioso, pero no es lo que un equipo de producto necesita para empezar su mañana. Los ingenieros necesitan saber cuándo una dependencia, una imagen base, una herramienta de build o una integración SaaS que usan tiene un problema conocido, y si deben dejar lo que están haciendo.

Eso convierte la threat intel de un ejercicio de lectura en una consulta. El aviso dice "paquete X, versiones anteriores a Y". La pregunta de ingeniería es "¿dónde tenemos X por debajo de Y?". Si responderla lleva un día preguntando por el chat, la información llega demasiado tarde para servir.

Convierte la respuesta en una consulta

La forma de hacer rápida esa consulta es tener una lista de materiales de software (SBOM) actualizada de cada servicio e imagen, guardada donde puedas buscar. Genérala en CI con Syft en cada build:

# In CI, after building the image
syft registry.example.test/payments-api:1.42.0 \
  -o cyclonedx-json=sbom/payments-api.cdx.json

Cuando llega un advisory, puedes comprobar un SBOM en segundos:

# Which version of a named package is in this service?
jq -r '.components[] | select(.name == "xz" or .name == "liblzma")
  | [.name, .version] | @tsv' sbom/payments-api.cdx.json

# Scan an SBOM against current vulnerability data with Grype
grype sbom:sbom/payments-api.cdx.json --only-fixed

Y en todo el parque:

# Every service that ships a given package, with versions
for f in sbom/*.cdx.json; do
  jq -r --arg svc "$(basename "$f" .cdx.json)" \
    '.components[] | select(.name == "lodash")
     | [$svc, .version] | @tsv' "$f"
done | sort -u

Combina el SBOM con datos de deploy, qué versión de cada servicio corre en cada entorno, y podrás decir no solo «lo tenemos» sino «lo tenemos en producción en estos tres servicios».

Qué atender

Cuando puedes responder rápido a la consulta, el filtro para actuar es corto:

• Explotadas en el mundo real, y presentes en tus SBOM. Los catálogos públicos de vulnerabilidades explotadas son una buena señal principal. Una coincidencia aquí es trabajo para hoy.
• Cualquier cosa que toque tu tooling de build y release. Las CI actions comprometidas, los gusanos en registries de paquetes y las dependencias de build con backdoor afectan a toda la fábrica, no solo a un producto. El compromiso de tj-actions/changed-files (marzo de 2025) y el gusano Shai-Hulud de npm (septiembre de 2025) son ejemplos de esta clase.
• Accesible desde internet. Una librería vulnerable en un job batch interno es menos urgente que la misma librería detrás de una API pública. Usa tu conocimiento de la arquitectura para priorizar.
• Tu proveedor de identidad y tus proveedores SaaS. Los incidentes en los servicios que guardan tus tokens o tu código fuente exigen respuesta aunque no haya ningún paquete implicado: rota credenciales, revisa los audit logs, busca accesos nuevos.

Qué ignorar

Esta es la parte que a la gente le resulta incómoda, pero decir que no es lo que mantiene útil el feed.

• Perfiles de actores y nombres de campañas. Lectura interesante, pocas veces accionable para un equipo de producto. Déjalos para quien se encargue de la detección.
• Informes genéricos de tendencias. "Los ataques a la nube aumentan" no cambia lo que haces esta semana.
• Avisos de software que no usas. Si la consulta al SBOM no devuelve nada, has terminado. Anota que lo has comprobado y sigue.
• Puntuaciones de severidad por sí solas. Una puntuación crítica en una ruta de código que nunca llamas tiene menos prioridad que una media en tu página de login.
• Listas de indicadores sin contexto. Las listas de IPs y hashes pertenecen a las herramientas de detección, no a un canal de ingeniería.

Qué haríamos

1. Genera un SBOM CycloneDX con Syft para cada imagen en CI, asociado al digest de la imagen.
2. Guarda los SBOM de forma centralizada y mantén un mapa de qué digest se ejecuta dónde.
3. Suscribe un canal a un pequeño conjunto de fuentes: la base de datos de avisos de tus ecosistemas de paquetes, un catálogo de vulnerabilidades explotadas conocidas y los avisos de seguridad de tu host de Git, tu CI y tu proveedor cloud.
4. Por cada aviso nuevo, ejecuta la consulta sobre el SBOM. Publica la respuesta, haya coincidencia o no, en el hilo en menos de una hora.
5. Escala solo las coincidencias que se explotan, son alcanzables o están en tus herramientas de build. Todo lo demás pasa a ser una actualización de dependencia normal.

Hecha así, la threat intel va menos de leer más y más de responder más rápido. El SBOM es la lista de piezas de la línea; mantenlo al día y la mayoría de los avisos se resuelven en una comprobación de dos minutos.

Dónde encaja en la línea

En la torre (en desarrollo):