En marzo, Wiz publicó un fallo de inyección de comandos en GitHub. Cualquiera con acceso push a cualquier repositorio en github.com podía ejecutar código como el usuario git en el storage node que alojaba los repositorios de millones de personas. GitHub parcheó el sitio público en dos horas. La mayoría de las instalaciones on-premise de Enterprise seguían sin parchear cuando llegó la noticia. El detalle que más importó al resto de nosotros: Wiz encontró el bug usando IA.
Una plataforma, cuatro vías de entrada
Mira los titulares relacionados con GitHub de los últimos dieciocho meses. El hallazgo de Wiz se sumó a tj-actions/changed-files, una GitHub Action usada por veintitrés mil repositorios que fue reescrita en silencio bajo todos los que dependían de ella, después de que un atacante mantuviera oculto durante seis meses un Personal Access Token robado. Luego CamoLeak, donde markdown invisible en un pull request le pedía a Copilot Chat que exfiltrara secretos a través del propio proxy de imágenes de GitHub. Luego la divulgación de Lasso de que la caché de Bing, y más tarde Copilot mismo, seguían sirviendo el contenido de repositorios que se habían hecho privados.
Cuatro clases de ataque distintas. Dieciocho meses. Una plataforma.
Este es un problema con la forma del problema
El SaaS centralizado para código fuente es un objetivo por la misma razón que es útil: reúne mucho código valioso en un sitio, en la infraestructura de un operador, detrás de un único conjunto de defensas. Lo que atraviese esas defensas atraviesa a todos los alojados en la plataforma a la vez. El ritmo es la otra mitad. Los investigadores de Wiz usaron herramientas de IA para leer binarios closed-source y hacer reverse engineering de los protocolos internos. El mismo tipo de herramienta que el resto de nosotros usa para autocompletar una función encontró una vulnerabilidad que puso millones de repositorios al alcance. Sea cual sea el ritmo de divulgaciones que pienses para la próxima década, la cifra real será mayor. La IA no se cansa.
El gobierno neerlandés leyó los mismos titulares y actuó. En abril hizo un soft launch de code.overheid.nl, una instancia auto-alojada de Forgejo gestionada por su propia oficina de Open Source. Su razonamiento, en sus palabras exactas: "Alojar código fuente es un componente crítico de la infraestructura del gobierno neerlandés. El gobierno no puede permitirse el riesgo de que el código o los binarios en los repositorios sean manipulados, ya que las personas podrían ejecutarlos directamente." Un gobierno nacional declarando por escrito que no puede tener su código manipulado en la caja de otro. Esa es la respuesta adulta.
Qué significa managed self-hosting
Managed self-hosting es la respuesta para equipos que quieren la soberanía sin tener que llevar el equipo de operaciones. Vuestra plataforma Git corre en hardware dedicado de un solo inquilino. Las claves, los datos y el audit trail son vuestros. Nosotros lo desplegamos, lo parcheamos, hacemos backup, lo monitorizamos y os contactamos si algo necesita atención. Sin aplicación compartida. Sin otros inquilinos en la misma instancia. El perímetro de defensa termina en vuestro equipo, no en el borde de una plataforma.
La parte práctica que más importa a los operadores es la proximidad. Vuestros datos están justo ahí cuando los necesitáis. Podéis iniciar sesión en el servidor y leer el backup directamente del disco. Podéis auditar quién tiene acceso y revocarlo sin abrir un ticket. Cuando llegue la próxima divulgación, no estaréis en una cola con ochenta mil empresas más esperando una ventana de parche.
Por qué Gitea
Gitea se parece y se siente como GitHub. Pull requests, issues, tableros de proyecto, Actions runners para CI, un registro de contenedores y paquetes. La mayoría de los equipos migra en una tarde y descubre que el flujo de trabajo diario es el mismo. Funciona con holgura en hardware modesto, escala horizontalmente para las partes que lo necesitan y es open source, así que el camino de salida es real si vuestras necesidades cambian.
Nosotros corremos nuestra propia ingeniería en Gitea. Cada línea de código que nuestro equipo entrega pasa por allí: pull requests, releases con Actions, el package registry que aloja nuestros módulos Go y nuestras imágenes de contenedor. Nuestro CRM, helpdesk, project tracker y la Platform Demo sobre la que trabajan nuestros agentes viven todos en el mismo hardware dedicado. Todo lo que enviamos corre sobre la infraestructura en la que pondríamos a un cliente mañana.
Para quién es esto
Esto es para equipos de software de cinco a cincuenta personas que escriben código que importa. Agencias digitales cuyo código de cliente forma parte del entregable. Empresas de software con IP sensible, trabajo de contratación del sector público u obligaciones de cumplimiento bajo DORA, NIS2 o RGPD que se simplifican cuando el límite de auditoría es vuestro propio servidor. No es para proyectos hobby ni startups de tres personas quemando runway; para esas, la prima del SaaS sigue valiendo la pena. La pregunta es si la herramienta que guarda el código fuente de vuestro equipo debería estar en la plataforma de otro, junto con la de todos los demás.
¿Es hora de tomar el control?
Los titulares no van a frenarse. La próxima divulgación se está escribiendo justo ahora, por un investigador que deja corriendo un bucle de reverse engineering durante toda la noche mientras el mundo duerme. La respuesta es la misma que adoptó el gobierno neerlandés: poned vuestro código fuente en hardware que controléis, con claves que poseáis, y alguien competente que lo mantenga funcionando.