{"id":14683,"date":"2026-09-11T15:38:03","date_gmt":"2026-09-11T22:38:03","guid":{"rendered":"https:\/\/omnitrust.com\/blog\/historias-desde-las-trincheras-sobre-la-cra-9-el-software-de-codigo-abierto-es-ahora-un-asunto-del-consejo-de-administracion\/"},"modified":"2026-09-11T15:38:03","modified_gmt":"2026-09-11T22:38:03","slug":"historias-desde-las-trincheras-sobre-la-cra-9-el-software-de-codigo-abierto-es-ahora-un-asunto-del-consejo-de-administracion","status":"publish","type":"post","link":"https:\/\/omnitrust.com\/es\/blog\/historias-desde-las-trincheras-sobre-la-cra-9-el-software-de-codigo-abierto-es-ahora-un-asunto-del-consejo-de-administracion\/","title":{"rendered":"Historias desde las trincheras sobre la CRA #9 \u2013 El software de c\u00f3digo abierto es ahora un asunto del consejo de administraci\u00f3n"},"content":{"rendered":"

Este blog es el noveno de nuestra serie Historias desde las trincheras: lecciones aprendidas sobre la CRA<\/em>. Nuestro objetivo al desarrollar estos blogs es ayudar a fabricantes, proveedores de software y proveedores de productos conectados a comprender las realidades pr\u00e1cticas de la implementaci\u00f3n de programas de cumplimiento de la CRA. Nos basaremos en las lecciones que hemos aprendido trabajando con nuestros clientes y hablando con l\u00edderes del sector.\u00a0 Las organizaciones est\u00e1n aprendiendo que un cumplimiento sostenible requiere capacidades de gobernanza, visibilidad, rendici\u00f3n de cuentas y gesti\u00f3n del ciclo de vida que van mucho m\u00e1s all\u00e1 de las actividades tradicionales de ciberseguridad. Crear un producto seguro no es suficiente para lograr el cumplimiento de la CRA.<\/p>\n

 <\/p>\n

Por qu\u00e9 el Reglamento de Ciberresiliencia est\u00e1 elevando el riesgo de la cadena de suministro de software a una prioridad ejecutiva<\/h2>\n

Durante a\u00f1os, el uso de software de c\u00f3digo abierto se consider\u00f3 en gran medida una decisi\u00f3n de ingenier\u00eda.<\/p>\n

Los desarrolladores seleccionaban bibliotecas. Los arquitectos aprobaban frameworks. Los equipos de seguridad hac\u00edan seguimiento de las vulnerabilidades. Los equipos de producto se centraban en la funcionalidad y los calendarios de entrega. La mayor\u00eda de los ejecutivos rara vez necesitaban pensar en los cientos de componentes de c\u00f3digo abierto integrados en sus productos.<\/p>\n

Esos d\u00edas han terminado.<\/p>\n

El Reglamento de Ciberresiliencia (CRA) de la Uni\u00f3n Europea est\u00e1 cambiando la forma en que las organizaciones piensan sobre las cadenas de suministro de software, incluido el software de c\u00f3digo abierto. Lo que antes se consideraba principalmente un asunto t\u00e9cnico se est\u00e1 convirtiendo cada vez m\u00e1s en una cuesti\u00f3n empresarial, de cumplimiento y de gobernanza.<\/p>\n

Por qu\u00e9 el c\u00f3digo abierto es diferente<\/em><\/strong><\/p>\n

El software de c\u00f3digo abierto impulsa pr\u00e1cticamente todos los productos conectados. A diferencia del software comercial, los fabricantes normalmente no tienen una relaci\u00f3n contractual con los desarrolladores que lo crean y mantienen. Muchos proyectos de c\u00f3digo abierto no cuentan con soporte comercial, mantenimiento garantizado ni compromisos de nivel de servicio.<\/p>\n

Cada vez se espera m\u00e1s que las organizaciones comprendan el software que impulsa sus productos, mantengan visibilidad sobre las dependencias, respondan r\u00e1pidamente a las vulnerabilidades y demuestren una gobernanza continua durante todo el ciclo de vida del producto. Bajo la CRA, esto va m\u00e1s all\u00e1 del software desarrollado internamente o licenciado a proveedores comerciales e incluye tambi\u00e9n el software de c\u00f3digo abierto.<\/p>\n

Esta realidad est\u00e1 sacando las conversaciones sobre software de c\u00f3digo abierto de los equipos de ingenier\u00eda y llev\u00e1ndolas a reuniones de liderazgo ejecutivo, revisiones de cumplimiento, comit\u00e9s de auditor\u00eda y consejos de administraci\u00f3n. El problema no es que el software de c\u00f3digo abierto sea inherentemente arriesgado. El problema es la visibilidad y la rendici\u00f3n de cuentas.<\/p>\n

Perspectivas para ejecutivos<\/h2>\n

Una lecci\u00f3n fundamental que est\u00e1 surgiendo de los programas de preparaci\u00f3n para la CRA es que el riesgo de la cadena de suministro de software se ha convertido en un riesgo empresarial. Hist\u00f3ricamente, las organizaciones se centraban en si el software de c\u00f3digo abierto aceleraba el desarrollo, reduc\u00eda los costes o mejoraba la funcionalidad del producto.<\/p>\n

Los consejos de administraci\u00f3n no solo deber\u00edan preguntar qu\u00e9 componentes de c\u00f3digo abierto se utilizan en sus productos; tambi\u00e9n deben considerar el impacto que esos componentes tienen sobre el cumplimiento de la CRA. Esto implica determinar si esos proyectos de c\u00f3digo abierto se mantienen activamente, cu\u00e1l es su nivel de madurez, si cuentan con respaldo comercial, si existen procesos para informar vulnerabilidades, con qu\u00e9 rapidez se corrigen las vulnerabilidades y si siguen existiendo componentes sin soporte o abandonados en productos que se comercializan.\u00a0 En la medida en que existan brechas de soporte, las empresas deben determinar si pueden abordarlas internamente.\u00a0 En algunos casos, grandes empresas han optado por unirse a proyectos de c\u00f3digo abierto o apoyarlos para ayudar a crear procesos sostenibles de notificaci\u00f3n y mitigaci\u00f3n de vulnerabilidades.<\/p>\n

Estas no son preguntas de ingenier\u00eda. Son cuestiones de gobernanza y gesti\u00f3n. Bajo la CRA, las organizaciones deben demostrar visibilidad sobre las dependencias de software, mantener procesos de gesti\u00f3n de vulnerabilidades, respaldar actividades coordinadas de divulgaci\u00f3n y aportar pruebas de una gobernanza continua de la ciberseguridad.<\/p>\n

Como resultado, muchos equipos directivos est\u00e1n descubriendo que el uso de software de c\u00f3digo abierto afecta directamente al cumplimiento normativo, la confianza de los clientes, la seguridad de los productos, la reputaci\u00f3n de la marca y las obligaciones de soporte a largo plazo.<\/p>\n

Por qu\u00e9 el c\u00f3digo abierto se ha convertido en un desaf\u00edo para la CRA<\/h2>\n

El software de c\u00f3digo abierto en s\u00ed no es el problema. De hecho, el desarrollo de software moderno ser\u00eda casi imposible sin \u00e9l.\u00a0 El desaf\u00edo es que muchos proyectos de c\u00f3digo abierto no cuentan con soporte comercial, mantenimiento garantizado ni compromisos de nivel de servicio.<\/p>\n

Las vulnerabilidades pueden afectar a varios productos<\/em><\/strong><\/p>\n

Una vulnerabilidad descubierta en un componente de c\u00f3digo abierto ampliamente utilizado puede afectar a cientos de productos en m\u00faltiples unidades de negocio. Las organizaciones deben poder identificar r\u00e1pidamente los productos afectados, las versiones impactadas, la exposici\u00f3n de los clientes y las mitigaciones disponibles.<\/p>\n

Sin visibilidad, los tiempos de respuesta aumentan dr\u00e1sticamente.<\/p>\n

El soporte a largo plazo genera responsabilidad<\/em><\/strong><\/p>\n

La CRA hace hincapi\u00e9 en la responsabilidad durante todo el ciclo de vida. Las organizaciones deben estar preparadas para gestionar las dependencias de software durante toda la vida \u00fatil con soporte de un producto. Esto plantea preguntas dif\u00edciles respecto al software de c\u00f3digo abierto. Entre ellas se incluye determinar si la empresa utiliza proyectos de c\u00f3digo abierto sin soporte o abandonados, c\u00f3mo se realiza el seguimiento de las vulnerabilidades en el software de c\u00f3digo abierto y c\u00f3mo puede la empresa mitigar las vulnerabilidades encontradas en \u00e9l. \u00a0\u00bfPuede la empresa actualizar por s\u00ed misma el software de c\u00f3digo abierto? \u00bfO puede encontrar contratistas o empresas que ofrezcan soporte a largo plazo para componentes cr\u00edticos de c\u00f3digo abierto?<\/p>\n

Uso generalizado de software de c\u00f3digo abierto<\/em><\/strong><\/p>\n

Las organizaciones dependen cada vez m\u00e1s del software de c\u00f3digo abierto. \u00a0Cuando se piensa en software de c\u00f3digo abierto, normalmente vienen a la mente grandes proyectos como OpenSSL, Linux o PostgreSQL. En realidad, estos son solo la punta del iceberg.<\/p>\n

Una sola aplicaci\u00f3n suele incluir bibliotecas de tiempo de ejecuci\u00f3n del lenguaje de programaci\u00f3n, frameworks de desarrollo (Spring, paquetes OSS de .NET, React, Angular, etc.), bibliotecas criptogr\u00e1ficas, bibliotecas de red, herramientas de compilaci\u00f3n, analizadores JSON\/XML y frameworks de registro. Cada uno de ellos, a su vez, puede depender de decenas de paquetes.<\/p>\n

Ejemplos del mundo real<\/em><\/strong><\/p>\n

Al igual que ocurre con el software desarrollado internamente, la visibilidad sobre el uso de software de c\u00f3digo abierto representa un desaf\u00edo para muchas organizaciones.\u00a0 Cuando se anuncia una vulnerabilidad cr\u00edtica en una biblioteca de c\u00f3digo abierto ampliamente utilizada, los equipos de seguridad empiezan inmediatamente a preguntarse si ese componente existe en sus productos.<\/p>\n

La respuesta deber\u00eda ser sencilla. Pero sin documentaci\u00f3n centralizada y completa, a menudo no lo es. Cada equipo de ingenier\u00eda debe buscar en repositorios de c\u00f3digo, sistemas de documentaci\u00f3n y entornos de desarrollo para determinar la exposici\u00f3n. Esto puede llevar d\u00edas, lo que supone un verdadero problema dado el requisito de notificaci\u00f3n en 24 horas de la CRA.<\/p>\n

Esto se complica a\u00fan m\u00e1s por la naturaleza de los proyectos de c\u00f3digo abierto. No existe una relaci\u00f3n contractual con un proveedor al que las empresas puedan solicitar informaci\u00f3n sobre la composici\u00f3n del software y la exposici\u00f3n a vulnerabilidades. A menudo, el fabricante tiene que determinar por s\u00ed mismo su nivel de exposici\u00f3n.<\/p>\n

Mejores pr\u00e1cticas para gestionar el riesgo del c\u00f3digo abierto bajo la CRA<\/h2>\n

Pr\u00e1cticamente todas las empresas utilizan software de c\u00f3digo abierto en sus productos, incluso si los equipos ejecutivos no son conscientes de ello.\u00a0 Como primer paso para gestionar el software de c\u00f3digo abierto, los equipos de cumplimiento de la CRA deber\u00edan establecer criterios formales de aceptaci\u00f3n para su uso. Entre los criterios importantes se incluyen la madurez del proyecto, la actividad de los responsables de mantenimiento, la frecuencia de las versiones, el historial de seguridad, el modelo de gobernanza, las licencias, las pr\u00e1cticas de prueba y la viabilidad a largo plazo.<\/p>\n

Aunque este es un paso importante, definir criterios de aceptaci\u00f3n para proyectos de c\u00f3digo abierto es una actividad orientada al futuro. Resulta \u00fatil para gestionar el uso de software de c\u00f3digo abierto en nuevos desarrollos de productos, pero no aborda su uso en proyectos heredados. Se necesitan medidas adicionales para los programas de gesti\u00f3n del riesgo del c\u00f3digo abierto dise\u00f1ados para lograr el cumplimiento de la CRA.<\/p>\n

Mantener SBOM completas<\/em><\/strong><\/p>\n

Las empresas deben mantener y actualizar las SBOM durante todo el ciclo de vida de sus productos y deben asegurarse de que todo uso de software de c\u00f3digo abierto est\u00e9 documentado y supervisado. Una vez identificado el conjunto de proyectos de c\u00f3digo abierto, las empresas deben planificar c\u00f3mo gestionar\u00e1n y mantendr\u00e1n estas soluciones para lograr el cumplimiento de la CRA.<\/p>\n

Determinar los planes de soporte y migraci\u00f3n<\/em><\/strong><\/p>\n

Una vez que las empresas dispongan de un inventario de las soluciones de c\u00f3digo abierto que utilizan, deber\u00e1n determinar c\u00f3mo dar\u00e1n soporte a estos componentes. Pueden optar por migrar algunos componentes de c\u00f3digo abierto, buscar soporte de empresas externas que respalden dichos componentes (cuando sea posible) o planificar la prestaci\u00f3n de soporte por cuenta propia.<\/p>\n

Dada la gran dependencia del software de c\u00f3digo abierto, muchas empresas se encuentran entre la espada y la pared. Migrar fuera del software de c\u00f3digo abierto suele ser inviable y proporcionar soporte interno puede resultar igualmente poco pr\u00e1ctico. Como alternativa, algunas empresas est\u00e1n optando por apoyar econ\u00f3micamente proyectos de c\u00f3digo abierto. En otros casos, pueden contratar a empresas que ofrecen soporte para las bibliotecas de c\u00f3digo abierto.<\/p>\n

Supervisar continuamente las vulnerabilidades<\/em><\/strong><\/p>\n

Las organizaciones deber\u00edan evaluar continuamente las vulnerabilidades emergentes frente a los inventarios de software y los productos implementados.\u00a0 La automatizaci\u00f3n puede mejorar significativamente la velocidad de respuesta.<\/p>\n

Errores comunes<\/h2>\n

Hay varios errores recurrentes en las iniciativas de preparaci\u00f3n para la CRA.<\/p>\n

Tratar todo el software de c\u00f3digo abierto por igual<\/em><\/strong><\/p>\n

Existen miles de proyectos de software de c\u00f3digo abierto de uso generalizado. Van desde proyectos creados por un \u00fanico desarrollador hasta grandes proyectos con una financiaci\u00f3n considerable. Por ejemplo, la Linux Foundation tiene un presupuesto anual de m\u00e1s de 300 millones de d\u00f3lares y respalda m\u00e1s de 1300 proyectos de c\u00f3digo abierto distintos.<\/p>\n

Dado el n\u00famero, tama\u00f1o y uso de los proyectos, no sorprende que existan enormes diferencias en el nivel de calidad y soporte entre unos y otros.<\/p>\n

Suponer que la popularidad equivale a calidad<\/em><\/strong><\/p>\n

La adopci\u00f3n generalizada de un proyecto de c\u00f3digo abierto no garantiza una mayor calidad ni un menor riesgo de seguridad.\u00a0 En algunos casos ocurre lo contrario. Los proyectos m\u00e1s populares atraen a un conjunto m\u00e1s amplio de desarrolladores, lo que puede dar lugar a una calidad de c\u00f3digo inconsistente, dificultades para garantizar que todas las nuevas funciones y cambios de c\u00f3digo se revisen y prueben correctamente, y prisas por a\u00f1adir nuevas funciones para admitir nuevos casos de uso.\u00a0 Estos factores pueden contribuir a una menor calidad del c\u00f3digo y a la introducci\u00f3n de vulnerabilidades inesperadas.<\/p>\n

Los proyectos de c\u00f3digo abierto grandes, complejos y ampliamente utilizados tambi\u00e9n son objetivos populares para actores maliciosos. Dado que el software se publica y puede descargarse f\u00e1cilmente, los actores maliciosos pueden analizar el c\u00f3digo para intentar encontrar vulnerabilidades que puedan explotarse en sistemas implementados. Con las nuevas herramientas de IA capaces de analizar c\u00f3digo en busca de vulnerabilidades, este riesgo es mayor que nunca. Los actores maliciosos tambi\u00e9n pueden intentar introducir puertas traseras o vulnerabilidades cuidadosamente ocultas en software de c\u00f3digo abierto haci\u00e9ndose pasar por desarrolladores leg\u00edtimos. En proyectos grandes con muchos desarrolladores, aumenta el riesgo de que se a\u00f1ada c\u00f3digo malicioso sin ser detectado.<\/p>\n

Depender de proyectos sin soporte<\/em><\/strong><\/p>\n

Aunque muchos proyectos de c\u00f3digo abierto siguen desarroll\u00e1ndose activamente, no ocurre as\u00ed en todos los casos. Muchos proyectos son creados por un \u00fanico desarrollador o por un peque\u00f1o equipo que busca resolver un problema espec\u00edfico. Una vez completado el proyecto, los desarrolladores suelen pasar a otros proyectos y dejan de mantener la base de c\u00f3digo original.<\/p>\n

Para las empresas que utilizan estos proyectos, esto crea un riesgo de cumplimiento a largo plazo. Es especialmente cierto en el caso de productos cr\u00edticos y de larga vida \u00fatil. Una vulnerabilidad puede descubrirse mucho despu\u00e9s de que el proyecto haya sido abandonado.\u00a0 Las empresas que utilicen el componente afectado tendr\u00e1n que resolver el problema por su cuenta. \u00a0Dependiendo de la complejidad del software de c\u00f3digo abierto, esto puede ser un verdadero desaf\u00edo. Es posible que no dispongan de desarrolladores internos con las habilidades necesarias para solucionar el problema. Incluso si cuentan con esas habilidades, puede llevar semanas comprender una base de c\u00f3digo desconocida, depurar el problema y dise\u00f1ar una soluci\u00f3n.<\/p>\n

Tratar las SBOM como documentos de cumplimiento<\/em><\/strong><\/p>\n

Las SBOM deber\u00edan servir como herramientas operativas que respalden la gesti\u00f3n de vulnerabilidades, la visibilidad de los productos y la gobernanza del ciclo de vida. Aunque constituyen documentaci\u00f3n importante dentro de un programa de cumplimiento, son solo un punto de partida.<\/p>\n

Acciones para OEM y proveedores de software<\/h2>\n

Las organizaciones que busquen abordar el uso de software de c\u00f3digo abierto en sus programas de preparaci\u00f3n para la CRA deber\u00edan considerar las siguientes acciones.<\/p>\n

Prioridades inmediatas<\/em><\/strong><\/p>\n

    \n
  1. Establecer directrices para el uso de software de c\u00f3digo abierto.<\/li>\n
  2. Crear inventarios completos de componentes de software de c\u00f3digo abierto en todos los productos.<\/li>\n
  3. Identificar los proyectos de software de c\u00f3digo abierto aprobados para su uso continuado.<\/li>\n
  4. Crear planes de migraci\u00f3n para eliminar el uso de proyectos de software de c\u00f3digo abierto sin soporte, abandonados o considerados de alto riesgo.<\/li>\n
  5. Crear programas de supervisi\u00f3n de vulnerabilidades para los componentes de software de c\u00f3digo abierto utilizados en los productos de la empresa.<\/li>\n
  6. Crear planes de respuesta a vulnerabilidades para los componentes de software de c\u00f3digo abierto utilizados en los productos de la empresa. \u00a0Esto puede incluir encontrar empresas que proporcionen soporte comercial para estos proyectos o desarrollar recursos internos capaces de dar soporte al software.<\/li>\n
  7. Considerar la posibilidad de apoyar proyectos de c\u00f3digo abierto que sean cr\u00edticos para la empresa.<\/li>\n
  8. Asignar la responsabilidad sobre el uso de software de c\u00f3digo abierto dentro de la empresa.<\/li>\n
  9. Documentar las pol\u00edticas de uso de software de c\u00f3digo abierto y los planes de mitigaci\u00f3n de vulnerabilidades.<\/li>\n<\/ol>\n

    El software de c\u00f3digo abierto no va a desaparecer, pero las organizaciones necesitan visibilidad continua sobre los componentes de software de sus productos y los riesgos que introducen. A medida que cambian los productos, las dependencias y las vulnerabilidades, esa comprensi\u00f3n tambi\u00e9n debe evolucionar.<\/p>\n

    C\u00f3mo puede ayudar OmniTrust Certify<\/h3>\n

    El software de c\u00f3digo abierto no va a desaparecer, pero las organizaciones necesitan visibilidad continua sobre los componentes de software de sus productos y los riesgos que introducen. A medida que cambian los productos, las dependencias y las vulnerabilidades, esa comprensi\u00f3n tambi\u00e9n debe evolucionar.<\/p>\n

    OmniTrust Certify<\/a> crea un perfil din\u00e1mico del producto que conecta la composici\u00f3n del software, las vulnerabilidades, el riesgo cibern\u00e9tico, los requisitos normativos, los controles y las evidencias a lo largo de todo el ciclo de vida del producto.<\/p>\n

    Con OmniTrust Certify, las organizaciones pueden:<\/p>\n