Barry O’Donovan: el papel CRA depende del producto

Resumen

La CRA se fija en cómo se suministra y se mantiene un producto concreto. Barry O’Donovan sostiene que una organización puede ser administradora de comunidad de software de código abierto (open-source software steward en el texto del CRA) para la edición gratuita y fabricante para la versión de pago.
La etiqueta de entidad sin fines de lucro no resuelve la clasificación. Los operadores aún necesitan un inventario por producto, un contacto para vulnerabilidades y una ruta de parches.

Un mismo proyecto puede publicar código abierto gratuito y vender una edición ampliada. La CRA puede asignarles papeles distintos. Esa es la lectura operativa de Barry O’Donovan: la categoría sigue al producto, no al nombre de la organización.

O’Donovan, desarrollador principal de IXP Manager en INEX, planteó la distinción en RIPE 93 durante una charla sobre cadenas de suministro de software. Su pregunta para los operadores fue concreta: cuando un punto de intercambio o una red depende de software abierto, ¿qué trabajo de seguridad puede exigir al proyecto que lo mantiene?

La guía actual de la Comisión Europea separa dos funciones. El fabricante que introduce un producto abierto en el mercado tiene las obligaciones de fabricante. Una persona jurídica que no lo introduce en el mercado, pero respalda de forma sistemática y sostenida un producto abierto específico destinado a actividades comerciales, puede encajar como administradora de comunidad de software de código abierto. Esa función exige una política de ciberseguridad, gestión de vulnerabilidades y cooperación con las autoridades de vigilancia del mercado.

O’Donovan usó el caso habitual de un proyecto que ofrece gratis la versión abierta y cobra por una versión con funciones extra. En su explicación, la organización puede ser administradora de comunidad de software de código abierto de la primera y fabricante de la segunda. La Comisión también formula la categoría alrededor de productos concretos y de cómo se suministran. Es una unidad de análisis más precisa que pegar una sola etiqueta CRA a una fundación, una empresa o un equipo de desarrollo.

La ley también frena conclusiones rápidas. Recibir dinero de empresas, aceptar contribuciones o publicar versiones con regularidad no convierte por sí solo el software en una actividad comercial. El Reglamento añade que el desarrollo de software libre por una entidad sin fines de lucro no se considera comercial cuando los ingresos, después de costes, se destinan a sus fines no lucrativos. Hay que mirar conjuntamente el precio, quién responde por el producto, el apoyo sostenido y el uso comercial previsto.

O’Donovan puso IXP Manager como ejemplo. Dijo que INEX considera que el proyecto encaja en la categoría de administradora de comunidad de software de código abierto y que publicó políticas de desarrollo seguro y divulgación de vulnerabilidades después de que otros intercambios pidieran pruebas para sus revisiones de cadena de suministro. También señaló que INEX es una entidad sin fines de lucro que cobra por los puertos de intercambio. Esa es su lectura operativa, no una decisión de la autoridad sobre IXP Manager. La regla pública sigue dependiendo del producto y del papel real de la organización.

Para los operadores sujetos a NIS2, la etiqueta del proveedor no sustituye su propio control de la cadena. El artículo 21 incluye seguridad de proveedores y mantenimiento, además del tratamiento y la divulgación de vulnerabilidades. O’Donovan recomendó un inventario de software, seguimiento de fallos y una política de parches oportunos.

En las preguntas, anticipó que los casos fáciles quedarían claros y que la zona gris acabaría en los tribunales. Por cada dependencia, el operador necesita saber quién controla las versiones, quién recibe los informes, quién puede publicar una corrección y qué edición está utilizando. Si cambia el modelo comercial, puede cambiar el papel legal del producto. Un inventario que solo guarda el nombre de la organización no detectará el cambio.