\n<\/p>\n
Siete fundaciones de c\u00f3digo abierto se est\u00e1n uniendo para crear especificaciones y est\u00e1ndares comunes para la Ley de Resiliencia Cibern\u00e9tica (CRA) de Europa, regulaci\u00f3n adoptada por el Parlamento Europeo el mes pasado.<\/p>\n
La Apache Software Foundation, Blender Foundation, Eclipse Foundation, OpenSSL Software Foundation, PHP Foundation, Python Software Foundation y Rust Foundation revelaron sus intenciones de aunar sus recursos colectivos y conectar los puntos entre las mejores pr\u00e1cticas de seguridad existentes en el desarrollo de software de c\u00f3digo abierto, y garantizar que la tan denostada cadena de suministro de software est\u00e9 a la altura de la tarea cuando la nueva legislaci\u00f3n entre en vigor dentro de tres a\u00f1os.<\/p>\n
Se estima que entre el 70% y el 90% del software actual se compone de componentes de c\u00f3digo abierto, muchos de los cuales son desarrollados de forma gratuita por programadores en su propio tiempo y por su cuenta.<\/p>\n
La Ley de Resiliencia Cibern\u00e9tica se present\u00f3 por primera vez en forma de borrador hace casi dos a\u00f1os, con miras a codificar las mejores pr\u00e1cticas de ciberseguridad para productos de hardware y software vendidos en toda la Uni\u00f3n Europea. Est\u00e1 dise\u00f1ado para obligar a todos los fabricantes de cualquier producto conectado a Internet a mantenerse actualizados con los \u00faltimos parches y actualizaciones de seguridad, con sanciones por deficiencias.<\/p>\n
Estas sanciones por incumplimiento incluyen multas de hasta 15 millones de euros, o el 2,5% de la facturaci\u00f3n global.<\/p>\n
La legislaci\u00f3n en su forma inicial provoc\u00f3 feroces cr\u00edticas de numerosos organismos de terceros, incluidos m\u00e1s de una docena de organismos de la industria de c\u00f3digo abierto que el a\u00f1o pasado escribieron una carta abierta diciendo que la ley podr\u00eda tener un \u00abefecto paralizador\u00bb en el desarrollo de software. El meollo de las quejas se centr\u00f3 en c\u00f3mo los desarrolladores de c\u00f3digo abierto \u201cupstream\u201d podr\u00edan ser considerados responsables de los defectos de seguridad en los productos posteriores, disuadiendo as\u00ed a los mantenedores voluntarios del proyecto de trabajar en componentes cr\u00edticos por temor a represalias legales (esto es similar a las preocupaciones que abundaban en todo el mundo). Ley de IA de la UE, que recibi\u00f3 luz verde el mes pasado).<\/p>\n
La redacci\u00f3n de la regulaci\u00f3n CRA ofrec\u00eda algunas protecciones para el \u00e1mbito del c\u00f3digo abierto, en la medida en que los desarrolladores que no se preocupaban por comercializar su trabajo estaban t\u00e9cnicamente exentos. Sin embargo, el lenguaje estaba abierto a interpretaci\u00f3n en t\u00e9rminos de qu\u00e9 se incluye exactamente bajo el lema de \u201cactividad comercial\u201d: \u00bfcontar\u00edan, por ejemplo, patrocinios, subvenciones y otras formas de asistencia financiera?<\/p>\n
Finalmente se realizaron algunos cambios en el texto y la legislaci\u00f3n revisada abord\u00f3 sustancialmente las preocupaciones aclarando las exclusiones de proyectos de c\u00f3digo abierto.<\/p>\n
Aunque la nueva regulaci\u00f3n ya ha sido aprobada, no entrar\u00e1 en vigor hasta 2027, lo que dar\u00e1 tiempo a todas las partes para cumplir con los requisitos y pulir algunos de los detalles m\u00e1s finos de lo que se espera de ellas. Y esto es para lo que se est\u00e1n uniendo las siete fundaciones de c\u00f3digo abierto por ahora.<\/p>\n
La forma en que evolucionan muchos proyectos de c\u00f3digo abierto ha significado que a menudo tengan documentaci\u00f3n irregular (si es que la tienen), lo que dificulta el respaldo de las auditor\u00edas y dificulta que los fabricantes y desarrolladores posteriores desarrollen sus propios procesos de CRA.<\/p>\n
Muchas de las iniciativas de c\u00f3digo abierto con mejores recursos ya cuentan con est\u00e1ndares de mejores pr\u00e1cticas decentes, relacionados con aspectos como la divulgaci\u00f3n coordinada de vulnerabilidades y la revisi\u00f3n por pares, pero cada entidad puede utilizar diferentes metodolog\u00edas y terminolog\u00edas. Al unirnos como uno solo, esto deber\u00eda contribuir de alguna manera a tratar el desarrollo de software de c\u00f3digo abierto como una \u201ccosa\u201d \u00fanica sujeta a los mismos est\u00e1ndares y procesos.<\/p>\n
Si a esto le sumamos otras regulaciones propuestas, incluida la Ley de Seguridad del Software de C\u00f3digo Abierto en EE.UU., queda claro que las diversas fundaciones y \u201cadministradores del c\u00f3digo abierto\u201d ser\u00e1n objeto de un mayor escrutinio por su papel en la cadena de suministro de software.<\/p>\n
\u00abSi bien las comunidades y fundaciones de c\u00f3digo abierto generalmente se adhieren y han establecido hist\u00f3ricamente las mejores pr\u00e1cticas de la industria en materia de seguridad, sus enfoques a menudo carecen de alineaci\u00f3n y documentaci\u00f3n completa\u00bb, escribi\u00f3 hoy la Fundaci\u00f3n Eclipse en una publicaci\u00f3n de blog. \u00abLa comunidad de c\u00f3digo abierto y la industria del software en general comparten ahora un desaf\u00edo com\u00fan: la legislaci\u00f3n ha introducido una necesidad urgente de est\u00e1ndares de procesos de ciberseguridad\u00bb.<\/p>\n
La nueva colaboraci\u00f3n, aunque inicialmente constar\u00e1 de siete fundaciones, estar\u00e1 encabezada en Bruselas por la Fundaci\u00f3n Eclipse, que alberga cientos de proyectos individuales de c\u00f3digo abierto que abarcan herramientas de desarrollo, marcos, especificaciones y m\u00e1s. Los miembros de la fundaci\u00f3n incluyen a Huawei, IBM, Microsoft, Red Hat y Oracle.<\/p>\n<\/p><\/div>\n