Ing. Calogero Bono
GitHub presentó el 20 de octubre de 2026 el package firewall, un filtro que se sitúa entre los equipos que instalan paquetes y los registros públicos de donde los descargan. Hoy está en vista previa pública para todos los clientes de GitHub Enterprise Cloud y solo admite npm. El objetivo es frenar el malware que ataca en el momento de la instalación, un riesgo mayor para los agentes de IA y los sistemas de compilación que instalan dependencias sin que nadie las revise. Si desarrollas software o diriges a quienes lo hacen, es una señal de hacia dónde va la seguridad de la cadena de suministro.
Algunos términos antes de entrar en los hechos. Un registro (o registry) es el depósito en línea de donde se descargan los paquetes, como npm para JavaScript. Una dependencia es una pieza de código ajeno que tu proyecto utiliza. Los CI/CD son los procedimientos automáticos que compilan y publican el software. Una attestation SLSA es una declaración verificable sobre cómo y por quién se construyó un paquete. Los metadatos son la información sobre el paquete, por ejemplo la lista de versiones disponibles.
¿Qué es el package firewall de GitHub?
Según el changelog oficial de GitHub, en los últimos tiempos ha habido una verdadera oleada de ataques de malware que aprovechan el momento en que se instalan los paquetes. Los agentes y los runners de CI son objetivos especialmente atractivos, porque instalan dependencias para completar una tarea o una compilación sin que una persona intervenga.
El firewall se sitúa entre los endpoints, o los registros internos, y los repositorios de paquetes de origen. Como recoge The Hacker News, GitHub lo describe así. «The firewall inspects both metadata requests and package downloads for signs of malicious activity, acting as an install-time policy gate», es decir, una barrera de reglas aplicadas en el momento de la instalación.
El tema no es teórico. El sitio The Register publicó un titular sobre una campaña en la que los atacantes habrían convertido las incidencias de GitHub en un ataque a la cadena de suministro contra 61 repositorios públicos en menos de una hora. De la página que tenemos a disposición no se desprenden más detalles, así que no podemos decir si las dos noticias están relacionadas ni cómo.
¿Cómo funciona y qué controles ofrece?
El flujo tiene dos pasos. Primero los administradores configuran las reglas para su enterprise. Después, los agentes de programación y los hosts de CI/CD apuntan al firewall en lugar de hacerlo directamente a los registros públicos. Tanto las solicitudes de metadatos como las descargas pasan por el firewall, que las evalúa según la política definida.
Los controles disponibles
Según la lista de The Hacker News, estos son los controles disponibles.
- Bloqueo del malware conocido, comprobando los avisos activos en la GitHub Advisory Database.
- Bloqueo por gravedad de las vulnerabilidades, también a través de la base de datos. La opción predeterminada bloquea solo el nivel «Critical only», pero se puede elegir «High or higher», «Medium or higher» o «Any severity».
- Bloqueo de downgrades de attestation. El firewall compara las attestation de la versión solicitada con las de las versiones anteriores y detiene la descarga si falta la attestation SLSA.
- Bloqueo de los nuevos scripts de instalación, es decir, los que se ejecutan con los hooks preinstall o postinstall y pueden usarse para robar datos sensibles.
- Periodo de espera (cooldown), que impide instalar versiones más recientes que la edad mínima configurada.
El cooldown puede ir de 1 a 365 días. El valor predeterminado es 1 día y se desactiva poniéndolo en 0.
¿Y si bloquea un paquete bueno?
Si un paquete se bloquea por error, el usuario puede solicitar una excepción. En GitHub el procedimiento es parecido al de otras funciones de GitHub Advanced Security. Según The Hacker News, la solicitud puede ser aprobada por los administradores y los responsables de seguridad de la enterprise.
¿Cuánto cuesta y quién puede usarlo?
El servicio está disponible en vista previa pública para todos los clientes de GitHub Enterprise Cloud, incluida la versión con residencia de datos. Durante la vista previa es gratuito. Cuando llegue la disponibilidad general, GitHub anuncia que será de pago según el consumo medido, de forma parecida a la facturación de Actions.
GitHub explica que la vista previa sirve para hacer crecer la infraestructura y añadir funciones según lo que pidan los clientes. Para las instrucciones de configuración remite a la documentación Protecting endpoints with package firewall.
¿Por qué se habla tanto de los periodos de espera?
El cooldown es la regla más sencilla y quizá la más extendida. The Hacker News recuerda que en el último año se han introducido esperas similares en npm, Python, Visual Studio Code, Ruby, Bun, pnpm y Yarn. El principio es reducir la probabilidad de que una versión recién publicada y nunca revisada acabe de inmediato en una compilación.
Ayuda sobre todo frente a quien toma el control de la cuenta de un mantenedor y publica una versión envenenada de un paquete popular. La espera frena la difusión rápida, manual o automática.
El mismo artículo señala que Rust 1.100, que saldrá el 12 de noviembre de 2026, debería añadir una edad mínima de publicación configurable para los crates. La opción se llama «global-min-publish-age» y se encuentra en el archivo cargo/config.toml. Si no se especifica, se aplica una espera predeterminada de siete días.
En el otro lado de la moneda habla Socket, citada por The Hacker News. «The tradeoff is that legitimate fixes have to wait, too, unless developers make an exception», afirma la empresa. Añade que una publicación que ha escapado a los controles puede simplemente sobrevivir al cooldown. El valor, según Socket, está en dar tiempo a investigadores, mantenedores y registros para intervenir.
Límites que debes conocer
- Por ahora el firewall solo admite npm. Quien trabaja con PHP, Python u otros ecosistemas no está cubierto, y las fuentes no indican fechas para otros registros.
- Está reservado a los clientes de GitHub Enterprise Cloud. Las fuentes no hablan de planes más pequeños.
- Estamos en vista previa. Funciones, infraestructura y precios pueden cambiar, y el coste por consumo todavía no está cuantificado.
- No tenemos datos independientes sobre su eficacia. Las fuentes recogen las declaraciones de GitHub, no pruebas con malware real, y no se mencionan cifras de falsos positivos.
- Como recuerda Socket, el cooldown no vuelve inofensivo el código malicioso. Una versión no detectada puede quedar oculta más allá de la espera.
Qué cambia para quien trabaja con tecnología digital
El punto práctico es que la seguridad pasa del control a posteriori al control previo a la instalación. Para quien desarrolla con agentes de IA que escriben e instalan por su cuenta, esto significa tener una regla central en lugar de confiar en cada agente por separado. Si usas herramientas de desarrollo guiadas por IA, conviene releer los riesgos que describimos en nuestro artículo sobre el vibe coding para la PYME.
Para las empresas italianas el tema también toca la conformidad. La cadena de suministro del software forma parte de lo que tratamos en la guía sobre el registro de proveedores NIS2. Poder demostrar que los paquetes pasan por un filtro con reglas escritas es un argumento concreto, aunque ninguna fuente relaciona el firewall con la NIS2.
Quien usa mucho código abierto debería recordar que cada dependencia es un proveedor. Hablamos de ello en el análisis sobre código abierto en la empresa. Incluso quien no es cliente Enterprise puede copiar la idea con las herramientas ya disponibles, por ejemplo los periodos de espera que ofrecen algunos gestores de paquetes.
En los servidores de compilación y de producción también importan las actualizaciones y el aislamiento. Si quieres una infraestructura gestionada por otros, tienes nuestro servicio de hosting y servidores gestionados. Si en cambio estás valorando un proyecto a medida, encontrarás el camino en el desarrollo de software a medida.
Nuestra opinión
La idea es acertada. Frenar un paquete antes de que se ejecute en el equipo es más eficaz que darse cuenta después, y hacerlo en un punto único evita depender de la disciplina de cada desarrollador o de cada agente. Que GitHub parta precisamente de los agentes sin supervisión nos parece una lectura honesta del problema.
Las reservas son dos. La primera es comercial. Una protección tan útil, por ahora reservada al plan Enterprise y de pago por consumo tras la vista previa, corre el riesgo de dejar desprotegidos a los equipos pequeños, que suelen ser los más expuestos. La segunda es técnica. Muchos controles se apoyan en la base de datos de GitHub y en el tiempo, y el tiempo no es una garantía, como admite la propia Socket.
Por eso no lo vemos como un escudo definitivo. Es una capa más, útil si se acompaña de revisión de dependencias, bloqueo de versiones y permisos mínimos para los agentes. Si crees que basta con activar el firewall, te estás dando una falsa sensación de seguridad.
Preguntas frecuentes
¿El package firewall de GitHub es gratuito?
Sí, pero solo durante la vista previa. GitHub anuncia que, con la disponibilidad general, se cobrará según el consumo medido, de forma parecida a Actions. Los precios todavía no se han publicado.
¿Funciona solo con npm?
Sí, por ahora admite únicamente paquetes npm. Las fuentes no anuncian fechas para otros ecosistemas. Si usas otros lenguajes, de momento tendrás que buscar otras defensas.
¿Quién puede usarlo?
Todos los clientes de GitHub Enterprise Cloud, incluida la versión con residencia de datos. Las fuentes no mencionan otros planes. Los administradores configuran las reglas para toda la enterprise.
¿Qué pasa si bloquea un paquete legítimo?
El usuario puede solicitar una excepción. Según The Hacker News, la solicitud puede ser aprobada por administradores y responsables de seguridad. El procedimiento, según GitHub, es parecido al de otras funciones de Advanced Security.
¿El periodo de espera basta para frenar el malware?
No. Ayuda a ganar tiempo frente a las versiones recién publicadas, pero Socket recuerda que el código malicioso no se vuelve inofensivo con el paso del tiempo. Una publicación no detectada puede superar la espera.
Qué seguir hasta la disponibilidad general
En los próximos meses conviene seguir tres cosas. El precio por consumo que fijará GitHub, una posible ampliación más allá de npm y la llegada de la espera mínima en Rust 1.100, prevista para el 12 de noviembre de 2026. Mientras tanto, puedes empezar así.
- Haz una lista de las dependencias que usan CI y agentes, y decide quién puede instalar qué sin supervisión.
- Valora un periodo de espera para las nuevas versiones, sabiendo que también retrasa las correcciones legítimas.
- Prepara un procedimiento para las excepciones, con un responsable que apruebe con rapidez pero dejando constancia por escrito.
