{"id":167273,"date":"2026-10-22T11:19:12","date_gmt":"2026-10-22T09:19:12","guid":{"rendered":"https:\/\/e3mag.com\/?p=167273"},"modified":"2026-10-22T11:19:17","modified_gmt":"2026-10-22T09:19:17","slug":"lightwell-y-sap-cuando-los-parches-por-si-solos-no-bastan","status":"publish","type":"post","link":"https:\/\/e3mag.com\/es\/lightwell-und-sap-wenn-patchen-allein-nicht-reicht\/","title":{"rendered":"Lightwell y SAP: cuando los parches por s\u00ed solos no bastan"},"content":{"rendered":"

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

Para la seguridad inform\u00e1tica, esto supone un gran problema que los procesos cl\u00e1sicos de gesti\u00f3n de vulnerabilidades solo resuelven en parte. Un esc\u00e1ner detecta una versi\u00f3n vulnerable y el fabricante o la comunidad de c\u00f3digo abierto proporciona una versi\u00f3n corregida. Aunque t\u00e9cnicamente la vulnerabilidad quedar\u00eda as\u00ed subsanada, desde el punto de vista operativo el asunto a\u00fan est\u00e1 lejos de estar resuelto. Y es que la nueva versi\u00f3n no tiene por qu\u00e9 ser necesariamente compatible con los sistemas existentes.<\/p>\n\n\n\n

Una actualizaci\u00f3n puede modificar las API, sustituir dependencias transitivas, provocar regresiones o requerir una nueva certificaci\u00f3n. Por ello, en el caso de una aplicaci\u00f3n cr\u00edtica para el negocio, no solo es importante saber si hay una correcci\u00f3n disponible, sino tambi\u00e9n c\u00f3mo se puede integrar en la versi\u00f3n actual del software. Dado que muchas empresas reh\u00fayen 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.<\/p>\n\n\n\n

<\/div>\n\n\n\n

El momento m\u00edtico obliga a replantearse las cosas<\/h2>\n\n\n\n

Esta tendencia se est\u00e1 acelerando r\u00e1pidamente con la inteligencia artificial. En el marco del proyecto Glasswing de Anthropic, se detectaron miles de vulnerabilidades en software de c\u00f3digo abierto con la ayuda del modelo Mythos Preview, entre ellas casi 3.900 vulnerabilidades de gravedad alta o cr\u00edtica. La IA puede analizar c\u00f3digo a un ritmo inalcanzable con los m\u00e9todos manuales convencionales. Esto tambi\u00e9n cambia la din\u00e1mica de las vulnerabilidades de d\u00eda cero: cuanto m\u00e1s r\u00e1pido se identifican los posibles puntos de ataque, m\u00e1s r\u00e1pido se cierra la ventana de oportunidad para su correcci\u00f3n. Para una empresa concreta, resulta casi imposible evaluar y priorizar por s\u00ed misma cada vulnerabilidad detectada. Esto, a su vez, agrava el problema de la \u00abbrecha de correcci\u00f3n\u00bb. Pueden pasar semanas o incluso meses entre el descubrimiento de una vulnerabilidad y su correcci\u00f3n efectiva en una aplicaci\u00f3n en producci\u00f3n. Durante ese tiempo, las empresas se quedan con una vulnerabilidad conocida, tienen que gestionar sus propios parches o se enfrentan a la decisi\u00f3n de llevar a cabo una actualizaci\u00f3n arriesgada.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Desde el esc\u00e1ner hasta el sistema en producci\u00f3n: entre la identificaci\u00f3n de una vulnerabilidad y su implementaci\u00f3n hay que pasar por el an\u00e1lisis, la correcci\u00f3n, la compilaci\u00f3n, las pruebas y la aprobaci\u00f3n, lo que requiere mucho tiempo. (Fuente: Red Hat)<\/em><\/figcaption><\/figure>\n\n\n\n

Pero tambi\u00e9n las \u201eviejas\u201c vulnerabilidades siguen siendo un problema. Un ejemplo especialmente significativo es Log4Shell. La vulnerabilidad en la extendida biblioteca Java Apache Log4j se hizo p\u00fablica a finales de 2021 y se clasific\u00f3 como cr\u00edtica. Las aplicaciones afectadas eran aquellas que utilizaban una versi\u00f3n vulnerable y desactualizada de la biblioteca. En determinadas circunstancias, los atacantes pod\u00edan aprovecharla para ejecutar c\u00f3digo 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 \u2014y, por tanto, olvidadas\u2014 en la cadena de suministro de software siguen suponiendo enormes vulnerabilidades.<\/p>\n\n\n\n

A esto se suma el hecho de que una simple actualizaci\u00f3n de seguridad no es suficiente por s\u00ed sola. El camino desde el parche hasta la producci\u00f3n suele ser arduo: hay que recompilar la aplicaci\u00f3n, realizar pruebas automatizadas y manuales, comprobar las dependencias y autorizar los cambios. En el caso de las aplicaciones cr\u00edticas, pueden a\u00f1adirse, en su caso, aceptaciones t\u00e9cnicas, 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\u00e1pido que una empresa pueda acceder a una nueva actualizaci\u00f3n de seguridad, si el proceso interno de compilaci\u00f3n e implementaci\u00f3n requiere varias semanas o incluso meses, la vulnerabilidad permanecer\u00e1 durante ese tiempo o ni siquiera se abordar\u00e1.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Lightwell: correcci\u00f3n de seguridad en lugar de un cambio de versi\u00f3n obligatorio<\/h2>\n\n\n\n

Lightwell, una iniciativa conjunta de Red Hat e IBM destinada a proteger la cadena de suministro del software de c\u00f3digo abierto, aborda precisamente esta carencia. El concepto ampl\u00eda un principio que Red Hat lleva d\u00e9cadas aplicando en el \u00e1mbito del software empresarial: las correcciones de seguridad no se distribuyen necesariamente mediante un salto de versi\u00f3n completo, sino que pueden retroportarse de forma selectiva a una versi\u00f3n 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\u00f3n soluciona la vulnerabilidad sin modificar autom\u00e1ticamente toda la estructura de dependencias de la aplicaci\u00f3n.<\/p>\n\n\n\n

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

<\/div>\n\n\n\n
\n

Las empresas tienen tres opciones a la hora de subsanar las vulnerabilidades:<\/h2>\n\n\n\n
    \n
  1. Actualizaci\u00f3n cl\u00e1sica:<\/strong> La aplicaci\u00f3n adopta una versi\u00f3n m\u00e1s reciente de la dependencia y asume los costes asociados en materia de compatibilidad y pruebas.<\/li>\n\n\n\n
  2. Aceptar el riesgo o aplicar el parche uno mismo:<\/strong> La organizaci\u00f3n mantiene la versi\u00f3n actual y, si es necesario, crea su propia soluci\u00f3n alternativa o bifurcaci\u00f3n.<\/li>\n\n\n\n
  3. Retroportabilidad selectiva:<\/strong> La correcci\u00f3n de seguridad se adapta a la versi\u00f3n en producci\u00f3n y se integra en la cadena de suministro existente como un artefacto controlado, sin necesidad de modificar la aplicaci\u00f3n.<\/li>\n<\/ol>\n\n\n\n

    La variante m\u00e1s adecuada depende de la aplicaci\u00f3n, el perfil de riesgo y el modelo operativo. Lightwell ampl\u00eda as\u00ed el abanico de soluciones t\u00e9cnicas con una opci\u00f3n que resulta especialmente relevante en el caso de aplicaciones estables, duraderas y dif\u00edciles de modificar.<\/p>\n<\/div><\/div>\n\n\n\n

    <\/div>\n\n\n\n

    Por ello, Lightwell no solo proporciona artefactos parcheados y firmados, sino tambi\u00e9n 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\u00e9s de Sigstore o Cosign. Esto resulta especialmente relevante para los clientes de SAP, ya que, como se ha mencionado, la dependencia del c\u00f3digo abierto no termina en los l\u00edmites del sistema SAP. En un entorno de integraci\u00f3n, las bibliotecas Java, los componentes de mensajer\u00eda, las API, los contenedores, las herramientas de compilaci\u00f3n o los marcos de IA pueden formar parte del sistema global. Una SBOM hace que estos componentes sean visibles y legibles por m\u00e1quina. VEX (Vulnerability Exploitability Exchange) va incluso un paso m\u00e1s all\u00e1.<\/p>\n\n\n\n

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

    Estos artefactos verificables de la cadena de suministro y de compilaci\u00f3n tambi\u00e9n son relevantes de cara a futuros requisitos europeos de certificaci\u00f3n y cumplimiento, o bien de car\u00e1cter voluntario, como el EUCS (Esquema Europeo de Certificaci\u00f3n de Ciberseguridad para Servicios en la Nube) o el EUCC (Esquema Europeo de Certificaci\u00f3n de Ciberseguridad basado en los Criterios Comunes).<\/p>\n\n\n\n

    <\/div>\n\n\n\n

    Dos versiones para diferentes necesidades<\/h2>\n\n\n\n

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

    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\u00e9s de repositorios de Maven y desempe\u00f1an un papel importante en numerosos escenarios de integraci\u00f3n, middleware y aplicaciones propias de los clientes. Al mismo tiempo, Java es solo el principio. Est\u00e1 previsto que Lightwell se ampl\u00ede a otros ecosistemas, como PyPI, npm y Go, para satisfacer las necesidades de los sectores regulados, en los que la gesti\u00f3n de versiones fijas o \u00abpinned\u00bb reviste especial importancia. Actualmente, la soluci\u00f3n est\u00e1 disponible en dos versiones diferentes.<\/p>\n\n\n\n

    <\/div>\n\n\n\n
    \n

    Lightwell no sustituye a:<\/h2>\n\n\n\n