La estrategia de ciberseguridad de Europa debe ser clara sobre el código abierto

La política de seguridad cibernética de Europa tiene un problema de fuente abierta. En comparación con los EE. UU., el Reino Unido y Europa se han estado poniendo al día en la estrategia de seguridad nacional para la resiliencia de las cadenas de suministro de software de código abierto contra actores maliciosos. El código abierto impulsa nuestra infraestructura de software crítica y puede usarse como una amenaza contra ella: Microsoft descubrió recientemente que los componentes de código abierto vulnerables se estaban explotando para piratear las redes de energía en la India. En 2021, la vulnerabilidad Log4shell, la vulnerabilidad de seguridad de mayor propagación en la historia reciente, puso al descubierto los riesgos de las cadenas de suministro de software no administradas.

Debido a que esta es una preocupación mundial, los gobiernos están actuando. El año pasado, el gobierno del Reino Unido emitió una Propuesta de legislación para “Mejorar la resiliencia cibernética del Reino Unido”, destacando el inmenso impacto que pueden tener incluso los pequeños riesgos de seguridad en la cadena de suministro. Mientras tanto, Alemania emitió la Ley de Seguridad de la Información 2.0 (IT-SiG) y, más recientemente, la Unión Europea (UE) ha propuesto su Ley de Resiliencia Cibernética (volveremos a eso).

Para poner en perspectiva por qué esto es tan importante, el código abierto comprende entre el 80 % y el 90 % del código en todas las aplicaciones modernas. Al menos una cuarta parte de los ataques identificados que se originan en la capa de la aplicación se pueden atribuir a una vulnerabilidad en un componente de código abierto utilizado para construirlo. Desafortunadamente, muchos consumidores comerciales de código abierto no administran su cadena de suministro de software de manera centralizada. De los componentes de código abierto que se descargan y que se sabe que son vulnerables, el 96 % de las veces ha habido una versión mejor y no vulnerable disponible.

Incluso Log4j, el componente que hizo que las aplicaciones fueran vulnerables a Log4shell, estuvo sujeto a un comportamiento similar. El consumo promedio de las versiones vulnerables de Log4j fue del 38 % durante todo 2022. Eso significa que el 38 % de las veces, alguien está descargando e integrando en su software una versión que contiene la vulnerabilidad más publicitada y explotada que jamás hayamos visto.

Más contenido para leer:  JVCKenwood golpeado por el ataque de ransomware Conti

El problema surge de la falta de incentivos para que las corporaciones actúen. El código abierto es una herramienta poderosa que habilita nuestra economía moderna, pero no administrarlo deja a los equipos de desarrollo de software expuestos a deudas técnicas y riesgos de seguridad.

El problema del Reino Unido con la seguridad del software de código abierto

Recientemente vimos a la Oficina Nacional de Auditoría del Reino Unido destacar los peligros. Descubrió que casi un tercio del software utilizado por el Departamento de Medio Ambiente, Alimentos y Asuntos Rurales (Defra) del Reino Unido ya pasó el final de su vida útil y Defra no tiene planes de actualizarlo. Eso significa que el sector público del Reino Unido es vulnerable a los ataques cibernéticos, ya que las miles de piezas de código abierto utilizadas para construirlo se vuelven obsoletas y más vulnerables a los nuevos tipos de vulnerabilidades que se descubren.

Si bien el gobierno del Reino Unido ha tratado de reconocer la importancia de la seguridad de la cadena de suministro digital, la política actual no considera el código abierto como parte de esa cadena de suministro. En cambio, la regulación o las políticas propuestas se enfocan solo en proveedores de software de terceros en el sentido tradicional, pero no reconocen los componentes básicos de todo el software actual y la cadena de suministro detrás de él.

Para enfatizar el punto, la Estrategia Nacional de Seguridad Cibernética del Reino Unido de más de 11,000 palabras no incluye una sola referencia al código abierto. Mientras tanto, la orientación de GCHQ sigue siendo limitada, con poca dirección detallada más allá de “reunir una lista de los componentes de código abierto de su software o preguntar a sus proveedores”.

Hasta que se ponga un énfasis significativo en mejorar las prácticas de código abierto a nivel nacional, es poco probable que el gobierno cumpla con sus objetivos de mejorar la resiliencia cibernética.

¿Está la UE manejando mejor la seguridad del software de código abierto?

En este sentido, la UE ciertamente ha estado escuchando. La Ley de Resiliencia Cibernética (CRA) recientemente publicada es su regulación propuesta para combatir las amenazas que afectan a cualquier entidad digital y ‘reforzar las reglas de seguridad cibernética para garantizar productos de hardware y software más seguros’.

Primero, los aspectos alentadores: la CRA no solo exige que los proveedores y productores de software tengan (entre otras cosas) una Lista de materiales de software (SBoM), sino que exige que las empresas tengan la capacidad de retirar componentes. Esta parte crucial ha estado ausente de las políticas durante mucho tiempo, ya que obliga a las empresas a generar conciencia sobre lo que sucede en su software distribuido.

Se debe exigir a los consumidores comerciales de código abierto que tengan la capacidad de realizar una recuperación específica de partes malas conocidas, tal como esperamos que hagan los fabricantes de bienes físicos, como la industria automotriz. Imagínese si los fabricantes de automóviles tuvieran que imprimir la lista de piezas en el manual de servicio de un automóvil, dejarlo en la guantera y hacer que el propietario del automóvil lo arregle. Eso no funcionaría con nadie, y no deberíamos tratar el software que se ocupa de la infraestructura o los datos críticos de manera diferente.

La CRA incluso intenta eximir al software de fuente abierta de estas regulaciones. Eso es genial: OSS y mantenedores de proyectos debería estar exentos de las normas que aplican la responsabilidad para evitar anular la innovación y el intercambio de ideas. Pero hay un lenguaje problemático con la forma en que la CRA traza una línea entre el uso de OSS comercial y no comercial, lo que podría dañar el futuro del código abierto.

Actualmente, el texto (Página 15, Párrafo 10; Página 43, Párrafo 4) implica que un desarrollador o proveedor que obtenga un beneficio comercial del OSS lo haría sujeto a la CRA. Incluso implica con respecto a la distribución de software que los productores o desarrolladores de código abierto podrían ser considerados responsables si sus proyectos de código abierto se usan comercialmente.

Lo que esto significa para el software de código abierto no está muy claro. ¿Cómo se aplicaría esto a repositorios públicos como PyPi, npm o Maven Central? Son las fuentes de facto donde el mundo consume copias de componentes de código abierto para Python, Javascript y Java, respectivamente. ¿Las organizaciones que proporcionan OSS y obtienen beneficios comerciales de repente querrían asumir una responsabilidad potencialmente ilimitada por el contenido?

Dado que no todas las vulnerabilidades de código abierto se aplican a todos los usos posibles de un componente en particular, es imposible que un repositorio como Central o npm evalúen el impacto de cada vulnerabilidad. Rara vez una vulnerabilidad se aplica a todos los usos de un componente. Obligar a las políticas que alientan a los upstreams a eliminar de manera efectiva un componente para resolver el problema de un usuario podría causar un daño irreparable a otro que lo esté usando de manera perfectamente segura.

La guía de código abierto debe ser clara y existir

La política de seguridad cibernética en toda la legislación europea debe reconocer el OSS, pero la orientación genérica sin pautas específicas y procesables no aumentará significativamente la resiliencia cibernética.

Si la CRA se convierte en ley de la UE sin aclaración, el efecto sobre el OSS podría traer consecuencias devastadoras no deseadas, incluida la balcanización del código abierto que dificulta o imposibilita la colaboración. Podría hacer que los repositorios públicos fueran inaccesibles para la UE, lo que sería desastroso para el ecosistema de software.

Si se mantiene la responsabilidad contra los editores, no es inconcebible que proyectos específicos puedan bloquear a los contribuyentes de los países afectados, evitando que los desarrolladores talentosos contribuyan a los proyectos de OSS. Los proyectos podrían comenzar a cambiar las licencias para excluir específicamente el uso dentro de los productos enviados a la UE.

Aún así, esta legislación proviene de un deseo constructivo de aumentar la postura de seguridad cibernética dentro de los productos digitales de una manera más avanzada que muchas de sus contrapartes. La política actual en los EE. UU., cuya reciente Ley de Seguridad de Código Abierto de 2022 y la orientación de la NSA/CISA, si bien son un paso en la dirección correcta, sigue siendo de un nivel demasiado alto. Cualquier regulación y guía adicional debe seguir la prescripción de GDPR para hacer cumplir los estándares más específicos para la gestión de la cadena de suministro de software, además de los requisitos de certificación para las cadenas de suministro de software de todos los proveedores.

Introducir una política donde no existe supondrá un esfuerzo significativo, pero si eso significa evitar una catástrofe para el código abierto y la industria europea del software, vale la pena.

Ilkka Turunen es CTO de campo en Sonatype

Nuestro objetivo fué el mismo desde 2004, unir personas y ayudarlas en sus acciones online, siempre gratis, eficiente y sobre todo fácil!

¿Donde estamos?

Mendoza, Argentina

Nuestras Redes Sociales