La llegada de la nueva reglamentación europea sobre la seguridad en dispositivos y aplicaciones Cyber Resilience Act va a suponer un cambio muy importante en el desarrollo de productos digitales.
Índice de temas
Qué es Cyber Resilience Act
En el año 2022, la Unión Europea publicó el primer borrador para una futura reglamentación sobre la seguridad de los productos digitales. Esta reglamentación establecerá los estándares mínimos de seguridad que los productos digitales que se comercialicen en la Unión Europea en los próximos años deberán cumplir.
Evidentemente el control de calidad del software ha sido un verdadero quebradero de cabeza desde hace muchos años. Década tras década, las compañías desarrolladoras han ido aplicando sus mejores criterios metodológicos y procedimentales al desarrollo de aplicaciones software. Algo que, aunque loable, ha evidenciado la disparidad de mecanismos y de rigor que se utilizan como condición previa para el lanzamiento de un producto al mercado.
Con el fin de unificar esos requisitos, la Unión Europea puso sobre la mesa el desarrollo de un nuevo reglamento que estableciera un buen número de exigencias a los productos software que fueran a ser comercializados en Europa, asociando calidad y seguridad; desde estándares mínimos de cumplimiento, hasta responsabilidades derivadas de la presencia de vulnerabilidades en los productos que fueran conocidas antes de su comercialización. Se trataría de algo así como una validación del producto hasta la fecha de su puesta en el mercado con garantía CE.
Borrador del reglamento Cyber Resilience Act
El texto de la nueva reglamentación es suficientemente sutil y extenso como para echarle un vistazo un poco más profundo.
Resultan llamativos algunos aspectos que pueden afectar al devenir de la comercialización de productos digitales (ya no solo software, sino también hardware) y que incluyen situaciones como (1) la necesidad de implantar mecanismos de diseño y desarrollo seguro de productos que sean comunes a todos los desarrolladores de aplicaciones; (2) la protección del acceso y de la información en el propio desarrollo de software; (3) la incorporación de mecanismos de ciberseguridad durante todo el ciclo de vida comercial del software, lo que impone actualizaciones periódicas frente a vulnerabilidades detectadas -asumiendo responsabilidades en caso de no cumplirse o (4) la divulgación y compartición de información sobre vulnerabilidades desde el momento de la detección de forma obligatoria dentro de las comunidades de actores definidos. La UE podría incluso hacer una evaluación independiente de forma discrecional de los productos y llegar a sus propias conclusiones con mecanismos sancionadores que podrían llegar a los 15 millones de euros o el 2,5% de la facturación anual de la compañía si esta fuera mayor.
El reglamento, aún por aprobar, recoge algunos puntos que son realmente controvertidos y que van a imponer exigencias importantes a casi cualquier desarrollador de software. Y decimos controvertidos porque uno de los grupos de actores que se verá más afectado es el de los desarrolladores de software libre.
Peticiones del colectivo de software libre
Pese a que el reglamento deja fuera de este marco de aplicación algunos elementos software como el código libre no vinculados a aplicaciones comerciales, servicios en la nube o sitios web de información en general, el nerviosismo ha cundido en el entorno del colectivo de los desarrolladores de software libre.
Si prestamos atención al primero de los elementos mencionados, el software libre, se le añade el sufijo de “no vinculado a aplicaciones comerciales”. Se trata de una cuestión que no es menor porque, pese a que da cobertura a una parte del grupo, un porcentaje muy elevado de aplicaciones comerciales hacen uso de software habitualmente definido como libre. Algunos expertos hablan de un 70%; otros de más allá de un 90%. Sea cual sea el valor real, el resultado es que estas aplicaciones software, suficientemente numerosas, estarían obligadas a validar (y asumir como responsables) la seguridad del software que proporcionan e integran.
El tema tiene a la comunidad de desarrolladores de software libre en pie de guerra ya que el matiz descrito puede resultar insuficiente dada la variedad de actores que participan en el ecosistema y que incluye a fundaciones, plataformas distribuidoras, grupos académicos, personas particulares o incluso entidades gubernamentales.
Grupos como Eclipse Europe, Open Forum Europe , Apache Foundation o Linux Foundation remitieron el pasado mes de abril una carta a la Comisión expresando sus inquietudes y su voluntad de convenir un modelo más acorde a la realidad de este tipo de software. Por ejemplo, GitHub hace unos meses puso sobre la mesa al menos cinco recomendaciones que consideraba que adaptaban mejor a la realidad a un entorno en el que colaboran más de 14 millones de desarrolladores solo en Europa y que mueve un negocio milmillonario.
‘As is’ frente a ‘Es seguro’
Finalmente, el pasado 19 de julio, la Comisión adoptó una posición común respecto al borrador sin introducir respuestas a estas peticiones. Si todo sigue como parece, es posible que durante la presidencia española de Consejo de Europa en este semestre se acabe definitivamente aprobando el documento, aunque su entrada en vigor no tenga lugar antes del próximo año 2024 (incluyendo un periodo de carencia de dos años para algunos actores).
Al final, el software libre, si nada cambia, tendrá que hacer frente a esta nueva situación haciendo uso de la imaginación porque, si se piensa bien, la puesta a disposición de los usuarios e integradores de un software ‘as is’ contradice la condición que impone la Comisión Europea de tener que declarar que “hasta donde se conoce en el sector, el software desarrollado es completamente seguro”.
