GitHub endurece npm y Actions por defecto: lo que cambia en tu pipeline
# GitHub endurece npm y Actions por defecto: lo que cambia en tu pipeline
Durante los últimos tres años, los ataques a la cadena de suministro del ecosistema JavaScript han seguido un guion predecible y deprimente. Un mantenedor con derechos de publicación sobre un paquete de alto tráfico recibe un phishing. Sus credenciales, incluido un código de 2FA de un solo uso, se reenvían en tiempo real al atacante. En cuestión de minutos, una versión envenenada de `chalk`, `debug` o `nx` aterriza en npm y es consumida por miles de millones de descargas semanales antes de que el mantenedor siquiera note el correo de restablecimiento de contraseña. La respuesta de GitHub, anunciada a finales de agosto de 2026 y detallada por el ingeniero principal de seguridad de producto Greg Ose y el ingeniero principal de software Zachary Steindler, consiste en eliminar las asunciones que hicieron funcionar ese guion — no parchando una vulnerabilidad, sino cambiando los valores por defecto de las dos superficies que más importaban: el propio npm y GitHub Actions.
Este artículo recorre cada valor por defecto que cambió, explica por qué importa cada uno y te da una lista de comprobación concreta de qué verificar en tus propios pipelines esta semana.
La protección de npm en modo solo lectura
El cambio más importante es invisible hasta que se activa. Cualquier cuenta de npm que GitHub clasifique como de "alto impacto" — es decir, cuentas que publican paquetes que en conjunto reciben más de un millón de descargas semanales, o que mantienen paquetes que son dependencias directas de los mil paquetes más descargados del registro — entra ahora en modo solo lectura durante setenta y dos horas tras dos eventos concretos: cambiar la dirección de correo electrónico principal de la cuenta, o utilizar un código de recuperación de 2FA.
El razonamiento es directo. El ataque a chalk/debug de septiembre de 2025 comenzó con un correo de phishing haciéndose pasar por soporte de npm. El mantenedor, Josh Junon, introdujo sus credenciales y un código TOTP reciente en un portal fraudulento en `npmjs[.]help`. Los atacantes capturaron ambos en tiempo real y publicaron versiones maliciosas de al menos dieciocho paquetes en dieciséis minutos. Ninguno de los análisis post-mortem identificó una manera de hacer que el propio TOTP fuera resistente a este tipo de phishing con adversario-en-el-medio — el protocolo funcionaba exactamente como estaba diseñado, y el atacante simplemente reenvió el desafío en tiempo real. La defensa tiene que vivir en otra capa.
El modo solo lectura es la respuesta de GitHub. Durante la ventana de setenta y dos horas, la cuenta no puede publicar nuevas versiones, no puede añadir nuevos mantenedores y no puede rotar tokens de publicación. El mantenedor todavía puede iniciar sesión, examinar su lista de paquetes y retirar versiones maliciosas — pero no puede publicar de nuevo por accidente mientras la amenaza sigue activa. Si el atacante logró publicar durante la toma de control, el camino de retirada es lo único que limita el radio de explosión. La espera de setenta y dos horas hace que esa ventana sea lo bastante larga para usarla de verdad.
Para los ingenieros de plataforma que ejecutan mirrors internos o registros privados, este cambio tiene un efecto colateral: si tu organización tiene una única cuenta de npm usada para publicar bibliotecas internas compartidas en un registro privado, casi con total seguridad esa cuenta es de "alto impacto" según la definición anterior. Debes esperar que el comportamiento de solo lectura se active la próxima vez que alguien rote la contraseña o se recupere de un autenticador perdido. Hornea esa espera en tu proceso de release. Si tu equipo trata la publicación en npm como una acción urgente que tiene que ocurrir minutos después de un merge, estás a punto de tener un martes muy malo.
El cambio de valor por defecto en actions/checkout
El segundo cambio de valor por defecto está en la acción que casi todo workflow ejecuta primero: `actions/checkout`. Durante años, la acción hacía checkout del contenido de la ref que disparaba el workflow por defecto, incluidos los pull requests de forks. Combinado con `pull_request_target` — un disparador que se ejecuta con permisos de escritura y acceso a secretos — esta combinación se convirtió en la receta estándar para una clase de ataque en la que un contribuidor externo envía un pull request, el workflow hace checkout de la cabeza del PR, y la cabeza del PR resulta contener un `.github/workflows/exfiltrate.yml` o un `package.json` con un script `preinstall` malicioso.
El nuevo valor por defecto de `actions/checkout` es que los workflows ya no hacen checkout de código de fork no confiable bajo los disparadores comúnmente explotados (`pull_request_target` desde forks, `workflow_run` desde forks) a menos que el equipo lo habilite explícitamente poniendo `persist-credentials: false` y reactivando el checkout manualmente. El cambio se portó a la línea 4.x antigua de la acción, así que aplica a pipelines que tenían pineada una versión anterior.
El efecto práctico es que la larga cola de pipelines de GitHub Actions que no se han auditado en el último año — y hay millones — se volvió silenciosamente más segura el día que cambió el valor por defecto. Los auditores que busquen el patrón clásico de `pull_request_target` + checkout de `github.event.pull_request.head.sha` encontrarán que la acción ahora se niega a hacer el checkout peligroso a menos que el autor del workflow haya abierto una excepción explícita.
Para los equipos que genuinamente necesitan ejecutar código de fork no confiable en un contexto privilegiado — por ejemplo, para construir un entorno de previsualización para una contribución externa — el patrón correcto no ha cambiado: ejecuta el código no confiable en un trabajo sandboxed sin secretos, sin permisos de escritura y con una allowlist de salida de red. El nuevo valor por defecto simplemente elimina la trampa para los equipos que no sabían que la tenían.
Políticas de ejecución de workflows
Una nueva primitiva de gobernanza, las políticas de ejecución de workflows, ofrece a los administradores de la organización una forma de restringir qué workflows pueden ejecutarse, quién puede dispararlos y qué tipos de disparador están permitidos. La política se define a nivel de organización y se evalúa antes de que el workflow arranque. Una política puede exigir, por ejemplo, que cualquier workflow disparado por un evento `pull_request_target` también pinee las versiones de las acciones a un SHA y no haga referencia a ninguna acción de terceros que no esté en la allowlist.
El modelo es deliberadamente conservador. Si un workflow viola la política, no se ejecuta en absoluto — la acción falla con un mensaje de error claro que nombra la política violada, no un éxito silencioso ni un error críptico de parseo YAML. Esta es una diferencia significativa frente a la guía previa de "esfuerzo de buena voluntad", que era una página de wiki.
Para los equipos de plataforma que están desplegando esto, el orden de migración importa. Empieza con una política que lo permita todo (un modo solo-auditoría) para ver qué workflows se habrían bloqueado. Después activa el bloqueo en organizaciones de no-producción. Luego actívalo en producción con una lista de exenciones para casos límite conocidos. Saltar directamente al bloqueo en producción es una receta para una caída cuyo origen sea un workflow que nadie recuerda quién mantiene.
El camino del envenenamiento de caché está cerrado
La caché de Actions ha sido una fuente silenciosa de riesgo de cadena de suministro durante años. Un workflow que usa `actions/cache` para persistir `node_modules` o artefactos de build entre ejecuciones confía implícitamente en lo que haya en esa caché. Si un atacante puede envenenar la caché — por ejemplo, disparando un workflow con una ref que escribe un binario malicioso en una ruta que la siguiente ejecución lee — puede conseguir que su código se ejecute en un contexto que confía en la clave de caché.
El nuevo valor por defecto hace que la caché de Actions sea de solo lectura para disparadores no confiables. Los pull requests de forks y los contribuidores externos ya no pueden escribir en la caché, solo leer de ella. El camino de envenenamiento de caché que se llevaba discutiendo en canales privados de seguridad desde al menos 2023 está ahora cerrado por defecto.
El impacto operativo es pequeño para la mayoría de los equipos. La caché sigue funcionando como caché de lectura para forks, y los contribuidores internos todavía pueden poblarla. Los únicos workflows que lo notarán son los que dependían explícitamente de que un fork contribuyera a la caché, que es un patrón inusual y casi siempre un error.
Trusted publishing y CircleCI
El trusted publishing es la parte de la estrategia de GitHub que no solo cambia valores por defecto sino que elimina clases enteras de credenciales del pipeline. En lugar de almacenar un `NPM_TOKEN` de larga duración en los secretos del repositorio, el trusted publishing usa OIDC para emitir un token de corta duración en el momento de la publicación, scoped al workflow específico que lo solicitó y al paquete específico que se está publicando. El token nunca existe fuera del paso de publish y no puede ser exfiltrado por un compromiso separado del almacén de secretos del repositorio.
Hasta agosto de 2026, el trusted publishing en npm estaba soportado para GitHub Actions, GitLab CI y un puñado de proveedores menores. El nuevo lanzamiento añade CircleCI, cerrando la brecha para los equipos que se estandarizaron en CircleCI antes de adoptar GitHub Actions y no han podido eliminar sus secretos `NPM_TOKEN` por esa razón. La migración es directa: en la configuración del paquete en npm, añade CircleCI como trusted publisher, configura el context y el project ID correspondientes en la configuración OIDC de CircleCI, y elimina el secreto `NPM_TOKEN` del context de CircleCI.
El comentario más útil del hilo original en InfoQ, de un mantenedor con el alias pimterry, captura la lógica de seguridad de forma sucinta: "El staged publishing confiable ayuda mucho: tienes que comprometer independientemente el workflow _y_ entonces completar un flujo separado de 2FA como mantenedor. El workflow nunca ve claves que puedan publicar de forma independiente." Esa es la propiedad que importa. Una identidad de workflow robada por sí sola no basta. El atacante todavía tiene que convencer a un humano de completar un segundo factor en el momento de la publicación, que es lo que impone el staged publishing.
El firewall de red de Actions
En preview técnica desde el anuncio está el firewall de red de Actions, que registra el tráfico saliente de las ejecuciones de workflows. El firewall no bloquea por defecto — eso rompería demasiados workflows existentes que bajan imágenes de registros públicos o llaman a APIs de despliegue. Lo que hace es producir un registro auditable de cada destino saliente que alcanza un workflow, indexado por workflow, job y step. El caso de uso es detección, no prevención: un workflow que de repente empieza a llamar a un rango de IPs desconocido o a resolver un dominio desconocido es una señal fuerte de que algo va mal.
Para los equipos de seguridad que ya operan un SIEM, la salida del firewall puede reenviarse a un destino de logs personalizado. Para los equipos que no, la UI de GitHub muestra los outliers más relevantes directamente en la página de ejecución del workflow. La preview es gratuita durante el periodo de preview y se tarifará por ejecución de workflow cuando llegue a disponibilidad general, aunque GitHub aún no ha anunciado el precio de la GA.
Qué deben hacer los ingenieros de plataforma esta semana
Los cambios son valores por defecto, lo que significa que aplican a workflows nuevos y a workflows que se han tocado recientemente. Los workflows dormidos durante mucho tiempo en repositorios que no han visto un push en meses pueden seguir con el comportamiento antiguo. Una lista corta de auditoría:
1. Encuentra cada workflow en tu organización que use `pull_request_target` y verifica que no haga checkout de código de fork con la configuración por defecto de `actions/checkout`. Si lo hace, opta explícitamente por no hacerlo o mueve el trabajo no confiable a un job sandboxed.
2. Encuentra cada paso de publish en npm en tu organización y verifica que el secreto en uso sea un token de trusted publishing de corta duración, no un `NPM_TOKEN` de larga duración. Si encuentras un token de larga duración, rótalo una vez que hayas migrado.
3. Activa las políticas de ejecución de workflows en modo solo-auditoría para al menos una organización y revisa el informe de violaciones. La salida es la forma más eficiente de encontrar la larga cola de workflows que se han desviado del cumplimiento.
4. Si operas un registro interno que es mirror de npm, verifica que la cuenta de servicio de tu mirror no esté clasificada como de alto impacto. Si lo está, asegúrate de que el equipo entiende la espera de setenta y dos horas.
La superficie de ataque de cadena de suministro del ecosistema JavaScript no encogió por un único parche. Encogió porque GitHub cambió las asunciones sobre las que varios años de ataques habían estado confiando silenciosamente. Los valores por defecto importan más que cualquier control opt-in individual, porque los valores por defecto alcanzan a los workflows que nadie tiene tiempo de auditar.