Los servicios públicos, bancos, fabricantes y plataformas cloud dependen de componentes de código abierto. La cuestión no es convertir cada proyecto en una empresa, sino contar con gobernanza, capacidad de mantenimiento y respuesta de seguridad acordes con la importancia que cada organización asigna al software.
A menudo se trata el open source como inventario gratuito: instalar un paquete, escanearlo y asumir que alguien más lo mantendrá. Pero una dependencia puede ser el proyecto personal de una sola persona, una iniciativa de una fundación o un producto con soporte comercial. La licencia permite determinados usos del código; no promete plazos de respuesta, versiones compatibles ni un equipo de seguridad financiado.
En junio de 2026, la Comisión Europea anunció una nueva Estrategia de Open Source dentro del paquete de soberanía tecnológica, con apoyo a soluciones, competencias, infraestructura y reutilización en la administración pública. Es una orientación política, no una garantía de financiación para un mantenedor o biblioteca concreta. Los equipos deben conocer igualmente su exposición y sus obligaciones de contratación.
Las descargas y estrellas son indicadores débiles de importancia operativa. Una pequeña biblioteca criptográfica puede estar en la ruta crítica de miles de productos, mientras una herramienta UI popular podría sustituirse. Construya un grafo a partir de SBOM y evidencia de ejecución; añada criticidad del servicio, superficie de ataque alcanzable, datos tratados, restricciones de actualización, soporte y alternativas. Priorice consecuencias y exposición, no solo el número de CVE.
| Señal | Qué registrar | Por qué importa |
|---|---|---|
| Función operativa | Servicios, productos, límites de seguridad y flujos de datos | Estima el impacto de una caída o compromiso. |
| Mantenimiento | Historial de versiones, ramas soportadas, concentración y respuesta | Indica si las correcciones pueden llegar y adoptarse. |
| Proceso de seguridad | Canal de divulgación, política de parches, procedencia y builds | Reduce incertidumbre al responder a vulnerabilidades. |
| Alternativas | Coste de fork, compatibilidad, reemplazo y migración | Hace recuperable la decisión de dependencia. |
Los mantenedores necesitan tiempo para revisar cambios, clasificar avisos, probar versiones, publicar alertas y cuidar la infraestructura de compilación. El apoyo puede incluir subvenciones recurrentes, contratos de mantenimiento, horas pagadas por empleadores, soporte fiscal de fundaciones, auditorías, builds reproducibles o capacidad compartida de respuesta. El acuerdo debe hacer transparentes las entregas y la gobernanza sin convertir a un patrocinador en autoridad exclusiva de la comunidad.
Las organizaciones dependientes pueden contribuir al proyecto upstream en lugar de acumular parches privados. Un plan práctico puede financiar mantenimiento, resolver errores difíciles, ampliar pruebas, documentar actualizaciones o mantener una rama compatible. Respete la gobernanza del proyecto y no publique datos confidenciales ni detalles de seguridad sin coordinación.
El Cyber Resilience Act de la UE distingue responsabilidades comerciales sobre productos de la actividad de los responsables de stewardship open source; el papel concreto depende de las circunstancias. Evite decir que “todos los mantenedores son fabricantes” o que el código abierto está exento de cualquier obligación. Los fabricantes deben mapear los componentes incorporados, definir el tratamiento de vulnerabilidades, conservar evidencia técnica y evaluar su función con asesoría jurídica cualificada. La licencia pública no traslada las obligaciones del fabricante a colaboradores voluntarios.
La gobernanza requiere contactos de escalado, política de versiones soportadas, expectativas de divulgación y coordinación de parches entre usuarios. En proyectos críticos, una política de seguridad clara y versiones firmadas pueden importar más que una insignia que nadie mantiene.
Los compradores públicos pueden pedir estándares abiertos, datos exportables, disponibilidad del código cuando proceda, opciones de contribución upstream y planes de soporte a largo plazo. Los requisitos deben premiar interoperabilidad y mantenibilidad, sin exigir una licencia concreta sin valorar el contexto. Un contrato puede financiar soporte o mantenimiento compartido, pero debe definir respuesta de seguridad, titularidad de versiones, propiedad intelectual y qué ocurre al terminar la financiación.
Mida resultados verificables: dependencias críticas con responsables, tiempo de corrección, cobertura de versiones, parches aceptados upstream, releases reproducibles, alternativas documentadas y horas de mantenimiento financiadas. Es mejor que contar repositorios o declarar que una organización “usa open source”.
Conectaría la generación de SBOM con la propiedad de servicios y un registro de riesgo de dependencias. Cada componente crítico tendría responsable interno, contacto upstream, estado de soporte, ruta de parches y divulgación, ventana de actualización, alternativa y coste de salida. Una revisión trimestral compararía criticidad con capacidad real y financiación de los mantenedores; compras conocería los riesgos pendientes antes de renovar. Las contribuciones y patrocinios serían parte de la resiliencia, no una métrica de marketing.
Para proyectos apoyados, publicaría el modelo de gobernanza, trabajo financiado, criterios de publicación y gestión de conflictos de interés. Preservaría la independencia de los contribuidores, mantendría confidenciales los avisos de seguridad hasta su divulgación coordinada y no prometería niveles de servicio imposibles para la comunidad.
La sostenibilidad open source es una cuestión operativa: el software crítico necesita capacidad de mantenimiento, seguridad, gobernanza y opciones de recuperación creíbles. El renovado interés político europeo puede ayudar a generar demanda e infraestructura compartida, pero cada organización debe financiar y gestionar las dependencias que utiliza. Mapee el riesgo desde el inventario, contribuya upstream, contrate soporte deliberadamente y mantenga claros los roles legales.
Nota editorial: Este artículo trata de ingeniería de software y no es asesoramiento jurídico. Las obligaciones del CRA dependen del producto y del papel de cada actor; consulte a especialistas para un caso concreto.