Los responsables de seguridad en bancos, aseguradoras y gestoras de activos han mantenido conversaciones recurrentes: el equipo de seguridad busca eliminar ciertas vulnerabilidades, mientras que ingeniería calcula el esfuerzo de actualizar la plataforma donde residen. Se cotiza el coste de las pruebas de regresión, se menciona el calendario de congelación de cambios y, finalmente, el hallazgo se aplaza con una excepción, un control compensatorio y una fecha en la hoja de ruta a 18 meses vista.
Nadie actúa de forma irracional. El sector financiero acumula más software heredado que casi cualquier otra industria debido a décadas de infraestructura acumulada, obligaciones regulatorias que priorizan la estabilidad y aplicaciones donde una hora de inactividad es inadmisible. En ese contexto, minimizar cambios es una forma de gestionar el riesgo. Cada actualización de dependencia, cada cambio de imagen base, cada migración implica la posibilidad de romper algo que procesa transacciones o mueve dinero.
Tener un backlog de vulnerabilidades ya no es aceptable
Durante años, aceptar un backlog de vulnerabilidades conocidas fue un intercambio común en el sector financiero para mantener la estabilidad. Las vulnerabilidades eran conocidas pero inactivas, y su explotación requería habilidad, tiempo, coste e incentivo. La probabilidad de que una CVE específica en una aplicación heredada fuera weaponizada antes de la próxima actualización planificada era lo suficientemente baja como para reconocerla y seguir adelante.
Los modelos de vanguardia han cambiado drásticamente este cálculo. Sistemas como Mythos pueden leer código, encontrar debilidades inactivas y encadenarlas más rápido de lo que los humanos pueden investigar y parchear. La brecha entre vulnerabilidades 'públicamente conocidas' y 'prácticamente explotables' se está cerrando, y lo hace precisamente donde las instituciones financieras han acumulado riesgo diferido: la cadena de suministro de software.
Por primera vez registrada, la explotación de vulnerabilidades ha superado al phishing como vector principal de acceso inicial en brechas del sector financiero. Además, más de la mitad de los proveedores de servicios financieros tienen al menos una CVE de alta severidad. Para una institución regulada, un paquete comprometido significa un evento operativo, una conversación regulatoria y un problema de confianza del cliente.
En la práctica, esto implica que el backlog nunca fue estático, pero las suposiciones que justificaban mantenerlo sí han quedado obsoletas. Una excepción firmada hace 18 meses se basa en un modelo de amenaza desactualizado.
La diferencia entre aplicaciones y cadena de suministro de software
Cuando un equipo de seguridad dice 'necesitamos modernizarnos', los líderes de ingeniería entienden modernización de aplicaciones: refactorizar el monolito, actualizar el runtime, migrar la capa de datos, volver a probar todo lo downstream. Eso es un programa multianual, con múltiples equipos y alta inversión de capital, con riesgo operativo real. Los líderes de ingeniería a menudo se resisten a este tipo de cambio, y probablemente tengan razón.
Pero el riesgo que introducen los modelos de vanguardia no reside principalmente en el código de la aplicación. Está en la cadena de suministro de software subyacente: imágenes base con muchas vulnerabilidades, bibliotecas de código abierto extraídas de registros públicos sin procedencia y herramientas de compilación que nunca se han inventariado adecuadamente. La entrada a la aplicación ha quedado expuesta.
Y las entradas se pueden cambiar sin reescribir lo que las consume. Actualizar esas entradas es la 'modernización' más prudente que muchas organizaciones financieras están considerando. Modernizar la cadena de suministro de software no requiere la misma inversión que modernizar las aplicaciones. Se puede cambiar aquello a partir de lo que se construye mucho antes de cambiar lo que se construye.
Cómo se ve esto sin una migración
El enfoque de Chainguard se basa en asegurar aquello a partir de lo que se construye. Imágenes de contenedor minimalistas y reforzadas, junto con bibliotecas de código abierto, se reconstruyen continuamente para que las vulnerabilidades evitables nunca entren en el entorno. Menos componentes significan menos que escanear, menos que clasificar y menos superficie de ataque por diseño, no por remediación.
Para el software que aún no está listo para actualizarse, Chainguard aplica parches de seguridad retroportados a las versiones que las instituciones ejecutan actualmente. Un equipo que utiliza una versión antigua de un runtime o framework recibe artefactos parcheados y confiables para esa versión. La compatibilidad se preserva y el plan de migración sigue su propio calendario.
De cualquier manera, los equipos que usan versiones antiguas reducen su exposición a vulnerabilidades. Para los equipos de plataforma, el cambio operativo es menor de lo esperado. La mayoría de las grandes instituciones financieras ya ejecutan un programa interno de imágenes doradas para estandarizar la base de cientos de equipos de aplicaciones. Mantener esas imágenes es lento y costoso.
Pero cuando los equipos de plataforma reemplazan la fuente upstream de esas imágenes, están replicando artefactos reforzados una vez y distribuyéndolos como bloques de construcción aprobados a través de los registros y pipelines que los equipos ya utilizan. Como resultado, la gestión de vulnerabilidades pasa de que cada equipo de aplicación investigue y reconstruya imágenes base de forma independiente a que un solo equipo de plataforma mantenga un conjunto confiable. Los equipos de aplicación heredan la solución en lugar de hacer el trabajo ellos mismos.
Además, cada artefacto incluye SBOM firmados y procedencia verificable, lo que permite a los equipos responder preguntas comunes de auditoría como '¿Qué se está ejecutando?', '¿De dónde vino?' o '¿Cómo se mantiene?'. Responder estas preguntas permite a los equipos de plataforma y seguridad volver a construir y mantener su negocio principal para sus clientes.
Los costes ocultos de no modernizar
Replantear la modernización hacia la cadena de suministro de software es importante porque 'mantener el statu quo' nunca ha sido la opción de riesgo cero. Solo ha sido la opción con costes distribuidos lo suficientemente ampliamente como para mantenerse fuera del registro de riesgos.
La capacidad de ingeniería consumida por la clasificación repetitiva de CVE en lugar del trabajo de hoja de ruta es un coste real. Ejecutar ciclos de respuesta de emergencia cada vez que una nueva campaña ataca un paquete ampliamente utilizado consume una enorme cantidad de tiempo y ancho de banda. Los hallazgos de auditoría que se vuelven más difíciles de cerrar en cada ciclo causan fatiga y ralentizan la organización. Y todo el esfuerzo de modernización puede detenerse si el equipo está demasiado ocupado parcheando como para implementar nuevos sistemas. Todo este progreso retrasado significa que el equipo de ingeniería no se centra en aquello para lo que existe: construir características que generen ingresos.
Frente a estos costes, adoptar una base de software segura es un cambio comparativamente pequeño, reversible y bien delimitado. Toca la compilación, no la lógica de negocio. Puede comenzar con un equipo de plataforma y un puñado de imágenes. Los equipos de plataforma pueden mejorar la base de software de forma centralizada y distribuir esos artefactos confiables a través de los registros y pipelines que otros equipos ya usan.
El calendario sigue siendo tuyo
Lo más importante que deben entender las organizaciones de servicios financieros sobre la modernización es que los beneficios de seguridad se ven a lo largo del camino, no solo cuando el esfuerzo está 'terminado'. Se puede mejorar enormemente la seguridad mientras se avanza de forma segura en el esfuerzo general de modernización comenzando por la cadena de suministro de software. Con el tiempo, a medida que más del patrimonio se construye sobre valores predeterminados confiables, la postura general de seguridad pasa de reaccionar continuamente a las vulnerabilidades a no heredar la mayoría de ellas en primer lugar. Eso es lo que significa seguro por defecto en la práctica.
Descubra más sobre cómo Chainguard puede ayudar a asegurar la cadena de suministro de software de su organización de servicios financieros hoy.
Nota: Este artículo ha sido escrito y contribuido con experiencia por Matt Stead, gerente de marketing de producto en Chainguard.
Deja una respuesta