Estabilidad en la vanguardia, backporting y riesgos ocultos
En el mundo moderno de DevSecOps, los CISO buscan constantemente señales entre el ruido y el resultado de los escáneres de seguridad suele ser significativo. Los análisis de seguridad que devuelven informes «cero CVE» a menudo pueden desbloquear actualizaciones para la producción; una sola señal de alerta puede impedir una liberación.
Esta visión dualista de la seguridad ha dado lugar a dos filosofías diametralmente opuestas. Por un lado, tenemos el enfoque de soporte a largo plazo (LTS): mantener versiones probadas y respaldar correcciones de seguridad específicas. Por otro lado, adoptamos el método de impulsar lo último: mantener la posición de liderazgo de CVE migrando continuamente a la última versión.
En este artículo, compararé los pros y los contras del enfoque «impulsar lo último» con el «enfoque LTS» y argumentaré que, si bien «avanzar» hace felices a sus escáneres, puede hacer que su infraestructura sea más vulnerable.
El caso del backporting: la estabilidad como pilar de la seguridad
El modelo LTS se basa en el principio de cambio mínimo. Por ejemplo, cuando se descubre una vulnerabilidad, los ingenieros de seguridad de Canonical extraen el conjunto mínimo de cambios necesarios para solucionar el problema y lo aplican a la versión anterior.
El beneficio de este modelo es la estabilidad: no es necesario «pérdida de funciones» para obtener correcciones de seguridad. Sus API no cambian, sus perfiles no se rompen y el comportamiento de su aplicación sigue siendo predecible. La estabilidad no se trata sólo de las API. Se trata de consumo de recursos. Los backports LTS no duplicarán repentinamente el uso de memoria ni agregarán nueva telemetría en segundo plano; la versión «más reciente» puede hacer esto sin previo aviso.
Sin embargo, este enfoque puede plantear desafíos para la gestión de vulnerabilidades, ya que muchos escáneres de seguridad dependen principalmente de cadenas de versión. Dado que es posible que algunas de estas herramientas no siempre sepan de inmediato acerca de un parche quirúrgico específico que se actualizó a una versión anterior, pueden marcar un paquete como vulnerable basándose únicamente en el número de versión. Esto crea «ruido CVE» donde los equipos de seguridad tienen que pasar horas escribiendo excepciones e ignorando listas para demostrar que el informe del escáner no es la causa del problema.
Para cerrar esta brecha, Trabajamos con los principales socios de escáneres de seguridad Comparta datos profundos sobre vulnerabilidad. Al brindar esta visibilidad, garantizamos que sus herramientas puedan identificar con precisión las correcciones respaldadas, lo que reduce significativamente la carga manual de los equipos de seguridad para investigar y certificar estos informes.
Desventajas del método «empujar lo último»
Algunos proveedores resuelven el problema simplemente utilizando la última versión de todo. Siempre que utilice la última versión, el escáner no encontrará vulnerabilidades conocidas. Parece magia: se obtiene un informe limpio y el auditor está contento.
Sin embargo, el enfoque de «impulsar lo último» se basa en una suposición peligrosa: «lo más nuevo» siempre es «más seguro». Veamos algunas de las desventajas y riesgos de este enfoque.
1. Riesgos “desconocidos desconocidos”
CVE es conocido Vulnerabilidad. Cuando usa una versión de paquete más antigua y ampliamente implementada (como la versión en Ubuntu LTS), es probable que esté usando código que ha sido «maduro» debido a años de uso en producción global.
Por el contrario, cuando obtienes la última versión de un paquete que se lanzó hace 48 horas, estás en la primera línea de pruebas de vanguardia. Es posible que hayas negociado conocido Errores (pueden haber sido parcheados y respaldados) desconocido, Vulnerabilidades que aún no han sido descubiertas y no solucionadas en la última versión.
2. Una advertencia sobre XZ Utils
La puerta trasera XZ Utils (CVE-2024-3094) es la refutación definitiva de la filosofía de «siempre lo último». En este infame ejemplo, se inyectó código malicioso en la última versión «de vanguardia» de la herramienta. Cada nueva línea de código es una nueva vulnerabilidad potencial.
Los usuarios de distribuciones como Debian Stable o Ubuntu LTS están protegidos de forma predeterminada, no porque sean más inteligentes, sino porque su dependencia de código probado y examinado por la distribución es obligatoria. periodo de reflexiónd cadena de suministro global. Por el contrario, el modelo de ingesta rápida «empujar lo último» crea una autopista para que este tipo de ataques sofisticados lleguen a los entornos de producción.
3. Introducir cambios importantes sin darse cuenta
Si utiliza el modelo «push Latest», la estabilidad de su entorno también se verá afectada porque sus dependencias seguirán cambiando. Las actualizaciones de versiones menores pueden incluir «correcciones» que cambian la forma en que la biblioteca maneja la memoria o los tiempos de espera de la red.
Si sus imágenes se reconstruyen todas las mañanas con el paquete «más reciente», es posible que su aplicación falle en producción porque la regresión nunca se detectó en su proceso de CI/CD, simplemente porque los desarrolladores anteriores cambiaron los ajustes preestablecidos en los que confiaba. Además, si te pierdes aunque sea un ciclo de actualización, este frágil castillo de naipes se desmorona, dejándote preguntándote si tu entorno era realmente estable para empezar.
Seguridad y cumplimiento
Cuando se considera el debate entre el «enfoque LTS» y el «impulso del último enfoque», queda claro dónde reside la verdadera fuente de tensión: el equilibrio entre seguridad y protección. infantil cumplir.
Los proveedores que adoptan un modelo de «empujar lo último» no necesariamente resuelven el problema; simplemente transfieren el riesgo. Al crear un sistema operativo personalizado y de lanzamiento continuo que elimina la estabilidad histórica, prometen parches instantáneos. Esto se produce a expensas de la promesa de compatibilidad garantizada de LTS.
En el mundo de los contenedores, creen que los grandes cambios no importan porque los contenedores son efímeros. Sin embargo, si bien los contenedores pueden ser efímeros, los contratos de software no lo son. Su aplicación se basa en un comportamiento estable de API, ABI y biblioteca. Cuando apuntas ciegamente a lo último, estás cambiando constantemente la base de tu aplicación. No importa qué tan rápido se reinicie el contenedor si el nuevo paquete ascendente que acaba de extraer rompe fundamentalmente las dependencias de su aplicación. Una caída rápida sigue siendo una interrupción.
en conclusión
La elección depende de lo que usted valore más: un escáner silencioso o una noche de sueño tranquilo. Si bien la búsqueda de lanzamientos ascendentes puede proporcionar la gratificación instantánea de un panel ecológico, lo logra trasladando el proceso de revisión a producción.
La verdadera seguridad requiere el importante trabajo de backporting: corregir vulnerabilidades sin introducir volatilidad. En un mundo donde los ataques a la cadena de suministro son la nueva frontera, el código estable y probado es más que una conveniencia. Esta es su capa de defensa más crítica.
¿Estamos realmente más seguros o simplemente estamos cansados de mirar el punto rojo en el tablero? Al respaldar las correcciones de CVE, Ubuntu Pro reconoce que se necesita tiempo para confiar en el código. En un mundo donde los ataques a la cadena de suministro son la nueva frontera, el código estable y probado puede ser la característica más segura que tenga.
lectura adicional
