La UE se encuentra en pleno proceso de enmiendas a su propuesta de Ley de Ciberresiliencia (CRA), una ley destinada a reforzar las defensas de Europa contra los ciberataques y mejorar la seguridad de los productos. Esta ley se dirige a una amplia gama de productos comercializados destinados a los consumidores europeos, incluidos los dispositivos del Internet de las Cosas (IoT), los ordenadores de sobremesa y los teléfonos inteligentes. Impone requisitos a los fabricantes y distribuidores de dispositivos en materia de divulgación de vulnerabilidades e introduce nuevas normas de responsabilidad por incidentes de ciberseguridad.

La EFF acoge con satisfacción la intención de la legislación, pero la ley propuesta penalizará a los desarrolladores de código abierto que reciban cualquier cantidad de compensación monetaria por su trabajo. También exigirá a los fabricantes que informen a los reguladores de las vulnerabilidades no parcheadas y explotadas activamente. Con este requisito se corre el riesgo de exponer el conocimiento y la explotación de esas vulnerabilidades a un público más amplio, lo que agravaría los daños que esta legislación pretende mitigar.

Amenazas para el software de fuente abierta

El software de código abierto es la columna vertebral de la Internet moderna. Las contribuciones de los desarrolladores que trabajan en proyectos de código abierto como Linux y Apache, por nombrar sólo dos, se utilizan libremente y se incorporan a productos distribuidos a miles de millones de personas en todo el mundo. Esto sólo es posible a través de fuentes de ingresos que recompensen a los desarrolladores por su trabajo, incluidas las donaciones individuales, subvenciones mediante fundaciones y patrocinios. Este ecosistema de desarrollo y financiación es parte integrante del funcionamiento y la seguridad del mundo del software actual.

La CRA impone responsabilidades a la actividad comercial que introduce productos vulnerables en el mercado. Aunque el considerando 10 de la propuesta de ley exime a los contribuidores de código abierto sin ánimo de lucro de lo que se considera "actividad comercial" y, por tanto, de responsabilidad, la exención define la actividad comercial de forma demasiado amplia. Cualquier desarrollador de código abierto que solicite donaciones o cobre por servicios de soporte para su software no está exento y, por tanto, es responsable de los daños si su producto contiene inadvertidamente una vulnerabilidad que luego se incorpora a un producto, aunque él mismo no haya producido ese producto. Normalmente, los contribuidores y desarrolladores de código abierto escriben software y lo ponen a disposición como un acto de buena voluntad y gratitud hacia otros que han hecho lo mismo. Esto supondría un riesgo para dichos desarrolladores si recibieran siquiera una propina por su trabajo. Las organizaciones más pequeñas que producen código fuente abierto en beneficio público pueden ver impugnada legalmente toda su actividad simplemente por carecer de fondos para cubrir sus riesgos. Esto empujará a desarrolladores y organizaciones a abandonar por completo estos proyectos, perjudicando al código abierto en su conjunto.

Concordamos con muchos otros en plantear esta preocupación y pedimos a la CRA que exima aún más de responsabilidad a las personas que proporcionan software de código abierto, incluso cuando reciben una compensación por su trabajo.

Los requisitos de divulgación de vulnerabilidades suponen una amenaza para la ciberseguridad

El artículo 11 del texto propuesto obliga a los fabricantes a comunicar a la Agencia Europea de Ciberseguridad (ENISA), en un plazo de 24 horas, las vulnerabilidades activamente explotadas. A continuación, ENISA deberá transmitir los detalles de estas vulnerabilidades a los equipos de respuesta a incidentes de seguridad informática (CSIRT) de los Estados miembros y a las autoridades de vigilancia del mercado. Pensado como medida de responsabilidad, este requisito incentiva a los fabricantes de productos con un historial mediocre en materia de seguridad de productos a perseguir y mitigar activamente las vulnerabilidades. Por bienintencionado que sea, este requisito tendrá probablemente consecuencias imprevistas para los fabricantes que dan prioridad a la seguridad de sus productos. Las vulnerabilidades que tienen graves implicaciones para la seguridad de los consumidores suelen ser tratadas por estas empresas como secretos bien guardados hasta que las correcciones se aplican correctamente y se despliegan en los dispositivos finales. Estas vulnerabilidades pueden tardar semanas o incluso meses en corregirse.

La brevedad del plazo desincentivará a las empresas a aplicar correcciones "profundas" que corrijan la causa de fondo de la vulnerabilidad en favor de correcciones "superficiales" que sólo aborden los síntomas. Las correcciones profundas llevan tiempo, y el requisito de 24 horas pone en marcha el temporizador de la respuesta y dará lugar a respuestas chapuceras.

El segundo efecto será que un conjunto más amplio de organismos y personas conocerán rápidamente la vulnerabilidad, lo que ampliará enormemente el riesgo de exposición de estas vulnerabilidades a quienes quieran utilizarlas maliciosamente. El conocimiento gubernamental de una serie de vulnerabilidades de software por parte de los fabricantes podría crear jugosos objetivos para la piratería informática y el espionaje. Los fabricantes preocupados por los resultados de seguridad para sus clientes tendrán poco control o visión de la seguridad operativa de ENISA o de las agencias de los estados miembros con conocimiento de estas vulnerabilidades. Este requisito de notificación aumenta el riesgo de que la vulnerabilidad se añada al arsenal ofensivo de las agencias de inteligencia gubernamentales. Los fabricantes no deberían tener que preocuparse de que la notificación de fallos en su software se traduzca en un aumento de las capacidades de ciberguerra a su costa.

Otro motivo de preocupación es que la obligación de informar no incluye la divulgación pública. Para que los consumidores tomen decisiones informadas sobre sus compras, los detalles sobre las vulnerabilidades de seguridad deberia ser entregada junto con las actualizaciones de seguridad.

Dados los riesgos sustanciales que plantea este requisito, pedimos a los legisladores europeos que se abstengan de imponer plazos inflexibles para abordar los problemas de seguridad y que los informes detallados sobre vulnerabilidades se emitan a ENISA sólo después de que las vulnerabilidades hayan sido corregidas. Además, debería exigirse la divulgación pública detallada de las correcciones de seguridad. En el caso de las empresas que hayan mostrado un historial mediocre en materia de seguridad de sus productos, podrían imponerse requisitos más estrictos, pero esto debería ser la excepción, no la norma.

Más protección para los investigadores de seguridad

La investigación de seguridad de buena fe -que puede incluir la divulgación de vulnerabilidades a los fabricantes- refuerza la seguridad de los productos e infunde confianza a los consumidores. Nos unimos a nuestra organización asociada EDRi en la petición de un puerto seguro para los investigadores que participan en prácticas de divulgación coordinadas. Este puerto seguro no debe implicar que otras formas de divulgación sean perjudiciales o maliciosas. Un puerto seguro general para toda la UE garantizará a los investigadores de seguridad que no se verán amenazados legalmente por hacer lo correcto.

Empecemos con un buen primer paso

La Ley de Ciberresiliencia pretende reforzar la ciberseguridad para todos los europeos. Sin embargo, si no se adoptan cambios en el texto propuesto, tememos que algunos aspectos de la ley tengan el efecto contrario. Hacemos un llamamiento a la Comisión Europea para que se tome en serio las preocupaciones de la comunidad del código abierto y de los profesionales de la seguridad y modifique la propuesta para abordar estas graves preocupaciones.