Vercel añade login por OIDC a VCR desde GitHub Actions

Qué cambió exactamente en Vercel

Vercel publicó la acción oficial vercel/vcr-action/login@v1, que permite a un workflow de GitHub Actions autenticarse contra Vercel Container Registry (VCR) sin guardar credenciales de larga duración en el repositorio. El flujo es directo: la acción intercambia el token OIDC del workflow por un token de acceso de Vercel de vida corta, lo usa para hacer login en vcr.vercel.com, y cuando el job termina lo revoca.

Según el changelog de Vercel, la acción autentica a Docker por defecto, pero acepta el parámetro engines para usar Podman o Buildah en lugar del primero. La imagen ya preparada puede consumirse después como imagen personalizada de Vercel Sandbox dentro del mismo proyecto, referenciándola como <repositorio>:<tag>.

Por qué importa: el problema de los secretos de larga duración

Hasta ahora, subir una imagen a un registry privado desde GitHub Actions implicaba generar un token de larga duración y guardarlo como secret en el repo. Ese modelo tiene un riesgo conocido y repetidamente explotado: cualquier compromiso del workflow, de un action de terceros o del propio runner puede filtrar esas credenciales en los logs o en artefactos.

BleepingComputer documentó en 2025 un ataque a la cadena de suministro sobre la acción tj-actions/changed-files, usada por unas 23.000 repos, en el que un commit malicioso dumpeó secretos del runner en logs de workflows de proyectos públicos (CVE-2025-30066). TechTarget recogió el mismo caso y añadió el detalle clave que justifica el enfoque de Vercel: según Matt Moore, CTO de Chainguard, los atacantes exfiltraron credenciales de los principales clouds, tokens de GitHub de larga duración y claves de firma. La recomendación recurrente fue exactamente la que Vercel acaba de implementar: dejar de usar credenciales de larga duración donde sea posible.

En esa misma línea, CSO Online reportó esta semana cómo repos de organizaciones expertas en seguridad como MITRE y Splunk exponían credenciales por workflows mal configurados, incluso con la trivía pull_request_target ejecutando código no confiable con acceso a todos los secretos del repo (CVE-2025-47928). El patrón de fallo no es el modelo de Vercel ni el de GitHub, sino confiar en secretos persistentes dentro del pipeline.

Qué necesitas para activarlo en tu repo

El changelog lista tres requisitos previos. No son opcionales: saltarse cualquiera de ellos rompe el handshake OIDC.

• Política OIDC en el equipo de Vercel que matchee el repositorio y workflow de GitHub y conceda acceso de lectura y escritura a VCR. Se crea desde la pantalla de Build and Deployment del equipo en Vercel.
• Variables del repositorio en GitHub con al menos VERCEL_TEAM_ID, el slug del equipo, el slug del proyecto y el nombre del repositorio que se usará en el tag de la imagen.
• Permiso id-token: write en el workflow o en el job concreto, necesario para que GitHub emita el token OIDC.

El paso de login es el ejemplo mínimo del changelog: tras actions/checkout y docker/setup-buildx-action, invocas vercel/vcr-action/login@v1 con team: ${{ vars.VERCEL_TEAM_ID }} y luego docker/build-push-action@v6 con la imagen apuntando a vcr.vercel.com/<team>/<project>/<repo>:latest. La acción se encarga del login y del logout; el tag y la compresión (zstd, nivel 3) los controlas tú.

Qué significa esto para tu startup

Si hoy despliegas imágenes custom a Vercel Sandbox o a cualquier otro destino que dependa de VCR, esta acción te quita una de las tareas más ingratas del pipeline: rotar secretos cada vez que un dev deja el equipo, cada vez que GitHub te avisa de un leak en un push, o cada vez que auditas quién tiene acceso al registry. Pasar a OIDC significa que la credencial deja de existir antes de que un atacante pueda reutilizarla.

Hay dos acciones concretas que puedes aplicar esta semana:

• Audita qué credenciales de larga duración viven en tus repos de GitHub. Empieza por docker/login-action@v3 con username y password: cada uno de esos pares es un candidato a migrar a OIDC. La guía oficial de Vercel es el punto de partida; si usas AWS o GCP desde el mismo runner, el equivalente (aws-actions/configure-aws-credentials con role-to-assume o google-github-actions/auth) sigue el mismo patrón y puedes atacarlos en la misma sprint.
• Pinea las acciones externas por SHA completo, no por tag. Vercel lo hace en su propio ejemplo (vercel/vcr-action/login@v1 debería seguirse de @<sha> en producción). La auditoría de tj-actions/changed-files mostró que los tags pueden ser reescritos retroactivamente: el pin por commit es la segunda capa de defensa que necesitas junto con OIDC.

Si todavía no usas Vercel Container Registry pero tu equipo necesita Sandboxes con dependencias pesadas (modelos, binarios propietarios, bases de datos embebidas), este flujo baja la barrera de entrada: ahora puedes construir la imagen en CI y empujarla a VCR sin que alguien del equipo tenga que generar tokens manualmente ni rotarlos cuando alguien rota.

Fuentes

• Vercel changelog: push images to VCR from GitHub Actions (fuente original)
• BleepingComputer: supply chain attack on popular GitHub Action exposes CI/CD secrets
• TechTarget: GitHub Actions supply chain attack spotlights CI/CD risks
• CSO Online: GitHub Actions attack renders even security-aware orgs vulnerable