Guillem Alsina Gonzàlez
La Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos (CISA) hizo público el pasado 30 de julio, un documento con recomendaciones para que las agencias federales empleen de forma segura el software de código abierto (OSS), el cual también puede ser de utilidad para cualquier otra organización —incluídas las empresas— que quieran dibujar una política de adopción y uso de este tipo de software.
El texto reúne pautas para evaluar la seguridad de estos componentes, aplicar parches e incluso contribuir a los proyectos comunitarios. Su principio de partida es que el código abierto no resulta ni más ni menos seguro que cualquier otro software cerrado, aunque obliga a adaptar las prácticas habituales de gestión de riesgos.
El punto de partida del documento es que el software actual rara vez se construye desde cero. La mayoría de los programas se ensamblan a partir de componentes ya existentes, y buena parte de esas piezas son de código abierto, es decir, programas cuyo código fuente puede consultarse, usarse, modificarse y distribuirse con libertad gracias a licencias permisivas.
Entre las ventajas que atribuye al código abierto figuran la posibilidad de inspeccionar directamente el código —lo que permite verificar sus propiedades de seguridad sin depender de las garantías del proveedor—, una menor dependencia de un único fabricante, y el ahorro de costes al no existir cuotas de licencia.
Esas mismas características conllevan, sin embargo, una contrapartida. En el modelo propietario, el fabricante desarrolla y distribuye los parches de seguridad, de manera que las modificaciones circulan en un solo sentido, del productor al consumidor. En el código abierto no existe una entidad obligada a publicar mejoras o correcciones, ya que quienes mantienen un proyecto no tienen el deber de proporcionar actualizaciones. Por ello, la responsabilidad de mantener al día las dependencias recae en quien utiliza el software, que deberá asignar personal propio o contratar a terceros para esa tarea.
Para decidir si un componente de código abierto es de fiar, la guía aconseja examinar cómo se ha producido el software y no quién lo ha producido, dado que muchos participantes en estas comunidades actúan anónimamente o bajo seudónimo. Con ese fin describe el denominado Marco C4, que agrupa los criterios de evaluación en cuatro categorías: el código base y sus dependencias, la comunidad que mantiene el proyecto, la conducta esperada y observada de sus integrantes, y la configuración con la que se despliega el componente. El documento insiste en que ningún dato aislado basta para juzgar un proyecto y en que conviene apoyarse en herramientas automatizadas que extraigan información de los metadatos.
La agencia también recomienda una vigilancia continua, inventariando los componentes de código abierto igual que el resto del software y recurriendo a los listados de materiales de software (SBOM), que permiten conocer no solo las piezas desplegadas, sino también sus dependencias. Como recordatorio de por qué importa esta trazabilidad, cita dos incidentes conocidos: la vulnerabilidad Log4Shell, detectada en 2021, y la puerta trasera introducida en la utilidad xz en 2024.
En materia de parcheo, el documento plantea dos criterios: colaborar en lugar de exigir, y enviar las correcciones “aguas arriba”, esto es, remitirlas al proyecto original para que queden a disposición de todos. Cuando una entidad detecta una vulnerabilidad sin identificador CVE, debe seguir los procedimientos de divulgación coordinada; si el proyecto no responde, esa falta de reacción ha de interpretarse como una posible señal de fin de soporte y motivar la sustitución del componente.
Cautela ante los modelos de IA de código abierto
El texto dedica una atención destacada al efecto de la inteligencia artificial, ya que durante 2026 la automatización más avanzada, incluidos los modelos de frontera, ha elevado notablemente tanto el número de vulnerabilidades descubiertas como la velocidad a la que se desarrollan los parches. Ante ese escenario, CISA aconseja automatizar la gestión de dependencias y de parches e integrarla en los flujos de integración y entrega continuas.
La parte quizá más contundente del documento aborda los sistemas de inteligencia artificial que se presentan como de código abierto, advirtiendo que las licencias abiertas para IA no exigen el mismo grado de transparencia que las del software convencional. En concreto, la Open Source Initiative, organización que mantiene el listado de licencias reconocidas, no requiere que los datos de entrenamiento de un modelo sean accesibles para que su licencia se considere abierta.
La guía publicada por la CISA sostiene que, sin acceso a esos datos, no es posible evaluar de manera adecuada la fiabilidad del modelo, explicando que los archivos de un modelo pueden corromperse para eludir a los escáneres, que los pesos pueden manipularse para alterar su comportamiento, y que los conjuntos de datos pueden envenenarse. También menciona investigaciones según las cuales es factible insertar una puerta trasera manipulando los datos de entrenamiento, un ataque a la cadena de suministro específico de la IA que resulta imposible detectar sin acceso a dichos datos.
La conclusión que traslada la agencia es directa: cualquier modelo de IA que no facilite el acceso a sus datos y a su cadena de entrenamiento debería tratarse como si no fuera de código abierto y gestionarse, en la práctica, como software propietario con una procedencia incompleta.
Junto a las pautas de consumo, la guía anima a las administraciones a producir también software abierto, para la cual cosa propone un enfoque de “código abierto por defecto” que traslada al inicio del proyecto la decisión sobre su publicación y obliga a justificar por qué un código no debería abrirse, en vez de justificar por qué sí. Con esta fórmula, la agencia busca abaratar la publicación, mejorar la calidad del código y evitar que distintas administraciones dupliquen desarrollos ya realizados.
