NHS retrocede en código abierto: riesgos técnicos y postura de DevOps

Introducción

El pasado 7 de mayo, The Register reportó que el NHS (National Health Service del Reino Unido) ordenó a su área de tecnología aislar sus repositorios de código abierto (FOSS) bajo llave. La justificación oficial fue el riesgo que representan herramientas de Large Language Models (LLM) para detectar vulnerabilidades en el código. Pero detrás de esta decisión hay un problema técnico concreto: ¿Cómo equilibrar la transparencia del código público con la necesidad de evitar que herramientas automatizadas —sin control— encuentren fallos críticos en sistemas críticos como los de salud?

Para DevOps e infraestructura, esto no es un tema de ideología, sino de riesgos operativos. La migración forzada a repositorios privados rompe con cadenas de herramientas que ya usan GitHub Actions, AWS IAM y componentes en Rust para auditorías de seguridad. Además, la decisión del NHS podría sentar un precedente peligroso: si un organismo estatal cierra el código por miedo a la IA, ¿qué otras instituciones seguirán el mismo camino?

Qué ocurrió

Según la cobertura de The Register, el NHS tomó esta decisión tras una evaluación interna donde se determinó que herramientas de bug hunting basadas en LLMs —como GitHub Copilot o Amazon CodeWhisperer— podían identificar vulnerabilidades en el código público antes que los equipos de seguridad. Sin embargo, el movimiento generó un rechazo inmediato:

1. FSFE (Free Software Foundation Europe): Publicó una carta abierta criticando la decisión y lanzó una petición en keepthingsopen.com con 812 firmas al momento del reporte (y en aumento).
2. Petición parlamentaria: Hay una iniciativa en el Parlamento británico para exigir que el Estado migre sus sistemas a software abierto por defecto, bajo el argumento de soberanía digital y reducción de dependencias geopolíticas.

El problema técnico subyacente no es la IA en sí, sino la falta de controles en el uso de estas herramientas. Por ejemplo:

• Herramientas como CodeQL (usada en GitHub) ya escanean repositorios públicos en busca de vulnerabilidades sin necesidad de LLMs.
• En sistemas críticos como los de salud, el código no solo debe ser auditado, sino también firmado criptográficamente para garantizar integridad.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps

El NHS no es un caso aislado. Muchos equipos en organizaciones públicas y privadas ya enfrentan presiones similares:

1. Integración con AWS IAM y GitHub:

– Si el NHS cerró sus repositorios, los pipelines que dependían de ellos (por ejemplo, para actualizar imágenes de Rust en entornos Kubernetes) quedarían rotos.

– Ejemplo concreto: Un equipo que usaba Linkerd para mallas de servicio en AWS y dependía de repositorios públicos de Rust para sus sidecars tendría que migrar a versiones privadas, aumentando costos y complejidad.

1. Riesgo de shadow IT:

– En entornos regulados (como salud), esto expone a multas por incumplimiento de normas como UK GDPR o HIPAA.

Para Seguridad

El argumento del NHS apunta a un problema real: herramientas de IA no controladas pueden exponer datos sensibles. Por ejemplo:

• Un LLM que analice repositorios públicos podría inferir información confidencial (ej.: algoritmos de diagnóstico en código médico).
• Dato clave: En 2023, la CVE-2023-23529 afectó a modelos de IA que filtraron datos de entrenamiento. ¿Qué pasa si un LLM escanea código del NHS y extrae información de pacientes?

Para Cloud

• AWS y Rust: Muchos componentes en Rust (como los usados en Linkerd para balanceo de carga) dependen de crates.io, el repositorio público de Rust. Si el NHS cierra sus repositorios, los equipos que usen estas dependencias tendrían que:

– Firmar criptográficamente los crates para evitar supply chain attacks (ej.: el ataque a CodeCov en 2021).

Detalles técnicos

¿Por qué el NHS tomó esta decisión?

Según The Register, el NHS citó dos riesgos concretos:

1. Filtración de datos sensibles:

– Ejemplo: En 2022, un tribunal alemán multó a una empresa por usar GitHub Copilot sin consentimiento explícito de los desarrolladores cuyos códigos fueron usados para entrenar el modelo.

1. Riesgo de prompt injection:

– CVE relevante: En 2024, la CVE-2024-3094 afectó a versiones de Rust que permitían arbitrary code execution en dependencias maliciosas.

Componentes afectados

1. Auditar herramientas de IA en pipelines

Si tu organización usa herramientas como GitHub Copilot o Amazon CodeWhisperer, sigue estos pasos:

# Listar repositorios públicos con permisos de IAM
aws iam list-attached-user-policies --user-name <usuario> | jq '.AttachedPolicies[].PolicyArn'

# Escanear código en busca de secrets (usando GitLeaks)
docker run --rm -v $(pwd):/code zricer/gitleaks detect --source /code --report-format json

• Acciones:

– Implementar GitHub Advanced Security para escaneo de código antes de que herramientas externas lo analicen.

2. Migrar a repositorios privados con auditoría

Si debes cerrar repositorios públicos (como el NHS):

# Ejemplo de GitHub Actions para migrar a private repo con checks de seguridad
name: Migrate to Private
on:
  push:
    branches: [main]

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          scan-ref: '.'

• Requisitos:

– Usar AWS IAM Roles con permisos mínimos para pipelines.

3. Implementar mTLS en servicios críticos

Para sistemas como Linkerd en entornos cloud:

# Configurar mTLS en Linkerd 2.14.0+
linkerd install --set proxy.opaquePorts="443" --set identityTrustAnchorsPEM="$(cat ca.crt)"

• Beneficio: Reduce el riesgo de que herramientas de IA intercepten tráfico entre servicios.

4. Participar en iniciativas de código abierto

• Firmar la petición de la FSFE: keepthingsopen.com.
• Evaluar el uso de FOSS en tu organización con herramientas como:

– FOSSA (para auditorías automatizadas de licencias).

Conclusión

La decisión del NHS refleja una tensión real: la transparencia del código abierto vs. los riesgos de herramientas automatizadas. Para DevOps e infraestructura, la solución no es cerrar repositorios, sino:

1. Implementar controles estrictos en el uso de IA (evitar que escaneen código sensible).
2. Auditar dependencias con herramientas como Trivy o Sigstore.
3. Mantener la transparencia donde sea posible, pero con salvaguardas técnicas.

El código abierto sigue siendo el estándar para sistemas críticos, pero requiere una arquitectura de seguridad robusta. Si el NHS retrocede, otros podrían seguir el mismo camino —y eso sí sería un problema.

Fuentes

• The Register: NHS code clampdown draws open source backlash
• Linkerd Security Blog
• Rust Blog: Security Advisories
• FSFE Open Letter: Keep Things Open
• CVE-2023-23529: Data Leakage in AI Models
• GitHub Advanced Security Docs