Para: cualquiera que gestione sus propios sitios o servicios y quiera recibir información sobre vulnerabilidades sin tener a una persona vigilando los canales. Este artículo trata sobre qué recoger, con qué compararlo y cuánto confiar en la IA.
Qué pasó: una persona se enteró primero, tres veces seguidas
En una semana, en los sitios que gestiona el operador de este sitio, ocurrieron tres cosas. En todos los casos, el operador se enteró primero a través de redes sociales o correo electrónico, y la vigilancia automatizada no había informado de nada en ese momento.
Caso 1
Una vulnerabilidad de PHP. El operador se enteró primero. La vigilancia automatizada no la había marcado.Caso 2
Código malicioso insertado en un paquete de Python. El operador se enteró primero. La vigilancia automatizada no lo había marcado.Caso 3
Un problema en una imagen base de contenedor. El operador se enteró primero. La vigilancia automatizada no lo había marcado.
La primera sospecha fue "no hay suficientes fuentes". No hubo una única causa: las fuentes oficiales pueden ir por detrás de lo que está en tendencia (más abajo), y además no había suficiente material para decidir que un elemento concierne a nuestra configuración. Palabras como "PHP" o "Python" aparecen en el texto de las noticias, pero eso es distinto de los nombres de los paquetes que realmente se ejecutan.
La vigilancia reconstruida
1. Recoger
Avisos oficiales / avisos de GitHub / listas de paquetes maliciosos / KEV / noticias / redes sociales
↓
Lista A: palabras de tecnología que usamos
Red amplia
Lista B: nombres reales de los componentes
Generada a partir de lockfiles y paquetes del sistema operativo
↓
2. Las reglas detectan coincidencias (funcionan sin IA)
↓
3. Un modelo de IA económico hace la clasificación inicial
Puede elevar la urgencia. No puede reducirla.
- Qué recoge: avisos oficiales, avisos de GitHub, listas de paquetes maliciosos, KEV de CISA, noticias y redes sociales.
- Dos listas para comparar: palabras de tecnología para una red amplia, y nombres reales de componentes para coincidencias de alta confianza. La lista de componentes se genera a partir de los lockfiles de cada repositorio más los paquetes del sistema operativo.
- Escaneo de la imagen completa: revisa toda la imagen, incluida la imagen base, no solo las dependencias de la aplicación.
- Retraso de los entornos de ejecución: mide cuánto se quedan atrás entornos como Node, PHP y la base de datos respecto a sus últimas versiones.
- Primera pasada con IA: un modelo de IA económico hace la primera valoración de "¿nos afecta?". La IA solo puede elevar la urgencia.
Lo que mostraron las mediciones, incluido lo que fue contrario a lo esperado
Primera suposición: las fuentes oficiales bastan
Asumimos que vigilar los avisos oficiales y KEV detectaría lo importante. En la práctica, un tema puede volverse tendencia antes de que se publique el aviso. Las fuentes oficiales por sí solas pierden esa carrera.
Tras medir: añadir las redes sociales como punto de entrada
Añadir redes sociales permitió que la vigilancia detectara cosas antes que solo con fuentes oficiales. Pero el contenido de redes sociales no se trata como un hecho hasta que una fuente oficial lo confirme. Amplio en la entrada, cauteloso en la decisión.
- Comprobación de fallos: unas 100 vulnerabilidades críticas recogidas en 10 días por una vigilancia separada (diseñada para encontrar candidatos a artículos) se cruzaron con esta vigilancia. Fallos entre las que afectaron a los sitios del operador: 0.
- Cuota de IA agotada: la cuota mensual se agotó y la clasificación con IA se detuvo unos 6 días. La coincidencia por reglas que no usa IA siguió funcionando todo el tiempo. El diseño establece de antemano una fecha de fin de la pausa, y la parte de IA se reanuda automáticamente desde esa fecha.
- Un hueco en un servidor nuevo: los paquetes del sistema operativo de un servidor recién añadido no estaban en la lista de componentes. La regeneración mensual de la lista lo detectó. Una lista es fiable solo si se regenera con regularidad, no si se construye una única vez.
Cómo construir esto en su propio entorno
Genere la lista de componentes (SBOM) de forma mecánica
Créela a partir de los lockfiles de cada repositorio y de los paquetes del sistema operativo de sus servidores y contenedores. CISA describe un SBOM como un inventario anidado, una lista de los ingredientes que componen los componentes de software. Generadores de SBOM como Syft, de código abierto, leen los paquetes del sistema operativo y las dependencias de los principales lenguajes desde imágenes de contenedor y sistemas de archivos, y pueden generar salida en CycloneDX o SPDX.
Compare la lista con vulnerabilidades conocidas
Para la comparación de dependencias, el osv-scanner de código abierto lee lockfiles y contenedores. La configuración y la integración en CI se explican en osv-scanner: configuración y uso.
Priorice con KEV y EPSS
Cuando hay muchos hallazgos no puede corregirlos todos con la misma urgencia. Empiece por lo que está confirmado como explotado (KEV) y por lo que tiene una alta probabilidad prevista de explotación (EPSS). Cómo combinarlos se explica en CVSS, EPSS y KEV: cómo usarlos juntos.
Si usa IA, úsela solo para elevar
Aunque la IA diga "no afectado", no elimine un elemento que una regla haya recogido. La IA puede decir erróneamente "no relacionado", y el coste de un fallo es mayor que el coste de una falsa alarma.
Decida qué ocurre cuando la IA no está disponible
Las cuotas se agotan, los servicios fallan y los proveedores dejan de funcionar. Decida antes de operar que las reglas sin IA por sí solas siguen enviando un conjunto mínimo de notificaciones, y establezca una fecha de reanudación para que la parte de IA vuelva automáticamente.
Regenere la lista con regularidad
Los huecos aparecen cuando se añade un servidor o repositorio y la lista no se actualiza. Reconstruya la lista al menos una vez al mes y compruebe que lo que añadió está incluido.
No trate las redes sociales como un hecho hasta que una fuente oficial lo confirme
Las redes sociales son rápidas, pero mezclan errores y especulaciones que el proveedor no ha confirmado. Úselas como punto de entrada, pero base su respuesta en fuentes primarias verificables, como el aviso del proveedor o KEV.
Visión de este sitio: red amplia con palabras de tecnología, reducida con nombres de componentes
Según la experiencia del operador, pasar a coincidir con los nombres reales de los componentes redujo tanto los falsos positivos como los fallos. Pero si la lista de componentes está desactualizada, lleva directamente a fallos. Se necesitan ambas cosas: una red amplia y una lista precisa para acotarla. Este artículo describe la vigilancia creada para los sitios que gestiona el operador.
Fuentes (primarias y oficiales)
- CISA — Known Exploited Vulnerabilities Catalog (vulnerabilidades confirmadas como explotadas)
- CISA — Software Bill of Materials (SBOM) (definición de SBOM)
- FIRST — EPSS (probabilidad prevista de explotación)
- OpenSSF — malicious-packages (repositorio de informes de paquetes maliciosos en formato OSV)
- Anchore — Syft (genera SBOM a partir de imágenes de contenedor y sistemas de archivos; salida en CycloneDX y SPDX; paquetes del sistema operativo y principales lenguajes)
Lecturas recomendadas
- Herramienta: osv-scanner: configuración y uso
- Prioridad: CVSS, EPSS y KEV: cómo usarlos juntos
- Ejemplo: Versión de seguridad crítica de PHP
- Relacionado: Defensa frente a ataques a la cadena de suministro de npm