El código abierto no es un límite de seguridad

El 14 de mayo de 2026, el UK Government Digital Service publicó una guía sobre IA, código abierto y riesgo de vulnerabilidades en el sector público. La guía responde la pregunta correcta: la IA puede abaratar la detección de vulnerabilidades, pero la privacidad de un repositorio sigue sin convertirse en un límite de seguridad.¹

Nueve días antes, un reporte público dijo que NHS England planeaba convertir en privados cientos de repositorios de GitHub tras una preocupación interna: que las herramientas de vulnerabilidades con IA pudieran inspeccionar código público a gran escala.² La ansiedad se entiende. El control propuesto, no. Ocultar código trata el descubrimiento como la amenaza. El trabajo serio de seguridad trata la debilidad sin corregir como la amenaza.

La seguridad de código abierto mejora cuando los equipos reducen la exposición real: sin secretos en el código, excepciones claras, repositorios con dueño, vías de divulgación que funcionen, parches rápidos y evidencia pública de que las correcciones llegaron a los usuarios. La privacidad del repositorio puede respaldar una excepción específica, pero no puede reemplazar ese modelo operativo.

Resumen

GDS dice que los equipos del sector público deberían mantener el código abierto por defecto, revisar las excepciones de forma deliberada y concentrarse en los factores prácticos que cambian el riesgo real.¹ Esa respuesta es mejor que el pánico por la privacidad de los repositorios, porque el código público quizá ya exista en forks, espejos, cachés, artefactos de paquetes, imágenes de contenedores, capturas de pantalla, clientes generados y clones previos. Más importante aún: el código público permite que más personas lo inspeccionen, reutilicen, reporten problemas y lo mejoren.¹³

La respuesta correcta ante la detección de vulnerabilidades con IA no es “hacer todo privado”. La respuesta correcta es: eliminar secretos, clasificar el código sensible, publicar excepciones claras, ejecutar análisis de dependencias y secretos, mantener una vía de divulgación de vulnerabilidades, parchear rápido y conservar evidencia de que el código abierto tiene un responsable.¹⁴⁵

Puntos clave

• Para líderes de ingeniería: la privacidad puede reducir la exposición en casos acotados, pero no reemplaza la propiedad, el inventario, los parches ni la divulgación.
• Para equipos del sector público: abrir por defecto sigue funcionando cuando se acompaña de excepciones explícitas para secretos, controles antifraude, arquitectura sensible y políticas no publicadas.
• Para equipos de seguridad: la IA aumenta el valor de la capacidad de respuesta. Un repositorio privado sin ruta de triaje sigue fallando.
• Para equipos de agentes: la visibilidad del código es solo una superficie de ataque. Los permisos de herramientas, los límites de estado, los controles de salida y los umbrales de publicación importan más que la apariencia privada de un repositorio.
• Para mantenedores: publiquen menos misterios. Buena documentación, puntos de contacto de seguridad claros y servicios pequeños con responsables definidos reducen más el riesgo que una pared de repositorios privados.

El pánico confunde visibilidad con vulnerabilidad

Los escáneres de vulnerabilidades con IA cambian la economía de la inspección. Antes, una persona necesitaba tiempo, habilidad y paciencia para revisar una base de código. Un modelo capaz puede inspeccionar más código con mayor rapidez, conectar pistas entre archivos y producir más hallazgos candidatos. Ese cambio aumenta la presión sobre equipos que ya tenían código frágil, propiedad difusa y rutas lentas para aplicar parches.

Aun así, la visibilidad del repositorio no equivale a vulnerabilidad. El código público puede revelar un error. El código privado puede contener el mismo error. Un atacante muchas veces puede inferir comportamientos a partir de binarios, tráfico de API, paquetes de cliente, contenido de paquetes, capas de contenedores, registros, documentación, metadatos de dependencias o un clon antiguo. GDS plantea el mismo punto práctico: convertir en privado un repositorio que antes era público quizá no quite el acceso a adversarios capaces, porque los proyectos populares suelen tener forks o espejos, e incluso los repositorios de bajo perfil pueden haber llegado ya a investigadores o atacantes.¹

Ese matiz importa porque “ciérralo” se siente como acción. Pero esa acción puede reducir la rendición de cuentas pública y dejar intacta la debilidad técnica. Los equipos pueden perder revisión externa, correcciones compartidas y reutilización, mientras ganan poca protección contra cualquiera que ya haya copiado el código.

El código abierto también crea una traza de auditoría. El historial público muestra quién cambió qué, cuándo llegó una corrección, cómo respondieron los mantenedores a un reporte y si un proyecto sigue recibiendo atención activa. El código privado oculta esas señales a equipos pares, proveedores, investigadores y otros organismos públicos que podrían reutilizar o mejorar el trabajo.

Abrir por defecto no es ingenuo

GDS no sostiene que cada línea de código deba estar en internet. La guía anterior de GOV.UK sobre código abierto ya nombra razones legítimas para mantener código cerrado, entre ellas llaves, credenciales, algoritmos de detección de fraude y políticas no publicadas.³ El Technology Code of Practice también vincula la apertura con obligaciones de seguridad y privacidad, no las enfrenta.⁴

La regla más fuerte es abrir por defecto con excepciones específicas. Esa forma de política obliga al equipo a nombrar el riesgo en vez de usar “seguridad” como categoría general. Un secreto no pertenece a un repositorio. Una señal antifraude puede necesitar visibilidad restringida. Un servicio de política aún no publicada puede necesitar una retención temporal. Una base de código que solo se siente vergonzosa no califica.

El manual del sector público del Reino Unido apunta en la misma dirección. Describe la expectativa de que el software y el código del gobierno sean de código abierto por defecto, se desarrollen de forma abierta y se publiquen bajo una licencia aprobada cuando corresponda.⁵ La política de publicación de código abierto de DWP sigue el mismo patrón: fomenta la publicación bajo licencias abiertas mientras protege el código fuente sensible mediante controles definidos.⁶

Esa distinción protege la calidad. Los equipos que programan en abierto tienden a escribir mejores README, instrucciones de configuración más limpias, historiales de issues más claros y límites de datos más explícitos, porque saben que personas externas pueden leer el trabajo. La guía de GOV.UK dice que publicar código puede mejorar la documentación, el mantenimiento, la claridad sobre datos y la retroalimentación de seguridad.³ Esos beneficios desaparecen cuando un equipo responde a la presión de la IA enterrándolo todo.

El verdadero control es la velocidad de corrección

La IA cambia el reloj. El descubrimiento se acelera. Aumenta el volumen de reportes. También aumentan los falsos positivos. Escribí sobre la misma presión de capacidad en Cuando tu agente encuentra una vulnerabilidad: descubrir sirve de poco sin verificación y reparación. Los equipos necesitan triaje, enrutamiento al responsable, parches, divulgación y evidencia de publicación. La privacidad del repositorio no entrega nada de eso.

La plataforma de Vulnerability Disclosure Policy de CISA existe por esa razón. La plataforma da a las agencias civiles federales un canal para recibir, triar y enrutar vulnerabilidades reportadas por investigadores públicos de seguridad.⁷ El programa de divulgación coordinada de vulnerabilidades de CISA también cubre vulnerabilidades en infraestructura crítica, incluido software de código abierto y sistemas de IA, y enfatiza la coordinación de mitigaciones antes de la divulgación pública.⁸

NCSC ofrece a las organizaciones del Reino Unido el mismo marco operativo mediante su guía de reporte y divulgación de vulnerabilidades, incluido un conjunto de herramientas y una ruta ya preparada para departamentos gubernamentales.⁹ El hilo común es simple: acepta que personas externas encontrarán errores y haz que el reporte y la corrección funcionen.

Ese marco convierte la detección de vulnerabilidades con IA de una razón para ocultar en una razón para mejorar el ciclo de respuesta. Si un modelo puede encontrar un error en tu código público, el equipo debería hacerse cinco preguntas:

Esas respuestas reducen el riesgo tanto si el código está abierto como si está cerrado. Ocultar el repositorio solo cambia quién puede ver el código fuente hoy. No crea un responsable, un parche ni una vía de divulgación.

Una mejor regla de decisión

Los equipos necesitan una regla de decisión que separe vergüenza, exposición y sensibilidad real.

La regla también evita una falla común: cerrar todo porque el equipo no puede clasificar nada. Un inventario de repositorios debería responder qué hace el servicio, qué datos toca, quién lo posee, qué escáneres de secretos se ejecutan, qué dependencias importan y cómo llegan los reportes a los mantenedores. Si el equipo no tiene esas respuestas, tiene una brecha operativa. Cambiar la visibilidad del repositorio puede ocultar esa brecha al público, pero la brecha permanece.

Los agentes agrandan el problema del límite

Los agentes de programación con IA hacen que la misma lección sea más evidente. Un límite de repositorio no impide que un agente tome una decisión insegura dentro de los permisos concedidos. Escribí sobre ese patrón en La seguridad del entorno aislado de tu agente es una sugerencia: las acciones peligrosas suelen ocurrir dentro del conjunto de permisos, no fuera de él. El mismo problema de composición impulsa los ataques a la cadena de suministro de software, donde piezas individualmente razonables se combinan en una ruta dañina.

El problema del agente invisible también aplica a la política de código abierto. Los equipos no pueden gobernar lo que no ven: rutas de herramientas, artefactos generados, cachés, estado de publicación, colas de divulgación y traspasos de propiedad importan.

La política de código abierto debería aprender de la seguridad de agentes. Los límites útiles viven en las capas de acción y respuesta:

• clasificar la entrada no confiable antes de que las herramientas la toquen;
• eliminar secretos del código, el historial, los registros, los paquetes y los activos generados;
• separar cachés de compilación y artefactos de publicación según el nivel de confianza;
• restringir las rutas de red salientes para flujos de trabajo automatizados;
• exigir evidencia antes de publicar, desplegar o declarar completa una corrección;
• dar a investigadores externos una ruta de reporte segura y documentada.

Esos controles no dependen del secreto del código fuente. Dependen de que los equipos sepan dónde vive el material sensible y qué acciones pueden causar daño. Si un repositorio contiene un secreto real, hacerlo privado después de la exposición resuelve el problema equivocado. Rota el secreto, elimínalo del historial cuando sea posible, invalida artefactos antiguos y documenta la ruta del incidente. El límite de publicación importa porque la salida externa necesita un umbral más fuerte que el análisis local.

Por eso la guía de GDS se siente correcta. No niega que la IA cambia la detección de vulnerabilidades. Rechaza la conclusión superficial. La IA hace que los sistemas débiles sean más fáciles de inspeccionar, así que la respuesta debería hacer que los sistemas sean más fáciles de poseer, auditar, reportar y reparar.

Qué haría hoy

Un equipo que enfrenta pánico por repositorios ante la IA debería ejecutar una revisión de código abierto de 48 horas antes de cambiar los valores por defecto:

1. Inventariar los repositorios públicos y asignar cada uno a un responsable.
2. Ejecutar análisis de secretos contra el árbol actual y el historial de Git.
3. Verificar si cada repositorio tiene un contacto de seguridad o una política de divulgación.
4. Identificar excepciones por fraude, abuso, arquitectura activa y políticas no publicadas.
5. Confirmar rutas de actualización de dependencias, publicación de parches y rollback.
6. Cerrar o retrasar solo los repositorios específicos que coincidan con una excepción nombrada.
7. Publicar la regla de decisión para que los equipos futuros no repitan el pánico.

Ese plan da a los líderes una superficie de control real. También crea evidencia. Un revisor futuro puede ver por qué un repositorio siguió abierto, por qué otro pasó a privado y qué trabajo redujo el riesgo real.

Preguntas frecuentes

¿La IA vuelve más peligroso el código público?

La IA puede hacer que el código público sea más fácil de inspeccionar, así que los equipos deberían esperar más reportes de vulnerabilidades y más sondeos automatizados. El peligro viene de vulnerabilidades sin corregir, secretos expuestos y ciclos de respuesta débiles. La visibilidad pública puede aumentar el descubrimiento, pero la privacidad no elimina el error subyacente.¹

¿Los equipos deberían hacer privados algunos repositorios alguna vez?

Sí. Los equipos deberían restringir el código que contiene o revela secretos, controles antifraude, arquitectura activa sensible, políticas no publicadas u otros daños específicos. Deben documentar la excepción y revisarla cuando la razón expire.³⁶

¿Por qué no cerrar todo hasta que el equipo termine una revisión?

El cierre general cambia beneficios públicos reales por una protección incierta. GDS advierte que el código que ya fue público puede existir en espejos, forks o copias clonadas.¹ Una revisión breve y dirigida es mejor que un valor por defecto indefinido que oculta problemas de propiedad.

¿Qué debería incluir un repositorio público antes de que un equipo lo considere suficientemente seguro?

Como mínimo: ningún secreto, un responsable, una licencia, notas claras de configuración, práctica de actualización de dependencias, un contacto de seguridad o una vía de divulgación de vulnerabilidades, y un proceso de publicación capaz de enviar correcciones rápido.

¿Cómo se relaciona esto con los agentes de programación con IA?

Los agentes amplían el mismo problema de límites. El riesgo rara vez está en un único archivo visible. Está en permisos, artefactos generados, cachés, solicitudes salientes, estado de compilación y autoridad de publicación. Tanto una buena seguridad de agentes como una buena política de código abierto requieren evidencia en esos límites.

Referencias