Se encontraron más de 100 mil repositorios infectados en GitHub

Artículo original ↗ Discusión en Hacker News ↗

Actores maliciosos han sembrado más de 100.000 repositorios infectados en GitHub, aprovechando la facilidad para crear cuentas y la automatización para ocultar ataques a la cadena de suministro entre proyectos legítimos de código abierto. Los comentaristas debaten cuánta responsabilidad deben asumir las plataformas y los gestores de paquetes frente a los desarrolladores individuales, y describen prácticas defensivas que van desde la separación estricta de entornos y el sandboxing (VMs, Qubes, contenedores) hasta herramientas de auditoría de dependencias y sistemas de reputación. Muchos ven esto como sintomático de un problema más profundo: la fuerte dependencia del software moderno de árboles de dependencias extensos y opacos y de la confianza ciega en código de terceros, que las herramientas de seguridad actuales solo mitigan parcialmente.

Aislamiento y sandboxing para desarrolladores

  • Muchos comentaristas ahora tratan cualquier código de terceros como no confiable, incluso el de repositorios “legítimos”.
  • Estrategias comunes: máquinas/VM separadas para trabajo, personal y hobbies; VMs efímeras en la nube (p. ej., EC2) destruidas después de usarlas; contenedores/devcontainers, Codespaces y VMs por actividad al estilo de Qubes OS.
  • Algunos ejecutan casi todo el desarrollo de forma remota; otros siguen prefiriendo lo local por control y rendimiento.

Desarrollo remoto y latencia

  • Algunos ven los escritorios remotos (Citrix, Guacamole, SSH + VNC/RDP) como el futuro inevitable y ya algo común en las empresas.
  • Otros informan de una latencia y un cansancio severos en el trabajo interactivo (programación, cambio de ventanas, juegos), incluso en entornos corporativos del mismo país.
  • Los juegos y los medios enriquecidos se consideran mucho menos tolerantes a la latencia que las cargas de trabajo de “oficina” o de programación.

El papel de GitHub y la escala de la infección

  • Debate sobre si ~100 mil repositorios maliciosos en una plataforma con cientos de millones de repositorios significa “fracaso” o un problema relativamente pequeño y manejable.
  • Según los informes, GitHub borra muchas bifurcaciones obviamente automatizadas; los repositorios maliciosos más sutiles sobreviven.
  • Los hosts más pequeños (p. ej. Codeberg) podrían estar protegidos por el bajo retorno de inversión para el atacante, pero podrían verse desbordados si fueran objetivo.

Herramientas y mitigaciones

  • Prácticas: preferir registros de paquetes con proxies/firewalls (p. ej., Sonatype), GitLab autohospedado, revisar paquetes mediante servicios como socket.dev, usar --ignore-scripts de npm, devcontainers y servidores de compilación con red limitada.
  • Herramientas mencionadas: Trivy, Semgrep Supply Chain, Packj, LavaMoat, container-shell, cargo-audit/deny, npm audit.
  • Varios comentarios subrayan que la mayoría de las herramientas encuentran vulnerabilidades conocidas, no malware nuevo ni puertas traseras.

Cultura de dependencias y riesgo en la cadena de suministro

  • Fuerte crítica a los árboles de dependencias enormes y profundos (especialmente en JavaScript). Las dependencias transitivas amplían enormemente el radio de impacto.
  • Algunos argumentan que los equipos deberían escribir más de sus propias bibliotecas, asumir el costo inicial y evitar los gestores de paquetes para sistemas críticos.
  • Otros proponen hacer snapshots de todas las dependencias bajo un espacio de nombres controlado para “poseer” la cadena de suministro.

Confianza, verificación y responsabilidad

  • Sugerencias: mejor indicación de repositorios “oficiales”, verificación de organizaciones vinculada a dominios, sistemas de reputación a nivel de gestor de paquetes.
  • Desacuerdo sobre si GitHub debería curar o clasificar por confianza el código, o si debería ser un anfitrión neutral.
  • Se plantean preguntas sobre la implicación de agencias de seguridad nacional (p. ej., CISA) y la dificultad de atribución.

LLMs y malware

  • Preocupación de que el malware generalizado en repositorios públicos pueda contaminar el entrenamiento de LLMs, llevando a sugerencias de código vulnerables o incluso maliciosas.
  • Algunos ven esto como alarmista; otros señalan que los LLMs ya emiten patrones inseguros, por lo que la revisión humana es esencial.
  • Entre las ideas figuran conjuntos de datos de entrenamiento curados y filtros de escaneo de malware o basados en IA para el entrenamiento y la salida.