Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- Los hashes de los módulos de Go cubren los nombres y el contenido de los archivos, no la codificación zip, por lo que un archivo reconstruido de forma independiente puede coincidir exactamente.
- Por eso, apuntar GOPROXY a un registro filtrado no invalida las entradas go.sum que ya tienes.
- La reconstrucción exacta demuestra que un archivo coincide con su fuente, no que la fuente sea segura.
- El cambio en sí mismo es una variable de entorno, y el riesgo real reside en la deriva de la configuración.
En julio de 2026, investigadores vincularon una oleada de cuentas de mantenedores comprometidas en npm, Packagist y módulos de Go con una campaña relacionada con Corea del Norte llamada PolinRider . La campaña también publicó paquetes maliciosos completamente nuevos, pero lo más relevante es lo que sucedió con los paquetes ya existentes. Los atacantes accedieron a cuentas con años de historial limpio y distribuyeron nuevas versiones desde allí.
Una nueva versión de un módulo publicada desde una cuenta de mantenedor comprometida puede superar las comprobaciones de integridad de Go en su primer uso. Tanto go.sum como la base de datos de sumas de verificación confirman que se recibió exactamente lo que se publicó. Ninguna de las dos emite una opinión sobre si lo publicado es seguro.
Agregar una capa de verificación a una compilación puede generar fricciones. Nuevas identidades de paquetes que conciliar, versiones que controlar, cambios en los archivos de bloqueo que nadie había previsto. Go sale relativamente bien parado, y vale la pena entender el motivo, porque también explica qué puede y qué no puede demostrar la verificación en Go.
¿Por qué se pueden verificar exactamente los archivos de módulos de Go?
Un archivo zip de un módulo Go contiene el código fuente. No se compila nada durante el proceso, y la estructura del archivo sigue un algoritmo documentado en lugar de lo que haga el script de empaquetado del editor en ese momento.
Esto tiene una consecuencia que la mayoría de la gente pasa por alto. Go calcula el hash del módulo sobre los nombres y el contenido de los archivos dentro del archivo comprimido. La codificación ZIP, el método de compresión, las fechas de modificación de cada archivo y otros metadatos se ignoran. Por lo tanto, cualquiera con acceso al historial de control de versiones puede reconstruir el módulo y obtener la misma suma de verificación h1:, incluso cuando los dos archivos ZIP difieren byte a byte.
Otros ecosistemas tienen más elementos que se interponen entre un repositorio y un artefacto publicado. Maven distribuye JARs compilados. Los wheel de Python son el resultado de la compilación. Un tarball de npm puede contener el código fuente directamente o el contenido que haya dejado un script de preempaquetado. El trabajo de compilación reproducible ha avanzado considerablemente en varios de estos ecosistemas, por lo que no existe una línea divisoria clara entre lo imposible y lo exacto. El problema radica en que la suma de verificación de Go se diseñó desde el principio para ignorar el ruido del empaquetado, lo que hace que la reconstrucción independiente sea excepcionalmente sencilla de comprobar.
La diferencia entre los proveedores radica en si alguien realiza realmente esa comparación a nivel de registro, en cada módulo y en cada ocasión. Un registro de verificación puede obtener el historial del sistema de control de versiones (VCS) para una ruta de módulo, crear el archivo según las especificaciones y compararlo con el archivo proporcionado por el proxy público. Una discrepancia significa que el archivo no corresponde a la fuente de la que afirma provenir.
Esa distinción tiene más peso del que parece a primera vista. La reconstrucción exacta indica que un archivo coincide con su origen declarado. No dice nada sobre si el origen en sí es seguro. PolinRider es un buen ejemplo, ya que los atacantes modificaron directamente los repositorios legítimos, en algunos casos forzando la modificación de confirmaciones existentes. Una reconstrucción fiel a partir de ese origen reproduce el contenido malicioso con la misma fidelidad. La reconstrucción detecta manipulaciones entre el repositorio y el archivo. Detectar código malicioso dentro del repositorio es una tarea aparte.
Nota: Para los artefactos que requieren compilación, scripts de empaquetado o archivos generados, «reconstruido desde el código fuente» también implica reproducir esas condiciones de compilación. La suma de verificación de Go proviene directamente del árbol de código fuente empaquetado, lo que hace que la comparación sea excepcionalmente sencilla de auditar. Pídale al proveedor que le muestre una discrepancia, no que la describa.
¿Por qué go.sum sigue funcionando?
Si un registro reconstruye los archivos de módulos, ¿cambian los hashes y se rompen todos los go.sum de la organización?
No. Dado que el hash abarca el árbol de archivos e ignora los detalles del empaquetado, un archivo reconstruido correctamente genera el mismo hash que el proxy público. Tus entradas existentes de go.sum se validan con este valor, y la base de datos de sumas de verificación en sum.golang.org sigue coincidiendo.
Por eso, el cambio no requiere modificaciones en go.mod ni en go.sum. No se trata de una ruta de migración que casualmente sea corta. No hay nada que migrar. La coincidencia de hashes es el resultado esperado, y una divergencia es una señal, no un inconveniente.
Un caso rompe esa simetría y merece una respuesta directa en lugar de una nota al pie. Go trata la ruta del módulo y la versión como inmutables. Por lo tanto, si un registro sirve contenido parcheado para una versión que ya existe en la versión principal, ese contenido no puede reutilizar la suma de verificación de la versión principal. Una entrada existente en go.sum rechazaría directamente los bytes modificados, y la base de datos pública de sumas de verificación seguiría almacenando el hash de la versión principal. Por consiguiente, los módulos parcheados necesitan un mecanismo de entrega documentado propio, ya sea una versión distinta, una ruta de módulo distinta u otra configuración de confianza controlada. Si la aplicación de parches después del fin de vida útil es uno de los motivos por los que está migrando, confirme ese mecanismo con TuxCare antes de planificar el despliegue. Es el único punto donde la afirmación de que "nada cambia" deja de ser cierta.
La única línea
GOPROXY acepta cualquier URL que implemente el protocolo proxy del módulo, por lo que apuntar a un registro filtrado es simplemente un cambio de variable de entorno.
go env -w GOPROXY=<your SecureChain Go proxy URL>,direct
Utilice una coma antes de `direct` en lugar de una tubería, y tenga en cuenta el efecto de cada una. Con una coma, Go recurre a la siguiente entrada solo después de un error 404 o 410. Con una tubería, recurre a cualquier error, incluido un tiempo de espera, por lo que una interrupción del registro redirige silenciosamente la compilación para evitar el elemento para el que instaló el registro. En cualquier caso, `direct` significa obtener directamente de la fuente del control de versiones, y una coma aún permite que un error 404 llegue a ella. Si el registro está diseñado para actuar como una puerta de enlace en lugar de una sugerencia, los módulos bloqueados deberían devolver un mensaje distinto a "no encontrado". La propia referencia de Go apunta al código 403 precisamente para este propósito.
Esto funciona tanto si GOPROXY apunta directamente a SecureChain como si apunta a un gestor de repositorios como Artifactory o Nexus, que a su vez apunta a SecureChain. Los módulos y el flujo de trabajo son los mismos en ambos casos.
Para la integración continua (CI), configúrelo en el entorno en lugar de incorporarlo a una imagen.
export GOPROXY=<your SecureChain Go proxy URL>,direct
exportar GOSUMDB=sum.golang.org
Dejar GOSUMDB activado explícitamente es intencional. La verificación de la suma de comprobación y el análisis del registro responden a preguntas diferentes, y el cambio de proxies no es motivo para desactivar ninguno de los dos.
Consejo: Configure GOPROXY con `go env -w` en las máquinas de los desarrolladores y mediante variables de entorno de CI en los agentes de compilación. Luego, ejecute `go env GOPROXY` en un ejecutor real para ver qué configuración se aplica realmente. Las imágenes base a veces incluyen su propio valor incorporado, y eso suele ser lo que causa problemas en estos despliegues.
Qué permanece igual y qué cambia
| Artículo | Cambios |
| go.mod | No |
| go.sum para módulos ascendentes servidos tal cual | No |
| Ve a construir, ve a probar, ve a obtener | No |
| Directorios de proveedores | No |
| Comportamiento de selección de versión | No |
| De dónde se obtienen los archivos | Sí |
| Si los archivos se examinan antes de su resolución | Sí |
Nada en tus comandos de compilación cambia, ni tampoco el repositorio. Lo que cambia es el origen del archivo y si se verifica antes de que la compilación lo acceda. Sin embargo, hay una advertencia sobre esa fila de dependencias. Una compilación de dependencias lee desde vendor/ y nunca consulta al proxy, por lo que no obtiene ningún beneficio del cambio hasta que actualices el directorio.
Lo que añade la evaluación antes de la resolución
Go no tiene un gancho de instalación equivalente a los scripts del ciclo de vida de npm, lo que normalmente es una ventaja. Sin embargo, esto no significa que el contenido de un módulo sea inofensivo. El código fuente malicioso termina compilándose en el binario, y las herramientas de un repositorio pueden abrir sus propias rutas de ejecución. PolinRider es un buen ejemplo de este último caso. Las cargas útiles eran cargadores JavaScript ofuscados ocultos en los recursos del proyecto, incluyendo archivos de fuentes .woff2 falsos, en lugar de algo que se ejecutara desde una función de inicialización de Go.
Esto convierte el análisis previo a la resolución en una de las primeras oportunidades automatizadas para detener el contenido malicioso antes de que llegue al entorno de compilación.
Se presentan tres variantes del problema, y cada una requiere tres soluciones diferentes.
Una ruta de módulo modificada puede distribuir una nueva versión maliciosa a través de la ruta legítima sin violar ninguna suma de verificación que Go ya tenga, ya que estas autentican el contenido del módulo en lugar de la propiedad o la intención del repositorio. Recompilar desde esa fuente VCS comprometida tampoco ayuda, puesto que el repositorio ahora pertenece al atacante. Analizar el contenido en busca de malware antes de la resolución sí funciona.
Una versión publicada en el repositorio principal tras una vulneración de cuenta es el caso de PolinRider. go.sum y la base de datos de sumas de verificación pueden autenticarla correctamente, ya que responden si se trata de los mismos bytes, en lugar de si estos bytes son seguros. El filtrado es lo que resuelve ese problema.
Un módulo abandonado con una vulnerabilidad CVE es un problema completamente distinto. No se introdujo ningún software malicioso; simplemente, el responsable dejó de corregir lo que ya existía. Los avisos de seguridad lo indicarán, pero cerrarlo implica mantener el módulo actualizado incluso después de que su autor haya dejado de trabajar en él, lo cual es mantenimiento, no una simple revisión. Esto es lo que cubre el Soporte de Ciclo de Vida Interminable (ELS).
Vale la pena analizar la magnitud del caso de robo de cuentas. Los investigadores encontraron rastros de compromiso en 80 módulos Go de un total de 108 paquetes únicos afectados durante la campaña, con 162 artefactos de lanzamiento maliciosos en total, y rastrearon la actividad como parte de Contagious Interview, también conocido como Famous Chollima. Estos módulos fueron comprometidos a través de cuentas con años de historial legítimo, en lugar de nombres similares recién registrados, lo cual es precisamente lo que la verificación de integridad por sí sola no puede detectar. Una nueva versión de este tipo pasa la primera resolución porque el hash autentica fielmente cualquier contenido asociado a esa versión, y un envío de un mantenedor de confianza desde hace mucho tiempo no parece sospechoso a simple vista.
Existe un problema delicado, especialmente para Go. Dado que los módulos de Go suelen obtenerse directamente de las etiquetas o confirmaciones del sistema de control de versiones, en lugar de subirse por separado a un registro, una vulnerabilidad en el repositorio puede propagarse por todo el ecosistema de módulos sin que el atacante necesite credenciales adicionales. Los investigadores observaron que la cuenta de un mantenedor comprometido no mostraba versiones maliciosas en un ecosistema que requiere un paso de carga independiente, lo que podría significar que los atacantes nunca llegaron a ese punto.
El abandono es la versión más silenciosa de la misma exposición. Un análisis reciente de 13,1 millones de paquetes de código abierto sitúa la proporción de Go fuera de banda, ponderada por repositorios dependientes en lugar de por cantidad de paquetes, entre el 33,2 % y el 57,9 %. La diferencia radica en la definición: la cifra superior incluye todo aquello sin una publicación en 730 días. La inferior también requiere que no haya confirmaciones en el repositorio durante ese período. En cualquier caso, los ejemplos de Go mencionados resultan familiares: gopkg.in/yaml.v2, jwt-go, AWS SDK para Go v1. Ninguna arquitectura de registro, filtrada o no, resuelve este problema por sí sola. Requiere parches continuos, que es para lo que sirve el tercer caso mencionado anteriormente.
Implementarlo sin romper las compilaciones
Cuatro fases, y el orden importa más que la velocidad.
| Fase | Acción | Lo que aprendas |
| 1 | Configure GOPROXY en un servicio no crítico. | Si alguna ruta de módulo falla al resolverse |
| 2 | Descarga y verifica las dependencias desde una caché de módulos vacía. | Si los módulos servidos a través del nuevo registro se autentican contra su go.sum existente |
| 3 | Implementar en CI en todos los repositorios | ¿Qué pipelines tenían GOPROXY codificado de forma fija en una imagen? |
| 4 | Restringir la salida del agente de compilación al registro y a la base de datos de suma de comprobación. | Lo que estaba eludiendo silenciosamente la configuración |
La segunda fase produce las pruebas que un revisor escéptico realmente solicitará.
limpiar -modcache
Descarga del mod Go
ir mod verificar
Es importante ser precisos sobre lo que demuestra cada comando. Con la caché vacía, `go mod download` fuerza la descarga de los módulos necesarios a través del nuevo registro y los autentica comparándolos con las entradas de `go.sum` confirmadas o con la base de datos de sumas de verificación configurada, donde aún no se ha registrado un hash. `go mod verify` confirma que el contenido almacenado en caché no ha cambiado desde su descarga. A continuación, ejecuta tu compilación o prueba habitual, y la compatibilidad se validará con las dependencias actuales de tu proyecto en tu propio entorno, en lugar de con la documentación del proveedor.
La fase cuatro es donde la política se convierte en aplicación. Hasta que se cierre la salida, GOPROXY es una sugerencia que cualquiera puede anular para desbloquear un despliegue de viernes. Bloquear proxy.golang.org por sí solo no funcionará, porque esa ruta directa envía errores 404 a GitHub y otros sitios. Permita el registro y deniegue el resto. Una comprobación antes de cambiar la regla: la verificación de suma de comprobación aún necesita acceso a la base de datos de suma de comprobación, ya sea directamente o a través de un proxy que la replique, así que confirme que esas consultas siguen resolviéndose en lugar de descubrirlo durante el primer fallo en la canalización.
Consejo práctico: Ejecuta la fase cuatro en el entorno de pruebas el tiempo suficiente para poner a prueba tus flujos de trabajo de compilación habituales antes de la producción. Esto revelará el inventario real de canalizaciones que se resolvían directamente sin que nadie lo supiera, y ese inventario es mucho más útil como lista ahora que como incidente posterior.
Asegure su cadena de suministro Go
Si las fases uno y dos ya se han superado en tus propios repositorios, con tu propio go.sum, esa es la evidencia de compatibilidad que necesita una revisión de seguridad y que tú mismo has generado. Lo que SecureChain para Go añade a partir de ahí es un análisis continuo en cada obtención de datos en lugar de una comprobación única, además de parches que continúan incluso después de que el mantenedor de un módulo haya dejado de trabajar en él, entregados a través de un registro que utiliza el mismo protocolo de proxy de módulos que tu conjunto de herramientas ya espera. Antes de recurrir a los parches posteriores al fin del soporte, confirma el mecanismo documentado de versionado y suma de comprobación para los módulos Go parcheados para que pueda integrarse en el despliegue.
Solicita un presupuesto para SecureChain o compara SecureChain con Chainguard .
PREGUNTAS FRECUENTES
¿Cómo cambio el proxy de mi módulo Go?
Establezca la variable de entorno GOPROXY con la URL del registro, usando una coma antes de direct en lugar de una tubería. Al ejecutar go env -w GOPROXY=… se guarda en la máquina del desarrollador. En CI, configúrela en el entorno en lugar de en una imagen base.
¿Cambiar los proxies de los módulos Go provoca que se rompa go.sum?
No, siempre que el registro sirva el mismo contenido de módulo. El hash del módulo de Go proviene de los nombres y el contenido de los archivos, no de los detalles de codificación ZIP, por lo que los archivos generados de forma independiente con la misma estructura de archivos producen el mismo hash. Los módulos parcheados son la excepción, ya que un contenido diferente implica, por definición, un hash diferente, y la forma en que se versiona y autentica dicho contenido depende del mecanismo de entrega de módulos parcheados del registro.
¿Puedo mantener habilitada la base de datos de suma de comprobación?
Sí, y deberías hacerlo. La verificación de GOSUMDB y el análisis del registro responden a preguntas diferentes, y para los módulos originales que se sirven tal cual, los hashes coinciden por definición. Deja GOSUMDB=sum.golang.org habilitado para esos módulos y gestiona los parcheados mediante el mecanismo de versionado y suma de comprobación que tu registro documente para ellos.
¿Necesito modificar go.mod para usar un proxy diferente?
No. go.mod registra las rutas y versiones de los módulos, y aparte de las directivas de reemplazo que hayas configurado, no tiene control sobre la procedencia de los archivos. La selección del proxy se realiza en la configuración del entorno.
¿Cómo puedo verificar yo mismo la afirmación de compatibilidad?
Borra la caché de módulos con `go clean -modcache`, ejecuta `go mod download` a través del nuevo registro para que Go vuelva a descargar y autentique todo con tus sumas de verificación existentes, luego ejecuta `go mod verify` seguido de tu compilación o conjunto de pruebas habitual. Un resultado positivo significa que los módulos recibidos coinciden con los hashes en los que tu proyecto ya confía.
