{"id":25582,"date":"2026-07-02T17:24:22","date_gmt":"2026-07-02T16:24:22","guid":{"rendered":"https:\/\/telecomkh.info\/?p=25582"},"modified":"2026-07-02T17:24:22","modified_gmt":"2026-07-02T16:24:22","slug":"proteger-el-tejido-tecnologico-empresarial-una-hoja-de-ruta-para-el-codigo-abierto","status":"publish","type":"post","link":"https:\/\/telecomkh.info\/?p=25582","title":{"rendered":"Proteger el tejido tecnol\u00f3gico empresarial: una hoja de ruta para el c\u00f3digo abierto"},"content":{"rendered":"

Las vulnerabilidades de d\u00eda cero impulsadas por IA, que han acaparado los titulares, han hecho que el sector se plantee una pregunta: \u00bfel software de c\u00f3digo abierto est\u00e1 suponiendo demasiado riesgo para las empresas? No es una pregunta balad\u00ed, dado que el c\u00f3digo abierto representa m\u00e1s de las tres cuartas partes de la base de c\u00f3digo de una empresa media. Pero la respuesta es clara: el software de c\u00f3digo abierto sigue siendo intr\u00ednsecamente seguro, estructuralmente resiliente y, en esencia, infalible<\/strong><\/p>\n

 <\/p>\n

Por Chris Wright, CTO y vicepresidente s\u00e9nior de Global Engineering en Red Hat<\/em><\/span><\/p>\n

El c\u00f3digo abierto es la base de toda la tecnolog\u00eda moderna, no solo de la inform\u00e1tica empresarial, y esto va mucho m\u00e1s all\u00e1 de Linux. Los servidores de aplicaciones, las bases de datos, el enrutamiento de redes, los entornos de desarrollo y todos los dem\u00e1s componentes invisibles que conforman nuestro tejido tecnol\u00f3gico se nutren, de una forma u otra, de proyectos de c\u00f3digo abierto.
\nEn pocas palabras, no existe una alternativa real al c\u00f3digo abierto. El software propietario es lo que m\u00e1s se le acerca, al estar controlado y ser propiedad de una \u00fanica empresa, pero carece de la escalabilidad, variedad y ubicuidad del c\u00f3digo abierto. Con el software propietario, el c\u00f3digo fuente es una caja negra. Solo el proveedor decide qu\u00e9 se soluciona y cu\u00e1ndo. Cuando se descubre una vulnerabilidad, puede permanecer en secreto, conocida \u00fanicamente por los atacantes que la encontraron. Ese modelo puede dar una falsa sensaci\u00f3n de seguridad, pero el riesgo simplemente se ha ocultado y se ha convertido en una inc\u00f3gnita. El software propietario permite que las vulnerabilidades se multipliquen en la sombra.
\nEl c\u00f3digo abierto cambia esta din\u00e1mica al poner el c\u00f3digo a disposici\u00f3n de todo el mundo, bajo la m\u00e1xima de que \u00abcon los ojos suficientes, todos los errores son visibles\u00bb. Cuando cualquiera puede examinar el c\u00f3digo, cualquiera puede detectar y reportar problemas, algo que ahora se ve enormemente potenciado por el uso de la IA para acelerar la inspecci\u00f3n del c\u00f3digo. Adem\u00e1s, dado que muchas organizaciones dependen del software de c\u00f3digo abierto, existe una gran motivaci\u00f3n colectiva para resolver las vulnerabilidades.
\nNing\u00fan m\u00e9todo de desarrollo de software garantiza un c\u00f3digo perfecto, pero la naturaleza transparente y colaborativa del c\u00f3digo abierto ofrece ventajas claras frente a los modelos propietarios a la hora de combatir las amenazas modernas. Las empresas siempre han estado, y seguir\u00e1n estando, atentas a las vulnerabilidades a medida que se descubren. Lo que ha cambiado es la velocidad. El n\u00famero de vulnerabilidades registradas (CVE) ha crecido m\u00e1s de un 520% desde 2016. Las herramientas de escaneo basadas en IA ahora descubren vulnerabilidades cr\u00edticas de d\u00eda cero en cuesti\u00f3n de horas, no de meses, y menos del uno por ciento de las vulnerabilidades detectadas por IA han sido parcheadas. El verdadero reto actual es la capacidad operativa de las empresas para absorber y desplegar las correcciones con la suficiente rapidez.
\nEste problema se ve agravado por la falta de coordinaci\u00f3n. Todas las grandes organizaciones dependen de los mismos paquetes de c\u00f3digo abierto esenciales (como Spring Framework, Jackson, Log4j, Pandas u OpenSSL). Sin embargo, al no haber coordinaci\u00f3n, cada entidad detecta las mismas vulnerabilidades de manera independiente, desarrolla parches de forma aislada y mantiene bifurcaciones privadas (forks) de las que nadie m\u00e1s se beneficia. El resultado es una duplicidad de esfuerzos con un coste enorme y una calidad desigual, mientras que el ecosistema general sigue expuesto. Para mantener la seguridad, las organizaciones deben contribuir a los proyectos de c\u00f3digo abierto de origen, lo que se conoce como contribuci\u00f3n upstream, acelerar sus procesos operativos y hacerlo de manera conjunta.<\/p>\n

Qu\u00e9 pueden hacer las empresas para empezar hoy mismo<\/strong>
\nEl c\u00f3digo abierto sigue siendo la base m\u00e1s segura para la innovaci\u00f3n, pero reducir el tiempo de exposici\u00f3n a las amenazas requiere una acci\u00f3n inmediata. Estos son algunos pasos sencillos y pr\u00e1cticos que las empresas pueden dar hoy mismo para proteger sus cadenas de suministro de software:<\/p>\n

\u25cf Elegir plataformas respaldadas por proveedores responsables:<\/strong> la infraestructura es el cimiento sobre el que descansa todo lo dem\u00e1s. Conviene verificar que los proveedores que la respaldan contribuyen activamente a los proyectos de c\u00f3digo abierto que distribuyen. Un proveedor con una trayectoria consolidada en contribuciones upstream, backporting de parches de seguridad y divulgaci\u00f3n responsable est\u00e1 comprometido con la salud de la comunidad, no solo con su cuenta de resultados.<\/p>\n

\u25cf Crear un inventario completo de dependencias:<\/strong> El punto de partida es auditar a cartera de aplicaciones para establecer un mapa de partida. Es necesario identificar cada biblioteca de c\u00f3digo abierto, cada dependencia transitiva y cada versi\u00f3n fijada que est\u00e9 corriendo actualmente en producci\u00f3n.<\/p>\n

\u25cf Definir el tiempo de ciclo desde el parche hasta la producci\u00f3n:<\/strong> Medir la realidad actual es imprescindible: cu\u00e1nto tiempo tarda realmente un parche upstream en superar los an\u00e1lisis de seguridad internos, las pruebas, los comit\u00e9s de cambio y los pipelines de despliegue. Una vez establecido ese tiempo, el objetivo debe ser fijar metas ambiciosas para reducir esta ventana al m\u00ednimo.<\/p>\n

\u25cf Automatizar los pipelines de reconstrucci\u00f3n y redespliegue:<\/strong> A medida que la ventana de exposici\u00f3n ante amenazas se reduce de meses a horas, las actualizaciones manuales dejan de ser viables. Preparar el entorno para reconstrucciones de aplicaciones frecuentes, predecibles y automatizadas permite incorporar paquetes seguros a gran velocidad y sin riesgos.<\/p>\n

\u25cf Adoptar soluciones de seguridad activas:<\/strong> Optar por soluciones activas de seguridad en la cadena de suministro que ofrezcan l\u00edneas base sin CVEs conocidos y protecci\u00f3n en tiempo de ejecuci\u00f3n, como Red Hat Hardened Images, Red Hat Trusted Libraries y OpenShift Advanced Cluster Security, permite operar con mayor agilidad y confianza<\/p>\n

Acelerar el cambio con el Proyecto Lightwell<\/strong>
\nA medida que las organizaciones automatizan sus flujos de trabajo para aplicar correcciones m\u00e1s r\u00e1pido, IBM y Red Hat est\u00e1n construyendo un motor de remediaci\u00f3n dise\u00f1ado espec\u00edficamente para suministrarlas. Recientemente hemos presentado el Proyecto Lightwell, un compromiso conjunto de 5.000 millones de d\u00f3lares respaldado por un equipo global de m\u00e1s de 20.000 ingenieros para redefinir la seguridad de la cadena de suministro de software en la era de la IA.
\nEl Proyecto Lightwell escala la metodolog\u00eda probada de Red Hat durante m\u00e1s de dos d\u00e9cadas en el backporting de parches de seguridad de nivel empresarial, el proceso de trasladar correcciones de versiones m\u00e1s recientes a versiones estables ya en producci\u00f3n. Esta disciplina de ingenier\u00eda rigurosa se extiende ahora m\u00e1s all\u00e1 de la capa del sistema operativo hacia el ecosistema m\u00e1s amplio de frameworks de aplicaciones y dependencias: comenzando por Maven\/Java y expandi\u00e9ndose a PyPI (el repositorio de Python), npm (el gestor de paquetes de JavaScript) y otros entornos. Al combinar IA para el procesamiento masivo de amenazas con ingenier\u00eda humana especializada, el proyecto aplica correcciones quir\u00fargicas sobre las versiones estables exactas que las empresas ya ejecutan en producci\u00f3n, eliminando la necesidad de actualizaciones indiscriminadas que pueden desestabilizar los sistemas.
\nSin un mecanismo para que las correcciones sean aceptadas por los proyectos de contribuci\u00f3n upstream, cada backport que una organizaci\u00f3n desarrolla de forma independiente genera un fork privado permanente: una bifurcaci\u00f3n del c\u00f3digo que debe mantenerse de forma aut\u00f3noma ante cada vulnerabilidad, actualizaci\u00f3n o cambio de dependencia posterior. Esto incrementa tanto los costes como los riesgos operativos de la organizaci\u00f3n. El Proyecto Lightwell rompe este ciclo: Red Hat desarrolla la correcci\u00f3n, la entrega a la empresa y la contribuye al proyecto de c\u00f3digo abierto de origen. De este modo, la correcci\u00f3n pasa a formar parte del c\u00f3digo p\u00fablico.
\nEste enfoque se alinea con las directrices de la reciente Orden Ejecutiva sobre IA y ciberseguridad de Estados Unidos, que contempla la creaci\u00f3n de un centro de coordinaci\u00f3n de ciberseguridad en IA para articular el an\u00e1lisis de vulnerabilidades, su validaci\u00f3n y remediaci\u00f3n en las infraestructuras cr\u00edticas. El Proyecto Lightwell est\u00e1 dise\u00f1ado para ser la columna vertebral operativa del sector privado en respuesta a ese mandato.<\/p>\n

Colaborar para proteger la empresa y todo el ecosistema de c\u00f3digo abierto<\/strong>
\nProteger la cadena de suministro de software es un reto colectivo de la industria que ninguna empresa puede resolver en solitario. A trav\u00e9s del Proyecto Lightwell, IBM y Red Hat colaboran con un grupo selecto de l\u00edderes del sector financiero y de infraestructuras cr\u00edticas para establecer un centro de confianza empresarial compartido.
\nEsta red de inteligencia colaborativa aporta tres capacidades que ninguna organizaci\u00f3n podr\u00eda desarrollar de forma independiente. En primer lugar, los miembros comparten hallazgos de nuevas vulnerabilidades y reciben parches coordinados antes de su difusi\u00f3n p\u00fablica, transformando la detecci\u00f3n aislada en una defensa compartida. En segundo lugar, cada parche se entrega listo para producci\u00f3n: firmado criptogr\u00e1ficamente, con un inventario de componentes de software (SBOM) legible por m\u00e1quina y avisos de seguridad para cumplir con los requisitos normativos. En tercer lugar, y de manera fundamental, el Proyecto Lightwell opera bajo el principio de contribuci\u00f3n siempre al c\u00f3digo fuente origina (upstream-always). Cada correcci\u00f3n que desarrollamos se devuelve al proyecto de c\u00f3digo abierto de origen. Al colaborar en este centro, el proyecto no solo protege a las organizaciones individualmente, sino que devuelve sistem\u00e1ticamente los avances de seguridad a la comunidad, manteniendo el c\u00f3digo abierto seguro para todos.<\/p>\n

El c\u00f3digo abierto ha construido la empresa moderna. La vigilancia coordinada y el Proyecto Lightwell ayudan a que este c\u00f3digo siga siendo seguro, solucionando los problemas m\u00e1s r\u00e1pido, como una sola comunidad y en abierto.<\/p>\n

Arriba, en la foto, Chris Wright, CTO y vicepresidente s\u00e9nior de Global Engineering en Red Hat<\/em><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Las vulnerabilidades de d\u00eda cero impulsadas por IA, que han acaparado los titulares, han hecho que el sector se plantee una pregunta: \u00bfel software de c\u00f3digo abierto est\u00e1 suponiendo demasiado riesgo para las empresas? No es una pregunta balad\u00ed, dado que el c\u00f3digo abierto representa m\u00e1s de las tres cuartas partes de la base de … <\/p>\n

Continue reading \u00abProteger el tejido tecnol\u00f3gico empresarial: una hoja de ruta para el c\u00f3digo abierto\u00bb<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":25583,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[15,67],"tags":[],"_links":{"self":[{"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/posts\/25582"}],"collection":[{"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/telecomkh.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=25582"}],"version-history":[{"count":1,"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/posts\/25582\/revisions"}],"predecessor-version":[{"id":25584,"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/posts\/25582\/revisions\/25584"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/media\/25583"}],"wp:attachment":[{"href":"https:\/\/telecomkh.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=25582"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/telecomkh.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=25582"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/telecomkh.info\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=25582"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}