Malware que ataca al instalar, y lo que revisa el cortafuegos de GitHub

Solemos pensar en una dependencia maliciosa como código que hace daño cuando la aplicación lo ejecuta. Lo que GitHub señala en su anuncio del 20 de octubre de 2026 es que cada vez más ataques no esperan tanto: actúan mientras el paquete se instala y se llevan credenciales del runner de CI o del portátil del desarrollador, sin que tu aplicación ejecute nunca una línea del paquete. Cuando arranca el primer test, el token ya se ha ido. La respuesta de GitHub es un cortafuegos de paquetes, ahora en vista previa pública, y conviene saber tanto lo que hace como lo estrecho que es todavía su alcance.

Qué inspecciona el cortafuegos

Según la descripción de GitHub, el cortafuegos se coloca entre tus endpoints, es decir, los runners de Actions y los agentes de código, y el registro de origen, y mira tanto las peticiones de metadatos como las descargas de paquetes. Hoy las políticas son un periodo de espera configurable, una comprobación contra la GitHub Advisory Database en busca de alertas de malware y vulnerabilidades, y controles de cadena de suministro como la degradación de atestaciones. Cada endpoint tiene que configurarse para usar el cortafuegos en lugar del registro directo, y si un paquete se bloquea por error puedes pedir una excepción.

Qué no cubre

Ten claro el alcance antes de planificar en torno a él. GitHub dice que la vista previa es para clientes de GitHub Enterprise Cloud, incluida la residencia de datos, y que de momento solo admite paquetes npm. Así que en un plan Free o Team no lo tienes, y en un proyecto PHP nada de tu instalación con Composer pasa por él. Es gratuito durante la vista previa, y GitHub dice que más adelante se cobrará por uso de forma parecida a Actions.

La parte de publicación también se endureció ese mes

Dos cambios de npm del 2 de octubre empujan desde el otro extremo. npm stage publish ya puede crear un paquete totalmente nuevo: la primera versión entra en una cola de staging y un mantenedor tiene que promoverla antes de que nadie pueda instalarla. Además, las configuraciones de trusted publishing no validadas caducan ahora 48 horas después de crearse, lo que reduce el riesgo de confiar en un nombre de repositorio o de proyecto que más tarde cambia de dueño. Una configuración queda validada con su primera publicación correcta. npm también rechaza ya los tokens de trusted publishing que vienen de eventos de workflow issue_comment, además de la restricción que ya existía para pull_request_target; npm recomienda usar push, release o workflow_dispatch en su lugar.

Qué puedes hacer con cualquier plan

Esta parte es una recomendación general, no una afirmación sobre el cortafuegos. Sube tus lockfiles al repositorio e instala a partir de ellos: npm ci en JavaScript, composer install contra composer.lock en PHP. Pasa una comprobación de avisos en CI. --ignore-scripts se salta los scripts de ciclo de vida de npm, pero no es una defensa completa, porque los ataques en la instalación no siempre son scripts y algunos paquetes los necesitan de verdad. Un periodo de espera manual consiste en no actualizar a una versión publicada en los últimos días, ya que la mayoría de las versiones maliciosas se detectan rápido. Y la capa que más importa: no ejecutes instalaciones en una máquina que guarde credenciales de larga duración.

npm ci
composer install --no-interaction
composer audit

Este sitio es Laravel con algo de tooling de JavaScript, así que el cortafuegos solo cubriría la mitad pequeña. En la parte PHP el equivalente es sencillo: instalar desde el composer.lock del repositorio, ejecutar composer audit en CI y no dejar entrar actualizaciones sin que alguien las lea. Si estás en Enterprise Cloud, apunta un solo runner al cortafuegos, mira durante una semana lo que bloquea y luego amplía. Fuente: GitHub Changelog, el cortafuegos de paquetes en vista previa pública.