El 30 de julio de 2026, la Agencia de Ciberseguridad y Seguridad de la Infraestructura de los Estados Unidos 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. Está disponible de forma gratuita y tiene la clasificación TLP:CLEAR, lo que significa que puede compartirse sin restricciones.
El documento está dirigido a las agencias federales de EE. UU. y cumple con las obligaciones establecidas en dos órdenes ejecutivas sobre ciberseguridad federal. 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. Las observaciones que siguen se refieren a las tres primeras.
Su contenido analítico no es específico de ninguna jurisdicción, y las administraciones públicas de otros lugares -incluida Europa- encontrarán que articula, en el lenguaje de la gestión de riesgos, varias posiciones que la comunidad de código abierto ha estado defendiendo durante dos décadas.
Lo que realmente dice la guía
La afirmación central es más precisa de lo que sugieren los titulares. La CISA no afirma que el software de código abierto sea más seguro que el software privativo. Afirma que el software de código abierto «no es ni más ni menos riesgoso que cualquier otro software», y sitúa la diferencia en otro lugar: 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 del proveedor.
Esta es una afirmación sobre la verificabilidad, no sobre las tasas de defectos. También es la afirmación más defendible y la que tiene mayores consecuencias para las adquisiciones. Una agencia que evalúa software privativo está evaluando la declaración de un proveedor sobre su propio producto. Una agencia que evalúa software de código abierto está evaluando el producto.
La guía saca esta conclusión de manera explícita. Entre los beneficios que enumera para las agencias federales se encuentra la reducción de la dependencia de un proveedor específico: los estándares abiertos y el código modificable, señala la CISA, protegen a las agencias de las «trampas de la dependencia de software privativo». Una autoridad nacional de ciberseguridad ha incluido la dependencia de un proveedor específico en un documento de seguridad en lugar de uno de política de competencia. Ese es un cambio significativo en el ámbito en el que se permite plantear este argumento.
El Marco C4
La parte más útil en la práctica de la guía es el Apéndice A, que establece el Marco C4 para evaluar si un proyecto de código abierto es confiable. Su premisa es que, dado que los colaboradores pueden ser seudónimos y no están sujetos a ninguna obligación de entrega, la confiabilidad no puede evaluarse en función de quién produjo el software. Debe evaluarse en función de cómo se produjo el software -algo que el desarrollo de código abierto hace visible de una manera que el desarrollo cerrado no permite-.
El C4 agrupa la evidencia en cuatro categorías:
- Código fuente: frecuencia de las contribuciones, vulnerabilidades conocidas, actualización de las dependencias.
- Comunidad: número de mantenedores, estructura institucional, si el proyecto forma parte de una fundación.
- Conducta: si existe una política de divulgación de vulnerabilidades, si se requiere la 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 seguridad admite el software.
El marco se aplica en cinco pasos: identificar criterios medibles, determinar la tolerancia al riesgo y ponderar los criterios, recopilar observaciones (con herramientas automatizadas cuando estén disponibles), evaluar según cada criterio y comparar el resultado con la tolerancia.
Alentamos a las administraciones públicas a aplicar este marco a LibreOffice. Cada categoría puede responderse a partir de evidencia pública: 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 gobernanza -The Document Foundation, una Stiftung alemana con una Junta Directiva elegida- que es un hecho de dominio público y no una mera afirmación.
Alentamos a las administraciones a aplicar el mismo marco a todas las soluciones candidatas, incluidas las propietarias, y a señalar qué preguntas pueden responderse y cuáles no.
La contribución y la cuestión de las correcciones
La guía también aborda una pregunta que las administraciones públicas plantean con frecuencia sobre la adopción del código abierto: quién es responsable de las correcciones. La respuesta de la CISA es que ninguna entidad en particular está obligada a proporcionarlas y que, por lo tanto, las agencias deben planificarse en consecuencia -asignando personal interno, contratando a terceros o ambas cosas- mientras siguen dos principios al tratar con proyectos de código abierto: colaborar en lugar de exigir, y enviar las correcciones a los desarrolladores originales.
Esta es una descripción acertada de cómo funciona el ecosistema de LibreOffice. Las correcciones, el mantenimiento a largo plazo y el desarrollo personalizado son proporcionados por desarrolladores certificados y profesionales de migración certificados, cuyas contribuciones se incorporan al código base compartido y benefician a todas las demás implementaciones. La guía tiene razón al señalar que esto requiere que las organizaciones lo planifiquen. También es cierto que las mejoras resultantes se comparten en lugar de ser acaparadas.
La CISA señala además que, cuando un proyecto deja de recibir mantenimiento, una organización puede, como último recurso, hacerse cargo de una bifurcación. Esta opción no tiene equivalente en el software privativo, donde el fin de las correcciones llega según el calendario del proveedor y no ofrece ningún remedio en absoluto.
Nota sobre el alcance
El documento no menciona ningún producto en concreto. La CISA afirma explícitamente que no respalda a entidades comerciales, productos ni servicios, y que nada de lo que figura en la guía debe interpretarse como una evaluación de ningún software en particular. Lo que ofrece es un conjunto de criterios. La observación de que LibreOffice los cumple es nuestra y se basa en evidencia que cualquiera puede verificar.
El documento Software de código abierto: principios y prácticas de seguridad está disponible en la página de la CISA: https://www.cisa.gov/resources-tools/resources/open-source-software-security-principles-and-practices
Anuncio de la CISA: https://www.cisa.gov/news-events/news/cisa-guide-helps-federal-agencies-securely-and-effectively-use-open-source-software
Artículo original (en inglés)
