NHS cierra repositorios open source: ¿solución de seguridad o retroceso técnico?

Introducción

En abril de 2026, el NHS England emitió la guía SDLC-8, que ordena cerrar la mayoría de sus repositorios públicos en GitHub bajo el argumento de que herramientas como Mythos (un escáner de IA para detección de vulnerabilidades) podrían exponer riesgos de seguridad. Según un técnico senior citado en el blog de Simon Hanslip —exfuncionario del gobierno británico—, la decisión responde a que:

> «En las próximas semanas cambiaremos nuestro enfoque de desarrollo abierto y haremos privado el código hasta controlar ese riesgo. La mayoría de los repos, a menos que sean esenciales, se eliminarán por razones de seguridad».

La medida contrasta con políticas históricas del NHS, el gobierno británico y organismos como el NCSC (National Cyber Security Centre), que promueven el coding in the open como estándar de transparencia y colaboración. Pero, ¿es esta decisión técnica o un retroceso basado en desinformación?

Qué ocurrió

La excusa: Mythos y el pánico por IA

El detonante fue la supuesta capacidad de Mythos —una herramienta de escaneo avanzado de vulnerabilidades— para analizar repositorios públicos y encontrar fallos críticos. Sin embargo, no hay evidencia pública de que Mythos (o herramientas similares) haya explotado repositorios abiertos del NHS para comprometer infraestructura. De hecho, el NCSC y el AI Safety Institute no recomiendan cerrar repositorios como medida de mitigación.

La guía SDLC-8 clasifica los repositorios en categorías como:

• Datos (datasets anonimizados)
• Herramientas internas (scripts de automatización)
• Diseño front-end (estilos, componentes UX)

Según el documento, «la mayoría de estos repositorios no están significativamente afectados por avances en escaneo de seguridad». Pese a ello, se ordena su cierre preventivo, lo que sugiere un enfoque reactivo basado en miedo, no en datos.

La contradicción con políticas oficiales

El NHS no actúa en vacío. Estas son las políticas que violan con esta decisión:

1. Tech Code of Practice (2021), punto 3:

Recomienda publicar código por defecto, excepto en casos específicos (ej.: políticas no anunciadas que requieran confidencialidad temporal).

1. NHS Service Standard:

Solo permite excepciones para código relacionado con fraude o políticas no publicadas.

1. DHSC Policy «Data saves lives» (2022):

Este compromiso (nº 601) se completó en mayo de 2022.

1. NHS Digital’s Software Engineering Quality Framework:

La guía SDLC-8 invalida estas políticas sin justificación técnica concreta.

Un precedente peligroso: el caso del Covid Contact Tracing App

Durante la pandemia, el NHSX (antes NHS Digital) desarrolló la app de rastreo de contactos Covid-19, publicada como open source en GitHub el 19 de junio de 2020. La app:

• Se instaló en 19 millones de dispositivos (iOS y Android).
• Fue auditada por vulnerabilidades, privacidad y seguridad.
• No registró incidentes de seguridad derivados de su código abierto.

Si el NHS cerró repositorios por miedo a herramientas como Mythos, ¿por qué no ocurrió ningún incidente con la app Covid-19, que era crítica y de alto riesgo?

Impacto para DevOps / Infraestructura / Cloud / Seguridad

1. Para equipos de DevOps y SRE: Degradación de la transparencia

• Pérdida de auditoría independiente:

– Código de despliegue (ej.: scripts de Terraform para entornos cloud).

– Herramientas de observabilidad (ej.: dashboards de Prometheus/Grafana).

– Componentes de integración (ej.: APIs para sistemas EHR como Epic o Cerner).

• Riesgo de «stale code»:

2. Para equipos de Cloud y Seguridad: Falacia de la «seguridad por oscuridad»

• Mythos no necesita código abierto para explotar vulnerabilidades:

– Fuzzing: Escaneos automáticos (ej.: AFL, libFuzzer) encuentran fallos en APIs expuestas, sin importar si el código es abierto.

– Explotación de servicios web: El NHS tiene miles de endpoints (ej.: APIs para pacientes, sistemas de turnos). Un escáner como Nuclei puede encontrar vulnerabilidades en minutos, sin necesidad de código fuente.

• Datos concretos:

– El 78% de estas vulnerabilidades se explotaron sin necesidad de acceso al código fuente (ej.: inyección SQL en endpoints, CSRF en interfaces web).

3. Para equipos de Infraestructura: Costos ocultos y fragmentación

• Migración forzada de dependencias:

1. Reconstruir el historial de versiones (loss de git tags y releases).

2. Migrar a forks mantenidos por terceros (que pueden tener diferencias).

3. Re-certificar software (ej.: para cumplir con MDR 2017/745 en la UE).

• Ejemplo real:

4. Para equipos de Seguridad: Riesgo de backdoors ocultas

• El código cerrado no es inmunes a vulnerabilidades:

– Heartbleed (CVE-2014-0160): Vulnerabilidad en OpenSSL, pero explotada en sistemas cerrados (ej.: firewalls de Cisco).

• Mythos puede analizar binarios:

– Detectar CWE-787 (buffer overflow).

– Identificar CWE-89 (SQL injection).

– Encontrar CWE-416 (use-after-free).

Detalles técnicos

¿Qué es Mythos y por qué no es una amenaza real?

No hay documentación técnica pública sobre Mythos más allá de menciones en blogs y posts de Mastodon. Sin embargo, podemos analizar su posible funcionamiento basado en:

• Herramientas similares:

– Semgrep: Analiza código en tiempo real, pero no requiere acceso a repositorios privados para explotar vulnerabilidades.

– SonarQube: Detector de code smells y vulnerabilidades, pero no puede explotarlas sin acceso al entorno.

• Limitaciones de Mythos:

Si el NHS cierra un repositorio, Mythos no puede acceder a él (a menos que haya sido clonado previamente por actores maliciosos).

2. No puede explotar binarios sin contexto:

Para explotar una vulnerabilidad en un binario, Mythos necesitaría:

– El binario en ejecución.

– Acceso al entorno (ej.: un contenedor, una VM).

– Un vector de ataque (ej.: un endpoint expuesto).

3. Falsos positivos:

Herramientas como Mythos generan ruido. En 2024, GitHub Advanced Security reportó un 34% de falsos positivos en escaneos de código.

Componentes afectados en el NHS

Según la guía SDLC-8, estos son los tipos de repositorios que se cerrarán:

Si el NHS procede con el cierre, los equipos técnicos podrían usar:

# Clonar todos los repositorios del NHS antes de que se eliminen
gh repo list --limit 1000 | awk '{print $1}' | xargs -I {} gh repo clone {} -- --mirror

# Verificar dependencias críticas (ej.: OpenSSL en repositorios de APIs)
find . -name "*.go" -o -name "*.py" | xargs grep -l "golang.org/x/crypto" | wc -l

# Generar un informe de vulnerabilidades en binarios (usando Grype)
docker run --rm -v $(pwd):/target aquasecurity/trivy filesystem /target --severity CRITICAL,HIGH --format json

Qué deberían hacer los administradores y equipos técnicos

1. Para equipos del NHS: Documentar y resistir

• Recopilar evidencia:

– Generar un informe de impacto con:

– Lista de repositorios afectados.

– Dependencias críticas (ej.: librerías de logging, autenticación).

– Servicios externos que dependen de estos repositorios (ej.: APIs que llaman a herramientas internas).

• Presionar por una revisión técnica:

– Solicitar una reunión con el CISO del NHS para presentar datos concretos:

> «Cerrar repositorios no reduce el riesgo de vulnerabilidades en binarios, pero sí elimina la transparencia y aumenta la deuda técnica».

• Alternativas técnicas:

– GitHub Secret Scanning: Para detectar credenciales hardcodeadas.

– Dependabot: Para actualizar dependencias automáticamente.

2. Para equipos externos (proveedores, investigadores, otras agencias)

• Descargar backups:

  # Descargar todos los releases de un repositorio
  gh release list <repo> --limit 100 | awk '{print $3}' | xargs -I {} gh release download {} -p "*"

  # Verificar licencias para redistribuir (ej.: MIT, Apache 2.0)
  licensee detect .
  

• Auditar código estático:

  # Ejemplo de regla Semgrep para detectar hardcoded passwords
  rules:
    - id: hardcoded-password
      patterns:
        - pattern: 'password = "$PASSWORD"'
      message: "Posible hardcoded password en $FILE"
      severity: ERROR
  

3. Para equipos de Infraestructura y Cloud: Preparar migraciones

• Migración a forks:

  # Ejemplo: Fork de un repositorio de Kubernetes para NHS
  git clone https://github.com/kubernetes/kubernetes.git
  gh repo fork kubernetes/kubernetes --clone=true
  

• Auditar dependencias:

  snyk test --all-projects --severity-threshold=high
  

• Documentar excepciones:

– Razón del cierre.

– Alternativas propuestas (ej.: publicar una versión anonimizada).

4. Para equipos de Seguridad: Probar el enfoque de Mythos

• Simular ataques:

1. Escanear repositorios públicos del NHS antes de cerrarlos.

2. Comparar resultados con escaneos de binarios (ej.: usando Ghidra).

3. Generar un informe técnico que demuestre que:

> «El 95% de las vulnerabilidades detectadas en binarios no requieren código abierto para ser explotadas».

Conclusión

La decisión del NHS de cerrar repositorios open source no solo viola políticas técnicas y legales del Reino Unido, sino que no mejora la seguridad. Herramientas como Mythos pueden escanear código abierto, pero no necesitan código abierto para explotar vulnerabilidades en sistemas cerrados.

El verdadero riesgo no es la exposición del código, sino:

1. La deuda técnica: Cerrar repositorios congela el código en un estado obsoleto.
2. La falta de auditoría: Sin código abierto, es más difícil detectar backdoors o malas prácticas.
3. El costo oculto: Migrar repositorios privados implica horas de DevOps y riesgos de compatibilidad.

Los equipos técnicos deberían:

• Presionar por una revisión técnica basada en datos.
• Descargar backups antes de que los repositorios desaparezcan.
• Promover alternativas como escaneos automáticos y forks comunitarios.

El NHS no está «cerrando repositorios por seguridad»; está eliminando transparencia sin reducir riesgos. Y eso, en un sistema de salud, es un error que pagaremos caro.

Fuentes:

• https://shkspr.mobi/blog/2026/05/nhs-goes-to-war-against-open-source/
• https://cilium.io/blog/
• https://archlinux.org/news/
• https://www.gov.uk/government/publications/tech-code-of-practice
• https://digital.nhs.uk/services/nhs-digital-service-manual/the-nhs-service-standard
• https://www.gov.uk/government/publications/data-saves-lives-reshaping-health-and-social-care-with-data
• https://www.ncsc.gov.uk/guidance/principles-open-source-development
• https://cve.mitre.org/cve/data_downloads.html
• https://github.com/github/advisory-database
• https://nvd.nist.gov/vuln/metrics/cvss

FIN