El CRA y el open source: en qué papel queda su proyecto

El CRA y el open source, en cuatro hechos

1. El software libre y de código abierto suministrado fuera de una actividad comercial queda fuera del ámbito. Un proyecto mantenido sin contraprestación, publicado para quien quiera usarlo, no se «comercializa» en el sentido del reglamento, porque falta la actividad comercial (artículo 2, apartado 1, y artículo 3, punto 22), y por eso no se le aplican las obligaciones de fabricante.
2. «Gratis» no significa «no comercial». Vender soporte por encima del coste real, una edición enterprise o monetizar los datos del software es actividad comercial, y a partir de ahí el proyecto pasa a ser producto, con un fabricante responsable. El artículo 07 dibuja la frontera con ejemplos.
3. Las personas jurídicas que dan soporte de forma sistemática y sostenida a programas libres y de código abierto destinados a actividades comerciales, como ciertas fundaciones, tienen un régimen propio, más ligero. El reglamento los llama «administradores de comunidad de programas informáticos de código abierto» (artículo 24): política de ciberseguridad y cooperación con las autoridades de vigilancia del mercado. La notificación de vulnerabilidades aprovechadas activamente solo se les aplica en la medida en que participen en el desarrollo, y la de incidentes graves solo cuando estos afecten a las redes y sistemas de información que proporcionan para ese desarrollo (artículo 24, apartado 3). No hay marcado CE ni evaluación de la conformidad. Estas obligaciones solo se aplican a partir del 11 de diciembre de 2027 (artículo 71, apartado 2); la notificación de los fabricantes se aplica desde el 11 de septiembre de 2026.
4. Quien integra open source en un producto responde por él. El fabricante que mete una biblioteca en el firmware tiene que inventariarla en la SBOM, seguir sus vulnerabilidades y corregirlas en el producto. Las obligaciones de fabricante no suben hasta quien mantiene la biblioteca fuera de una actividad comercial; se quedan con quien la vende dentro de un producto. Aun así, el fabricante tiene deberes con quien mantiene el componente: si detecta en él una vulnerabilidad, tiene que comunicarla a esa persona o entidad y, si desarrolla una corrección, compartir con ella el código o la documentación (artículo 13, apartado 6, aplicable a partir del 11 de diciembre de 2027). Si la biblioteca es en sí un producto comercial, quien la fabrica tiene obligaciones propias, que no eximen al integrador de las suyas. El artículo 09 aplica esto a un caso concreto: los fallos de PHP y Node.js, dos proyectos open source, corregidos el 21 de octubre de 2026.

Cómo este sitio practica lo que dice

El código de este sitio es público. Publicamos un security.txt con clave PGP para informes de vulnerabilidades, montado como describimos en el artículo 08. La política de seguridad de contenido cierra el sitio a su propio dominio, y no hay analítica ni cookies. Nuestro producto, Aeromate, tiene una edición Community abierta, y su preparación para el CRA está documentada en público en el diario de a bordo, fallos incluidos.

Qué hacemos, en tres líneas

Seguridad de producto y preparación para el CRA, del prototipo al producto vendible. Evaluaciones ofensivas: pentest whitebox de firmware y sistema, modelado de amenazas e intrusión física en instalaciones, siempre con ámbito y autorización por escrito. Y Aeromate, que pasa por el mismo filtro que aconsejamos. El detalle está en servicios.

Primera lectura para proyectos, sin coste

Descríbanos el proyecto o el producto por email, qué es, cómo se distribuye, si hay dinero de por medio y cómo, y en cinco días laborables devolvemos una nota escrita, de dos páginas, con tres cosas: si el CRA le alcanza y en qué papel (fabricante, administrador de código abierto o fuera de ámbito), las fechas que se aplican, y las tres decisiones más urgentes. Sin llamada, sin reunión y sin seguimiento comercial, salvo que lo pida.

Para que quede claro desde el principio. La lectura se basa únicamente en la información que nos envíe. No es una auditoría, no es un dictamen jurídico y no es una evaluación de la conformidad. No envíe código, credenciales ni documentación confidencial; con una descripción funcional y el modelo de distribución basta.

Para pedirla: oi@folhas.io con el asunto "Primera lectura (open source)".

No medimos visitas. Si viene del podcast, dígalo en el email: es la única forma de que lo sepamos.