En xullo de 2026, a Axencia de Ciberseguridade e Seguridade da Infraestrutura dos Estados Unidos (CISA) publicou Software de código aberto: principios e prácticas de seguridade, un documento de orientación de 31 páxinas dirixido ás axencias civís federais estadounidenses. É de acceso gratuíto e ten clasificación TLP:CLEAR, o que significa que se pode compartir sen restricións.
A guía responde a obrigas fixadas en dúas ordes executivas sobre ciberseguridade federal e abrangue catro áreas: o uso de solucións de código aberto, a contribución a proxectos de código aberto, a produción de software de código aberto e a avaliación de modelos de intelixencia artificial de código aberto. Aínda que está pensada para as administracións dos EE. UU., o seu contido analítico non depende de ningunha xurisdición concreta, polo que resulta igualmente útil para administracións públicas doutros lugares, incluída Europa.
Que di a guía
A idea central é máis matizada do que poida parecer a primeira vista: a CISA non afirma que o código aberto sexa máis seguro co software privativo, senón que “non é nin máis nin menos arriscado ca calquera outro software”. A diferenza, segundo o documento, está noutro sitio: co código aberto unha organización pode avaliar directamente a calidade e a seguridade do código, en vez de depender só das garantías dun provedor. É dicir, cando se avalía software privativo avalíase o que di o fabricante do seu propio produto; cando se avalía código aberto, avalíase o produto en si.
A guía tamén sinala que os estándares abertos e o código modificable reducen a dependencia dun único provedor, protexendo as administracións das chamadas “trampas” da dependencia do software privativo.
O marco C4 para avaliar a confianza
A parte máis práctica do documento é o seu Apéndice A, onde se presenta o Marco C4, deseñado para avaliar se se pode confiar nun proxecto de código aberto. Parte da idea de que, como as persoas colaboradoras poden ser pseudónimas e non teñen ningunha obriga formal de entrega, a confiabilidade non se pode xulgar por quen fixo o software, senón por como se fixo, algo que o desenvolvemento aberto fai visible e o pechado non.
O marco agrupa a evidencia en catro categorías:
- Código fonte: frecuencia das contribucións, vulnerabilidades coñecidas, actualización das dependencias.
- Comunidade: número de mantedores, estrutura institucional, se o proxecto forma parte dunha fundación.
- Conduta: se existe unha política de divulgación de vulnerabilidades, se se esixe revisión do código, se os mantedores fusionan as súas propias achegas, a licenza e o código de conduta.
- Configuración: se os valores por defecto son seguros e que medidas de reforzo de seguridade admite o software.
Aplícase en cinco pasos: identificar criterios medibles, determinar a tolerancia ao risco e ponderar os criterios, recoller observacións (con ferramentas automatizadas cando sexa posible), avaliar segundo cada criterio e comparar o resultado coa tolerancia definida.
O artigo orixinal anima as administracións públicas a aplicar este marco a LibreOffice, sinalando que cada categoría pode responderse con evidencia pública: un historial continuo de commits dende 2010, unha política de seguridade e un proceso de divulgación publicados, revisión por pares obrigatoria, unha licenza aprobada pola OSI, un código de conduta documentado e unha estrutura de goberno -The Document Foundation, unha fundación alemá cunha Xunta Directiva elixida- que é un feito público e non unha simple afirmación. Anímase tamén a aplicar o mesmo marco a calquera outra solución candidata, incluídas as privativas, sinalando que preguntas se poden responder e cales non.
Quen arranxa os problemas?
A guía tamén responde a unha dúbida moi frecuente entre as administracións públicas: quen é responsable das correccións no código aberto. A resposta da CISA é clara: ningunha entidade concreta está obrigada a fornecelas, polo que as axencias deben planificarse en consecuencia -con persoal propio, contratando terceiros, ou ambas- seguindo dous principios: colaborar en vez de esixir, e enviar as correccións aos desenvolvedores orixinais do proxecto.
Isto reflicte como funciona na práctica o ecosistema de LibreOffice, onde as correccións, o mantemento a longo prazo e o desenvolvemento a medida os fornecen desenvolvedores e profesionais de migración certificados, cuxas achegas se incorporan á base de código compartida e benefician todas as demais implantacións.
A CISA engade que, se un proxecto deixa de recibir mantemento, unha organización pode, como último recurso, facerse cargo dunha bifurcación (fork) propia. Esta posibilidade non existe no software privativo, onde o fin das correccións chega cando o decide o provedor, sen ningún remedio posible.
O documento non menciona ningún produto concreto: a CISA afirma expresamente que non respalda entidades comerciais, produtos nin servizos, e que nada do que contén a guía debe interpretarse como unha avaliación dun software en particular. O que ofrece son criterios; que LibreOffice os cumpra é unha lectura do blog orixinal, baseada en evidencias que calquera pode comprobar.
Fonte: La CISA publica una guía sobre seguridad del código abierto: la verificabilidad marca la diferencia
