Lightwell y SAP: cuando los parches por sí solos no bastan

El código abierto es ya imprescindible en las aplicaciones empresariales modernas. Esto también se aplica a los entornos SAP, incluso cuando el software utilizado solo constituye una parte del conjunto de tecnologías. Y es que, en torno a estos sistemas, existen plataformas de integración, desarrollos propios, soluciones de automatización, interfaces, herramientas de supervisión y numerosas aplicaciones más, muchas de las cuales se basan en componentes de código abierto o los incorporan como dependencias. De este modo, se crea una cadena de suministro de software que es considerablemente más amplia que el propio producto SAP.

Para la seguridad informática, esto supone un gran problema que los procesos clásicos de gestión de vulnerabilidades solo resuelven en parte. Un escáner detecta una versión vulnerable y el fabricante o la comunidad de código abierto proporciona una versión corregida. Aunque técnicamente la vulnerabilidad quedaría así subsanada, desde el punto de vista operativo el asunto aún está lejos de estar resuelto. Y es que la nueva versión no tiene por qué ser necesariamente compatible con los sistemas existentes.

Una actualización puede modificar las API, sustituir dependencias transitivas, provocar regresiones o requerir una nueva certificación. Por ello, en el caso de una aplicación crítica para el negocio, no solo es importante saber si hay una corrección disponible, sino también cómo se puede integrar en la versión actual del software. Dado que muchas empresas rehúyen este riesgo o no quieren asumirlo, las vulnerabilidades conocidas quedan sin resolver, se acumulan como excepciones de seguridad a largo plazo o requieren costosos parches y bifurcaciones propietarios.

El momento mítico obliga a replantearse las cosas

Esta tendencia se está acelerando rápidamente con la inteligencia artificial. En el marco del proyecto Glasswing de Anthropic, se detectaron miles de vulnerabilidades en software de código abierto con la ayuda del modelo Mythos Preview, entre ellas casi 3.900 vulnerabilidades de gravedad alta o crítica. La IA puede analizar código a un ritmo inalcanzable con los métodos manuales convencionales. Esto también cambia la dinámica de las vulnerabilidades de día cero: cuanto más rápido se identifican los posibles puntos de ataque, más rápido se cierra la ventana de oportunidad para su corrección. Para una empresa concreta, resulta casi imposible evaluar y priorizar por sí misma cada vulnerabilidad detectada. Esto, a su vez, agrava el problema de la «brecha de corrección». Pueden pasar semanas o incluso meses entre el descubrimiento de una vulnerabilidad y su corrección efectiva en una aplicación en producción. Durante ese tiempo, las empresas se quedan con una vulnerabilidad conocida, tienen que gestionar sus propios parches o se enfrentan a la decisión de llevar a cabo una actualización arriesgada.

Pero también las „viejas“ vulnerabilidades siguen siendo un problema. Un ejemplo especialmente significativo es Log4Shell. La vulnerabilidad en la extendida biblioteca Java Apache Log4j se hizo pública a finales de 2021 y se clasificó como crítica. Las aplicaciones afectadas eran aquellas que utilizaban una versión vulnerable y desactualizada de la biblioteca. En determinadas circunstancias, los atacantes podían aprovecharla para ejecutar código malicioso de forma remota y, de este modo, obtener un acceso amplio a los sistemas afectados. Aunque Log4Shell suele estar parcheado en los sistemas importantes, las dependencias de Log4Shell obsoletas —y, por tanto, olvidadas— en la cadena de suministro de software siguen suponiendo enormes vulnerabilidades.

A esto se suma el hecho de que una simple actualización de seguridad no es suficiente por sí sola. El camino desde el parche hasta la producción suele ser arduo: hay que recompilar la aplicación, realizar pruebas automatizadas y manuales, comprobar las dependencias y autorizar los cambios. En el caso de las aplicaciones críticas, pueden añadirse, en su caso, aceptaciones técnicas, requisitos de cumplimiento normativo o procesos formales de cambio. Por lo tanto, la velocidad de los procesos posteriores se convierte en un factor esencial. Por muy rápido que una empresa pueda acceder a una nueva actualización de seguridad, si el proceso interno de compilación e implementación requiere varias semanas o incluso meses, la vulnerabilidad permanecerá durante ese tiempo o ni siquiera se abordará.

Lightwell: corrección de seguridad en lugar de un cambio de versión obligatorio

Lightwell, una iniciativa conjunta de Red Hat e IBM destinada a proteger la cadena de suministro del software de código abierto, aborda precisamente esta carencia. El concepto amplía un principio que Red Hat lleva décadas aplicando en el ámbito del software empresarial: las correcciones de seguridad no se distribuyen necesariamente mediante un salto de versión completo, sino que pueden retroportarse de forma selectiva a una versión que siga recibiendo soporte. El objetivo es incorporar el cambio relevante para la seguridad sin forzar al mismo tiempo un cambio innecesario en las funcionalidades o en la API. Para las empresas, este es un aspecto importante: una retroportación soluciona la vulnerabilidad sin modificar automáticamente toda la estructura de dependencias de la aplicación.

La diferencia con respecto a una bifurcación manual es enorme. Aunque, en teoría, una empresa podría copiar el código fuente de una biblioteca afectada, aplicar el parche y compilar su propio artefacto, Sin embargo, con ello también asumiría de forma permanente la responsabilidad de esa bifurcación: el proceso de compilación, la firma, las dependencias, otras correcciones de seguridad, la documentación y, en su caso, la posterior integración en el código original. Otra diferencia con respecto a la gestión convencional de parches radica en lo que ocurre tras aplicar la actualización. En una cadena de suministro de software moderna, ya no basta con proporcionar un nuevo archivo JAR. Las empresas deben poder rastrear qué están utilizando, de dónde procede, cómo se ha compilado y qué información de seguridad está asociada a ello.

Por ello, Lightwell no solo proporciona artefactos parcheados y firmados, sino también metadatos de la cadena de suministro. Entre ellos se incluyen, entre otros, las listas de materiales de software (SBOM), la procedencia SLSA de nivel 3 y las firmas a través de Sigstore o Cosign. Esto resulta especialmente relevante para los clientes de SAP, ya que, como se ha mencionado, la dependencia del código abierto no termina en los límites del sistema SAP. En un entorno de integración, las bibliotecas Java, los componentes de mensajería, las API, los contenedores, las herramientas de compilación o los marcos de IA pueden formar parte del sistema global. Una SBOM hace que estos componentes sean visibles y legibles por máquina. VEX (Vulnerability Exploitability Exchange) va incluso un paso más allá.

Una SBOM responde, en esencia, a la pregunta de qué componentes están presentes. VEX puede aportar información complementaria sobre si un software se ve realmente afectado por una vulnerabilidad concreta y de qué manera. Para las empresas sujetas a regulación, esto reviste una importancia crucial. Los requisitos de DORA, NIS2 o la Ley de Resiliencia Cibernética aumentan la presión para documentar de forma trazable los componentes de software, las vulnerabilidades y su gestión. Lightwell proporciona esta información junto con los artefactos, de modo que no es necesario recopilarla manualmente a posteriori a partir de diferentes fuentes.

Estos artefactos verificables de la cadena de suministro y de compilación también son relevantes de cara a futuros requisitos europeos de certificación y cumplimiento, o bien de carácter voluntario, como el EUCS (Esquema Europeo de Certificación de Ciberseguridad para Servicios en la Nube) o el EUCC (Esquema Europeo de Certificación de Ciberseguridad basado en los Criterios Comunes).

Dos versiones para diferentes necesidades

Además, Lightwell no se limita a intervenir una vez que el parche está listo. El modelo combina la clasificación basada en IA con la experiencia de los ingenieros humanos. La IA ayuda a gestionar el enorme aluvión de CVE analizando las vulnerabilidades en cuestión de segundos, evaluando su relevancia y elaborando posibles correcciones. A continuación, los cambios resultantes se someten a pruebas automatizadas y son validados por expertos humanos —concretamente, más de 20 000 técnicos de Red Hat e IBM— antes de ser distribuidos como artefactos. Sin embargo, los parches desarrollados no solo se ponen a disposición de los clientes, sino que, en consonancia con el espíritu de la comunidad de código abierto, también se devuelven a los proyectos originales para que todo el sector se beneficie de ellos.

El enfoque inicial del ecosistema Lightwell se centra en Maven/Java. Esto resulta especialmente interesante para los clientes de SAP, ya que las aplicaciones Java suelen obtener sus dependencias a través de repositorios de Maven y desempeñan un papel importante en numerosos escenarios de integración, middleware y aplicaciones propias de los clientes. Al mismo tiempo, Java es solo el principio. Está previsto que Lightwell se amplíe a otros ecosistemas, como PyPI, npm y Go, para satisfacer las necesidades de los sectores regulados, en los que la gestión de versiones fijas o «pinned» reviste especial importancia. Actualmente, la solución está disponible en dos versiones diferentes.

Lightwell Network permite el acceso de autoservicio al catálogo disponible de paquetes adecuados y corregidos. Esto incluye archivos binarios y código fuente firmados digitalmente, así como artefactos de cumplimiento normativo. Por su parte, Lightwell Clearinghouse Premier está dirigido a sectores altamente regulados que requieren una atención intensiva. Las empresas se benefician además, entre otras cosas, de un servicio de notificación de vulnerabilidades para versiones de paquetes específicas del cliente, una revisión prioritaria de vulnerabilidades de nuevo tipo, así como de un gestor técnico de cuentas (TAM) dedicado a la seguridad y una corrección garantizada contractualmente (basada en un SLA) para determinados ámbitos de aplicación.

¿Qué significa esto concretamente para los clientes y socios de SAP?

Para los clientes de SAP, es importante saber que Lightwell no está pensado para sustituir las actualizaciones de seguridad habituales. Si se detecta una vulnerabilidad en un producto de SAP, la responsabilidad de subsanarla recae, por principio, en SAP. Las correcciones correspondientes se facilitan a través de los procesos establecidos, como las notas de seguridad de SAP. Además, Lightwell no sustituye los procesos de seguridad y desarrollo existentes en las empresas. Esto incluye, por un lado, las herramientas de análisis de vulnerabilidades y, por otro, la responsabilidad de la integración, las pruebas de aplicaciones, la aprobación y la implementación sigue recayendo en la empresa. Sin embargo, Lightwell modifica el punto de partida técnico de estas pruebas. La dependencia utilizada en producción se mantiene inicialmente en su versión actual, mientras que la corrección de seguridad se adapta específicamente a dicha versión. El artefacto está firmado, incluye información de la cadena de suministro y puede obtenerse a través del repositorio y el proceso de compilación existentes. Así pues, en lugar de validar un salto de versión completo, se valida una corrección de seguridad específica.

De este modo, Lightwell también resulta interesante para los socios de SAP. Los integradores de sistemas, las consultoras y los proveedores de servicios gestionados pueden ampliar sus competencias actuales en la gestión de SAP, la gestión del ciclo de vida de las aplicaciones, la gestión del cambio y DevSecOps. Los socios pueden, por ejemplo, empezar por aportar transparencia sobre las dependencias de código abierto de un entorno de aplicaciones. A continuación, pueden evaluar qué componentes son especialmente críticos, qué excepciones de seguridad ya existen y en qué punto se producen retrasos entre la disponibilidad de los parches y la puesta en producción. Otro punto de partida es la integración en los procesos de DevSecOps existentes. Los artefactos de Lightwell deben integrarse en los repositorios, los procesos de compilación y los procedimientos de prueba. Las recompilaciones y pruebas automatizadas pueden ayudar a acortar el tiempo que transcurre entre la disponibilidad de una corrección y su puesta en producción. Para los proveedores de servicios de SAP, esta no es una disciplina totalmente nueva, ya que cuentan con suficiente experiencia en la gestión de versiones, copias de sistemas, procesos de transporte y el funcionamiento de sistemas críticos para el negocio. Estas competencias pueden trasladarse ahora a las dependencias de código abierto relacionadas con las aplicaciones SAP. Los temas de gobernanza y cumplimiento normativo también forman parte de ello. Las empresas necesitan información comprensible y, sobre todo, documentada sobre qué componentes se utilizan, qué vulnerabilidades existen, qué corrección se ha aplicado y cuándo se ha incorporado a la producción.

El software de código abierto necesita un proceso de mantenimiento sólido

El verdadero significado de Lightwell no radica en un único repositorio ni en un único parche. Más bien, aborda un problema estructural de la cadena de suministro del código abierto. El código abierto acelera la innovación, pero distribuye la responsabilidad de los distintos componentes a lo largo de un ecosistema complejo. No obstante, las empresas deben tratar estos componentes como parte de su propia cadena de suministro. Sin embargo, con el avance de la inteligencia artificial y la consiguiente aceleración del análisis de vulnerabilidades, resulta cada vez más difícil subsanar cada vulnerabilidad detectada mediante un proceso de actualización clásico.

Aquí es donde entra en juego Lightwell, con su combinación de triaje basado en IA, generación automatizada de parches, retroportabilidad a versiones de producción concretas, validación técnica, distribución firmada y artefactos de cumplimiento legibles por máquina. El objetivo es incorporar los procesos de seguridad a la producción de forma controlada y trazable, incluso cuando un salto de versión no sea una opción viable por motivos técnicos, normativos u operativos.

Al directorio de socios: