La Ley de Resiliencia Cibernética (CRA) eleva las exigencias para las empresas que desarrollan, comercializan o utilizan productos con componentes de código abierto. La gestión de vulnerabilidades, las dependencias y los inventarios de software pasan a tener un peso mayor dentro de los procesos de seguridad y cumplimiento, con sanciones que 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
El uso de componentes de código abierto forma parte de numerosos productos y servicios tecnológicos. Una aplicación puede incorporar varias librerías y, a su vez, cada una de ellas depender de otros componentes.
Ese entramado dificulta saber qué elementos forman parte de un producto y cuáles necesitan una actualización cuando aparece una vulnerabilidad. Por eso, las nuevas obligaciones exigen un mayor control sobre el origen, mantenimiento y estado de seguridad de las dependencias.
Las empresas necesitan contar con evidencias técnicas que permitan demostrar cómo identifican las vulnerabilidades, qué medidas adoptan y cómo aplican los parches dentro de los plazos correspondientes.
La responsabilidad sobre la seguridad deja así de concentrarse únicamente en el código desarrollado internamente. Los componentes de terceros también forman parte del producto y requieren seguimiento.
Las dependencias también forman parte del riesgo
Una vulnerabilidad en una librería puede afectar a una aplicación que la utiliza sin que el código vulnerable haya sido desarrollado por la propia empresa.
Las dependencias transitivas aumentan todavía más la cantidad de componentes que deben identificarse y controlar. Sin un inventario preciso, resulta más difícil localizar dónde está presente una vulnerabilidad y determinar qué productos necesitan una actualización.
Los SBOM, o inventarios de componentes de software, permiten ordenar esta información. También ayudan a seguir el ciclo de vida de las dependencias y detectar componentes que ya no reciben mantenimiento.
La gestión de vulnerabilidades queda vinculada de esta manera con tareas que antes podían funcionar por separado. Tecnología, mantenimiento y cumplimiento necesitan trabajar sobre una misma visión de los componentes utilizados.
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.
El impacto económico hace que la respuesta ante una vulnerabilidad involucre tanto a los equipos técnicos como a las áreas responsables del cumplimiento legal.
También cambia el valor de la documentación. Una declaración general de cumplimiento no demuestra por sí misma cómo se identificó una vulnerabilidad, qué componente estaba afectado o qué medidas se aplicaron.
La empresa necesita conservar registros que permitan reconstruir ese proceso y demostrar las acciones realizadas.
Las PyMEs tienen una brecha de preparación
El nivel de preparación frente a estas obligaciones no es uniforme. Según los datos incluidos en el material, más del 83% de los grandes grupos corporativos muestra un nivel de alerta frente a estas normativas, mientras que solo el 12% de las PyMEs tecnológicas comprende el alcance legal de reportar vulnerabilidades en sus cadenas de suministro de software libre.
La diferencia puede traducirse en dificultades operativas. Incorporar componentes de código abierto requiere después identificarlos, mantenerlos actualizados y responder cuando aparece un problema de seguridad.
La situación también alcanza a las dependencias que llegaron al 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 evaluar alternativas.
Mantener 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 la actualización correspondiente.
Según el material, estas tareas pueden llegar a consumir hasta el 60% de la capacidad de ingeniería de algunos equipos cuando se trata de mantenimiento, auditoría y parcheo de dependencias heredadas.
Ese trabajo reduce el tiempo disponible para otras tareas de desarrollo y convierte la gestión del software existente en una parte relevante de la capacidad tecnológica de las empresas.
El cambio también alcanza a los mantenedores de código abierto
Las nuevas exigencias afectan a un ecosistema en el que muchos proyectos son desarrollados y mantenidos por voluntarios o equipos independientes.
Las empresas pueden necesitar respuestas rápidas frente a vulnerabilidades de componentes que utilizan en sus productos, pero los mantenedores de esos proyectos no necesariamente ofrecen soporte empresarial ni cuentan con los mismos recursos que las organizaciones que dependen de su código.
Cuando un proyecto externo no puede responder con la velocidad requerida, la empresa puede tener que asumir una mayor parte del trabajo de actualización, auditoría y parcheo.
La diferencia entre quien mantiene una librería y quien la incorpora a un producto adquiere así una importancia operativa directa.
Automatización y SBOM para controlar el ciclo de vida
La cantidad de componentes y dependencias hace difícil gestionar todo el proceso manualmente. Las herramientas de automatización de seguridad pueden reducir parte del trabajo relacionado con la identificación y tratamiento de vulnerabilidades.
Los SBOM permiten conocer qué componentes forman parte de cada producto, mientras que el seguimiento del ciclo de vida ayuda a detectar dependencias que dejaron de recibir mantenimiento o alcanzaron el final de su período de uso.
Estas herramientas integran la gestión de dependencias con el mantenimiento habitual del software. Actualizaciones, inventarios y control de vulnerabilidades pasan a trabajar sobre una misma base de información.
El cambio obliga a las empresas a conocer con mayor precisión qué código incorporan a sus productos y qué ocurre con él a lo largo del tiempo. Para los equipos técnicos, esto implica recursos destinados a inventarios, auditorías, actualizaciones y mantenimiento. Para las organizaciones, supone incorporar esas tareas a sus procesos de cumplimiento.
La relación entre las compañías y los proyectos de código abierto también queda atravesada por esta diferencia de capacidades. Una empresa puede depender de una librería para mantener operativo un producto, mientras que el proyecto que desarrolla esa librería puede disponer de recursos muy distintos para responder ante una vulnerabilidad.
