En julio de 2026, la Agencia de Ciberseguridad y Seguridad de la Infraestructura de Estados Unidos (CISA) publicó Software de código abierto: principios y prácticas de seguridad, un documento de orientación de 31 páginas dirigido a las agencias civiles federales estadounidenses. Es de acceso gratuito y tiene la clasificación TLP:CLEAR, lo que significa que puede compartirse sin restricciones.
La guía responde a obligaciones establecidas en dos órdenes ejecutivas sobre ciberseguridad federal y abarca cuatro áreas: el uso de soluciones de código abierto, la contribución a proyectos de código abierto, la producción de software de código abierto y la evaluación de modelos de inteligencia artificial de código abierto. Aunque está pensada para las administraciones de Estados Unidos, su contenido analítico no depende de ninguna jurisdicción concreta, por lo que también resulta útil para administraciones públicas de otros lugares, incluida Europa.
Qué dice la guía
La idea central es más matizada de lo que podría parecer a primera vista: la CISA no afirma que el código abierto sea más seguro que el software propietario, sino que «no es ni más ni menos arriesgado que cualquier otro software». La diferencia, según el documento, está en otro punto: con el código abierto una organización puede evaluar directamente la calidad y la seguridad del código, en lugar de depender únicamente de las garantías de un proveedor. Es decir, cuando se evalúa software propietario se evalúa lo que el fabricante afirma sobre su propio producto; cuando se evalúa código abierto, se evalúa el producto en sí.
La guía también señala que los estándares abiertos y el código modificable reducen la dependencia de un único proveedor, protegiendo a las administraciones de las llamadas «trampas» de la dependencia del software propietario.
El marco C4 para evaluar la confianza
La parte más práctica del documento es su Apéndice A, donde se presenta el Marco C4, diseñado para evaluar si se puede confiar en un proyecto de código abierto. Parte de la idea de que, como las personas colaboradoras pueden ser pseudónimas y no tienen ninguna obligación formal de ofrecer soporte, la fiabilidad no puede juzgarse por quién creó el software, sino por cómo se desarrolló, algo que el desarrollo abierto hace visible y el cerrado no.
El marco agrupa las evidencias en cuatro categorías:
- Código fuente: frecuencia de las contribuciones, vulnerabilidades conocidas y actualización de las dependencias.
- Comunidad: número de mantenedores, estructura institucional y si el proyecto forma parte de una fundación.
- Conducta: si existe una política de divulgación de vulnerabilidades, si se exige revisión del código, si los mantenedores fusionan sus propias contribuciones, la licencia y el código de conducta.
- Configuración: si los valores predeterminados son seguros y qué medidas de refuerzo de la seguridad admite el software.
Se aplica en cinco pasos: identificar criterios medibles, determinar la tolerancia al riesgo y ponderar los criterios, recopilar observaciones —con herramientas automatizadas cuando sea posible—, evaluar cada criterio y comparar el resultado con la tolerancia definida.
El artículo original anima a las administraciones públicas a aplicar este marco a LibreOffice, señalando que cada categoría puede responderse con evidencias públicas: un historial continuo de commits desde 2010, una política de seguridad y un proceso de divulgación publicados, revisión por pares obligatoria, una licencia aprobada por la OSI, un código de conducta documentado y una estructura de gobierno —The Document Foundation, una fundación alemana con una Junta Directiva elegida— que es un hecho público y no una simple afirmación. También anima a aplicar el mismo marco a cualquier otra solución candidata, incluidas las propietarias, señalando qué preguntas pueden responderse y cuáles no.
¿Quién corrige los problemas?
La guía también responde a una duda muy frecuente entre las administraciones públicas: quién es responsable de las correcciones en el código abierto. La respuesta de la CISA es clara: ninguna entidad concreta está obligada a proporcionarlas, por lo que las agencias deben planificarse en consecuencia —con personal propio, contratando a terceros o mediante una combinación de ambas opciones— siguiendo dos principios: colaborar en lugar de exigir y enviar las correcciones a los desarrolladores originales del proyecto.
Esto refleja cómo funciona en la práctica el ecosistema de LibreOffice, donde las correcciones, el mantenimiento a largo plazo y el desarrollo a medida los proporcionan desarrolladores y profesionales de migración certificados, cuyas contribuciones se incorporan a la base de código compartida y benefician a todas las demás implantaciones.
La CISA añade que, si un proyecto deja de recibir mantenimiento, una organización puede, como último recurso, hacerse cargo de una bifurcación (fork) propia. Esta posibilidad no existe en el software propietario, donde el fin de las correcciones llega cuando lo decide el proveedor, sin ningún remedio posible.
El documento no menciona ningún producto concreto: la CISA afirma expresamente que no respalda entidades comerciales, productos ni servicios, y que nada de lo que contiene la guía debe interpretarse como una evaluación de un software en particular. Lo que ofrece son criterios; que LibreOffice los cumpla es una interpretación del blog original, basada en evidencias que cualquiera puede comprobar.
Fuente: La CISA publica una guía sobre seguridad del código abierto: la verificabilidad marca la diferencia
