Software libre: nuevas obligaciones y multas de hasta €15 millones
Las nuevas obligaciones de notificación de vulnerabilidades vinculadas con la Ley de Resiliencia Cibernética (CRA) elevan las exigencias para las empresas que desarrollan, comercializan o utilizan software con componentes de código abierto. El cambio alcanza especialmente a las organizaciones que dependen de librerías open source, contenedores e infraestructura basada en Linux, que deberán prestar mayor atención al estado de sus dependencias y a la gestión de vulnerabilidades. Las sanciones previstas pueden alcanzar los 15 millones de euros o el 2,5% de la facturación global anual en determinados casos.
Qué cambia para las empresas que utilizan software libre
Las empresas utilizan componentes de código abierto por su disponibilidad y flexibilidad. El problema aparece cuando esos componentes forman parte de productos con múltiples dependencias y no existe un control suficiente sobre su origen, mantenimiento o estado de seguridad.
Las nuevas exigencias incorporan esa gestión al cumplimiento normativo. Las organizaciones deben disponer de evidencias técnicas que permitan demostrar cómo identifican y gestionan las vulnerabilidades y de qué manera aplican los parches de seguridad dentro de los plazos establecidos.
El cambio introduce una responsabilidad adicional sobre los componentes que forman parte de un producto. Una librería utilizada dentro de una aplicación requiere seguimiento porque una vulnerabilidad puede afectar al producto que la incorpora y generar obligaciones para la empresa responsable.
Las dependencias también forman parte del riesgo
Una aplicación puede depender de varias librerías y cada una de ellas puede incorporar otros componentes. Estas dependencias transitivas aumentan la cantidad de elementos que los equipos deben identificar y controlar.
Sin un inventario preciso, resulta más difícil conocer todos los componentes que forman parte de un producto y determinar cuáles requieren actualización cuando aparece una vulnerabilidad.
Por eso, la cadena de suministro de software libre pasa a ocupar un lugar dentro de las tareas de seguridad y cumplimiento. La gestión deja de concentrarse únicamente en el código desarrollado internamente y alcanza también a los componentes de terceros.
Las sanciones elevan el costo de una mala gestión
Las sanciones previstas pueden alcanzar los 15 millones de euros o el 2,5% de la facturación global anual para determinadas organizaciones que comercialicen o mantengan productos digitales con brechas de seguridad no gestionadas.
Ese nivel de sanción incorpora una dimensión económica a la gestión de vulnerabilidades. Una dependencia desactualizada puede requerir una respuesta que involucre tanto a los equipos técnicos como a las áreas responsables del cumplimiento de las obligaciones legales.
También cambia el tipo de evidencia que deben conservar las empresas. Las declaraciones generales de cumplimiento no alcanzan para demostrar cómo se gestionó una vulnerabilidad.
El cumplimiento depende de evidencias técnicas
Los equipos deben identificar los componentes utilizados, conocer su estado y registrar las medidas adoptadas frente a los problemas de seguridad.
Los SBOMs, o inventarios de componentes de software, permiten ordenar esa información y saber qué elementos integran cada producto. Esta información también facilita el seguimiento del ciclo de vida de las dependencias.
La gestión de vulnerabilidades queda así vinculada con procesos que antes podían permanecer separados. Tecnología, mantenimiento y cumplimiento necesitan trabajar sobre la misma información para conocer qué componentes están presentes y qué medidas se aplicaron.
Las PyMEs enfrentan una brecha de preparación
El nivel de preparación no es igual entre las empresas. Mientras los grandes grupos corporativos muestran un nivel de alerta superior al 83% frente a estas normativas, apenas el 12% de las PyMEs tecnológicas comprende el alcance legal de reportar vulnerabilidades en sus cadenas de suministro de software libre.
La diferencia deja expuesto un problema operativo. Las empresas pueden incorporar componentes con rapidez, pero necesitan contar con capacidad suficiente para identificarlos, actualizarlos y responder ante vulnerabilidades.
También adquieren importancia las dependencias que alcanzaron el final de su ciclo comercial. Cuando un producto continúa utilizando componentes que ya no reciben mantenimiento, aumenta la necesidad de controlar su estado y gestionar las alternativas disponibles.
La gestión de dependencias consume recursos de ingeniería
Una dependencia puede permanecer durante años dentro de un producto. Cuando aparece una vulnerabilidad, los equipos deben localizarla, evaluar su impacto y aplicar las actualizaciones correspondientes.
Estas tareas pueden absorber una parte significativa de la capacidad disponible. Los equipos internos pueden llegar a destinar hasta un 60% de su capacidad de ingeniería al mantenimiento, la auditoría y el parcheo de dependencias heredadas.
Ese tiempo dedicado al software existente reduce la capacidad disponible para otras tareas de desarrollo dentro de la misma organización.
El cambio también afecta a los mantenedores de código abierto
La presión sobre las empresas alcanza a un ecosistema en el que muchos proyectos son desarrollados y mantenidos por voluntarios independientes.
Las compañías pueden necesitar respuestas rápidas frente a vulnerabilidades en componentes que utilizan en sus productos. Los mantenedores, sin embargo, no necesariamente funcionan como proveedores de soporte empresarial.
Esta diferencia genera una relación compleja entre quienes desarrollan el código y las organizaciones que dependen de él. La empresa necesita mantener operativo su producto, mientras que el proyecto abierto puede tener recursos y capacidades muy diferentes.
¿Quién mantiene una dependencia cuando aparece una vulnerabilidad?
Cuando una empresa incorpora una librería desarrollada fuera de su organización, depende de ese componente para parte del funcionamiento de su producto.
Si aparece una vulnerabilidad, debe conocer dónde está presente y qué medidas puede aplicar. Cuando el proyecto externo no puede responder con la velocidad requerida, la organización debe asumir una mayor parte del trabajo de actualización, auditoría y parcheo.
El mantenimiento del código abierto adquiere así una dimensión directamente relacionada con la operación de los productos digitales que utilizan esos componentes.
Automatización, SBOMs y control del ciclo de vida
La gestión de este escenario requiere herramientas y procesos capaces de ordenar grandes cantidades de componentes y dependencias.
La automatización de seguridad permite reducir tareas manuales relacionadas con la identificación y el tratamiento de vulnerabilidades. Los SBOMs ofrecen un inventario de los componentes utilizados. El control del ciclo de vida permite detectar dependencias que ya no reciben mantenimiento o que llegaron al final de su período de uso.
Estas herramientas vinculan la seguridad con el trabajo cotidiano de los equipos tecnológicos. La gestión de dependencias pasa a formar parte del mantenimiento habitual del software, junto con las actualizaciones y el control de vulnerabilidades.
El nuevo escenario del software libre
El código abierto continúa formando parte de productos e infraestructuras tecnológicas, pero las empresas que incorporan estos componentes deben mantener un control más preciso sobre su composición y estado.
La responsabilidad empresarial alcanza a cuestiones que comienzan mucho antes de que aparezca una vulnerabilidad. Saber qué librerías utiliza un producto, qué dependencias contienen y cuál es su ciclo de vida permite organizar la respuesta cuando surge un problema de seguridad.
Para los equipos técnicos, esto implica dedicar recursos a inventarios, auditorías, actualizaciones y mantenimiento. Para las empresas, supone integrar esas tareas dentro de sus procesos de cumplimiento.
La relación entre las compañías y las comunidades open source también queda bajo una presión distinta. Quien desarrolla una librería y quien utiliza esa librería dentro de un producto pueden tener responsabilidades y capacidades muy diferentes. La gestión de esa distancia será una parte relevante de la aplicación práctica de las nuevas obligaciones sobre el software libre.
