Este blog es el noveno de nuestra serie Historias desde las trincheras: lecciones aprendidas sobre la CRA. Nuestro objetivo al desarrollar estos blogs es ayudar a fabricantes, proveedores de software y proveedores de productos conectados a comprender las realidades prácticas de la implementación de programas de cumplimiento de la CRA. Nos basaremos en las lecciones que hemos aprendido trabajando con nuestros clientes y hablando con líderes del sector. Las organizaciones están aprendiendo que un cumplimiento sostenible requiere capacidades de gobernanza, visibilidad, rendición de cuentas y gestión del ciclo de vida que van mucho más allá de las actividades tradicionales de ciberseguridad. Crear un producto seguro no es suficiente para lograr el cumplimiento de la CRA.
Por qué el Reglamento de Ciberresiliencia está elevando el riesgo de la cadena de suministro de software a una prioridad ejecutiva
Durante años, el uso de software de código abierto se consideró en gran medida una decisión de ingeniería.
Los desarrolladores seleccionaban bibliotecas. Los arquitectos aprobaban frameworks. Los equipos de seguridad hacían seguimiento de las vulnerabilidades. Los equipos de producto se centraban en la funcionalidad y los calendarios de entrega. La mayoría de los ejecutivos rara vez necesitaban pensar en los cientos de componentes de código abierto integrados en sus productos.
Esos días han terminado.
El Reglamento de Ciberresiliencia (CRA) de la Unión Europea está cambiando la forma en que las organizaciones piensan sobre las cadenas de suministro de software, incluido el software de código abierto. Lo que antes se consideraba principalmente un asunto técnico se está convirtiendo cada vez más en una cuestión empresarial, de cumplimiento y de gobernanza.
Por qué el código abierto es diferente
El software de código abierto impulsa prácticamente todos los productos conectados. A diferencia del software comercial, los fabricantes normalmente no tienen una relación contractual con los desarrolladores que lo crean y mantienen. Muchos proyectos de código abierto no cuentan con soporte comercial, mantenimiento garantizado ni compromisos de nivel de servicio.
Cada vez se espera más que las organizaciones comprendan el software que impulsa sus productos, mantengan visibilidad sobre las dependencias, respondan rápidamente a las vulnerabilidades y demuestren una gobernanza continua durante todo el ciclo de vida del producto. Bajo la CRA, esto va más allá del software desarrollado internamente o licenciado a proveedores comerciales e incluye también el software de código abierto.
Esta realidad está sacando las conversaciones sobre software de código abierto de los equipos de ingeniería y llevándolas a reuniones de liderazgo ejecutivo, revisiones de cumplimiento, comités de auditoría y consejos de administración. El problema no es que el software de código abierto sea inherentemente arriesgado. El problema es la visibilidad y la rendición de cuentas.
Perspectivas para ejecutivos
Una lección fundamental que está surgiendo de los programas de preparación para la CRA es que el riesgo de la cadena de suministro de software se ha convertido en un riesgo empresarial. Históricamente, las organizaciones se centraban en si el software de código abierto aceleraba el desarrollo, reducía los costes o mejoraba la funcionalidad del producto.
Los consejos de administración no solo deberían preguntar qué componentes de código abierto se utilizan en sus productos; también deben considerar el impacto que esos componentes tienen sobre el cumplimiento de la CRA. Esto implica determinar si esos proyectos de código abierto se mantienen activamente, cuál es su nivel de madurez, si cuentan con respaldo comercial, si existen procesos para informar vulnerabilidades, con qué rapidez se corrigen las vulnerabilidades y si siguen existiendo componentes sin soporte o abandonados en productos que se comercializan. En la medida en que existan brechas de soporte, las empresas deben determinar si pueden abordarlas internamente. En algunos casos, grandes empresas han optado por unirse a proyectos de código abierto o apoyarlos para ayudar a crear procesos sostenibles de notificación y mitigación de vulnerabilidades.
Estas no son preguntas de ingeniería. Son cuestiones de gobernanza y gestión. Bajo la CRA, las organizaciones deben demostrar visibilidad sobre las dependencias de software, mantener procesos de gestión de vulnerabilidades, respaldar actividades coordinadas de divulgación y aportar pruebas de una gobernanza continua de la ciberseguridad.
Como resultado, muchos equipos directivos están descubriendo que el uso de software de código abierto afecta directamente al cumplimiento normativo, la confianza de los clientes, la seguridad de los productos, la reputación de la marca y las obligaciones de soporte a largo plazo.
Por qué el código abierto se ha convertido en un desafío para la CRA
El software de código abierto en sí no es el problema. De hecho, el desarrollo de software moderno sería casi imposible sin él. El desafío es que muchos proyectos de código abierto no cuentan con soporte comercial, mantenimiento garantizado ni compromisos de nivel de servicio.
Las vulnerabilidades pueden afectar a varios productos
Una vulnerabilidad descubierta en un componente de código abierto ampliamente utilizado puede afectar a cientos de productos en múltiples unidades de negocio. Las organizaciones deben poder identificar rápidamente los productos afectados, las versiones impactadas, la exposición de los clientes y las mitigaciones disponibles.
Sin visibilidad, los tiempos de respuesta aumentan drásticamente.
El soporte a largo plazo genera responsabilidad
La CRA hace hincapié en la responsabilidad durante todo el ciclo de vida. Las organizaciones deben estar preparadas para gestionar las dependencias de software durante toda la vida útil con soporte de un producto. Esto plantea preguntas difíciles respecto al software de código abierto. Entre ellas se incluye determinar si la empresa utiliza proyectos de código abierto sin soporte o abandonados, cómo se realiza el seguimiento de las vulnerabilidades en el software de código abierto y cómo puede la empresa mitigar las vulnerabilidades encontradas en él. ¿Puede la empresa actualizar por sí misma el software de código abierto? ¿O puede encontrar contratistas o empresas que ofrezcan soporte a largo plazo para componentes críticos de código abierto?
Uso generalizado de software de código abierto
Las organizaciones dependen cada vez más del software de código abierto. Cuando se piensa en software de código abierto, normalmente vienen a la mente grandes proyectos como OpenSSL, Linux o PostgreSQL. En realidad, estos son solo la punta del iceberg.
Una sola aplicación suele incluir bibliotecas de tiempo de ejecución del lenguaje de programación, frameworks de desarrollo (Spring, paquetes OSS de .NET, React, Angular, etc.), bibliotecas criptográficas, bibliotecas de red, herramientas de compilación, analizadores JSON/XML y frameworks de registro. Cada uno de ellos, a su vez, puede depender de decenas de paquetes.
Ejemplos del mundo real
Al igual que ocurre con el software desarrollado internamente, la visibilidad sobre el uso de software de código abierto representa un desafío para muchas organizaciones. Cuando se anuncia una vulnerabilidad crítica en una biblioteca de código abierto ampliamente utilizada, los equipos de seguridad empiezan inmediatamente a preguntarse si ese componente existe en sus productos.
La respuesta debería ser sencilla. Pero sin documentación centralizada y completa, a menudo no lo es. Cada equipo de ingeniería debe buscar en repositorios de código, sistemas de documentación y entornos de desarrollo para determinar la exposición. Esto puede llevar días, lo que supone un verdadero problema dado el requisito de notificación en 24 horas de la CRA.
Esto se complica aún más por la naturaleza de los proyectos de código abierto. No existe una relación contractual con un proveedor al que las empresas puedan solicitar información sobre la composición del software y la exposición a vulnerabilidades. A menudo, el fabricante tiene que determinar por sí mismo su nivel de exposición.
Mejores prácticas para gestionar el riesgo del código abierto bajo la CRA
Prácticamente todas las empresas utilizan software de código abierto en sus productos, incluso si los equipos ejecutivos no son conscientes de ello. Como primer paso para gestionar el software de código abierto, los equipos de cumplimiento de la CRA deberían establecer criterios formales de aceptación 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ácticas de prueba y la viabilidad a largo plazo.
Aunque este es un paso importante, definir criterios de aceptación para proyectos de código abierto es una actividad orientada al futuro. Resulta útil para gestionar el uso de software de código abierto en nuevos desarrollos de productos, pero no aborda su uso en proyectos heredados. Se necesitan medidas adicionales para los programas de gestión del riesgo del código abierto diseñados para lograr el cumplimiento de la CRA.
Mantener SBOM completas
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ódigo abierto esté documentado y supervisado. Una vez identificado el conjunto de proyectos de código abierto, las empresas deben planificar cómo gestionarán y mantendrán estas soluciones para lograr el cumplimiento de la CRA.
Determinar los planes de soporte y migración
Una vez que las empresas dispongan de un inventario de las soluciones de código abierto que utilizan, deberán determinar cómo darán soporte a estos componentes. Pueden optar por migrar algunos componentes de código abierto, buscar soporte de empresas externas que respalden dichos componentes (cuando sea posible) o planificar la prestación de soporte por cuenta propia.
Dada la gran dependencia del software de código abierto, muchas empresas se encuentran entre la espada y la pared. Migrar fuera del software de código abierto suele ser inviable y proporcionar soporte interno puede resultar igualmente poco práctico. Como alternativa, algunas empresas están optando por apoyar económicamente proyectos de código abierto. En otros casos, pueden contratar a empresas que ofrecen soporte para las bibliotecas de código abierto.
Supervisar continuamente las vulnerabilidades
Las organizaciones deberían evaluar continuamente las vulnerabilidades emergentes frente a los inventarios de software y los productos implementados. La automatización puede mejorar significativamente la velocidad de respuesta.
Errores comunes
Hay varios errores recurrentes en las iniciativas de preparación para la CRA.
Tratar todo el software de código abierto por igual
Existen miles de proyectos de software de código abierto de uso generalizado. Van desde proyectos creados por un único desarrollador hasta grandes proyectos con una financiación considerable. Por ejemplo, la Linux Foundation tiene un presupuesto anual de más de 300 millones de dólares y respalda más de 1300 proyectos de código abierto distintos.
Dado el número, tamaño y uso de los proyectos, no sorprende que existan enormes diferencias en el nivel de calidad y soporte entre unos y otros.
Suponer que la popularidad equivale a calidad
La adopción generalizada de un proyecto de código abierto no garantiza una mayor calidad ni un menor riesgo de seguridad. En algunos casos ocurre lo contrario. Los proyectos más populares atraen a un conjunto más amplio de desarrolladores, lo que puede dar lugar a una calidad de código inconsistente, dificultades para garantizar que todas las nuevas funciones y cambios de código se revisen y prueben correctamente, y prisas por añadir nuevas funciones para admitir nuevos casos de uso. Estos factores pueden contribuir a una menor calidad del código y a la introducción de vulnerabilidades inesperadas.
Los proyectos de código abierto grandes, complejos y ampliamente utilizados también son objetivos populares para actores maliciosos. Dado que el software se publica y puede descargarse fácilmente, los actores maliciosos pueden analizar el código para intentar encontrar vulnerabilidades que puedan explotarse en sistemas implementados. Con las nuevas herramientas de IA capaces de analizar código en busca de vulnerabilidades, este riesgo es mayor que nunca. Los actores maliciosos también pueden intentar introducir puertas traseras o vulnerabilidades cuidadosamente ocultas en software de código abierto haciéndose pasar por desarrolladores legítimos. En proyectos grandes con muchos desarrolladores, aumenta el riesgo de que se añada código malicioso sin ser detectado.
Depender de proyectos sin soporte
Aunque muchos proyectos de código abierto siguen desarrollándose activamente, no ocurre así en todos los casos. Muchos proyectos son creados por un único desarrollador o por un pequeño equipo que busca resolver un problema específico. Una vez completado el proyecto, los desarrolladores suelen pasar a otros proyectos y dejan de mantener la base de código original.
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íticos y de larga vida útil. Una vulnerabilidad puede descubrirse mucho después de que el proyecto haya sido abandonado. Las empresas que utilicen el componente afectado tendrán que resolver el problema por su cuenta. Dependiendo de la complejidad del software de código abierto, esto puede ser un verdadero desafío. 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ódigo desconocida, depurar el problema y diseñar una solución.
Tratar las SBOM como documentos de cumplimiento
Las SBOM deberían servir como herramientas operativas que respalden la gestión de vulnerabilidades, la visibilidad de los productos y la gobernanza del ciclo de vida. Aunque constituyen documentación importante dentro de un programa de cumplimiento, son solo un punto de partida.
Acciones para OEM y proveedores de software
Las organizaciones que busquen abordar el uso de software de código abierto en sus programas de preparación para la CRA deberían considerar las siguientes acciones.
Prioridades inmediatas
- Establecer directrices para el uso de software de código abierto.
- Crear inventarios completos de componentes de software de código abierto en todos los productos.
- Identificar los proyectos de software de código abierto aprobados para su uso continuado.
- Crear planes de migración para eliminar el uso de proyectos de software de código abierto sin soporte, abandonados o considerados de alto riesgo.
- Crear programas de supervisión de vulnerabilidades para los componentes de software de código abierto utilizados en los productos de la empresa.
- Crear planes de respuesta a vulnerabilidades para los componentes de software de código abierto utilizados en los productos de la empresa. Esto puede incluir encontrar empresas que proporcionen soporte comercial para estos proyectos o desarrollar recursos internos capaces de dar soporte al software.
- Considerar la posibilidad de apoyar proyectos de código abierto que sean críticos para la empresa.
- Asignar la responsabilidad sobre el uso de software de código abierto dentro de la empresa.
- Documentar las políticas de uso de software de código abierto y los planes de mitigación de vulnerabilidades.
El software de código 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ón también debe evolucionar.
Cómo puede ayudar OmniTrust Certify
El software de código 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ón también debe evolucionar.
OmniTrust Certify crea un perfil dinámico del producto que conecta la composición del software, las vulnerabilidades, el riesgo cibernético, los requisitos normativos, los controles y las evidencias a lo largo de todo el ciclo de vida del producto.
Con OmniTrust Certify, las organizaciones pueden:
- Generar SBOM a partir del código fuente, binarios o firmware, o incorporar SBOM existentes
- Identificar componentes y dependencias de software de código abierto y de terceros
- Supervisar continuamente la información emergente sobre vulnerabilidades y asociar las nuevas vulnerabilidades con los productos afectados
- Evaluar cómo afectan las vulnerabilidades identificadas al riesgo de ciberseguridad del producto
- Realizar el seguimiento de la revisión, tratamiento y mitigación de vulnerabilidades, así como de las evidencias de respaldo
- Evaluar los productos frente a los requisitos de la CRA y otras normativas y estándares aplicables
- Reevaluar continuamente a medida que cambian los productos, componentes, vulnerabilidades y requisitos
En lugar de tratar la SBOM como un documento estático de cumplimiento, Certify la conecta con un registro dinámico del producto que ayuda a las organizaciones a comprender qué contienen sus productos, qué es vulnerable, qué está en riesgo y qué debe hacerse al respecto.
Resumen: El software de código abierto sigue siendo uno de los mayores aceleradores de la innovación. La CRA no desaconseja su uso, pero exige que las organizaciones lo gestionen de forma responsable. A diferencia del software comercial, las organizaciones heredan la responsabilidad sin tener el control. Los fabricantes que tengan éxito comprenderán no solo qué software de código abierto utilizan, sino también la madurez, el estado, la capacidad de soporte y la postura de seguridad continua de cada dependencia crítica. Por eso el software de código abierto se ha convertido en un asunto del consejo de administración.
Suscríbase al blog en nuestra página principal del blog para recibir notificaciones sobre futuros artículos de esta serie, que continúa con «Blog #10: Evaluar es fácil. Corregir es difícil».
