GitHub Package Firewall: controles npm antes de la instalación

GitHub ha presentado un package firewall para npm: un control que compara cada paquete con la política de la empresa antes de que se instale y bloquea malware conocido, vulnerabilidades críticas y versiones publicadas hace demasiado poco. Lo han contado heise Security el 23 de octubre, Help Net Security el 28 y The Hacker News el 29 de octubre de 2026. Los detalles técnicos que siguen proceden de Help Net Security, que también recogió las respuestas de dos responsables de producto de GitHub.

El firewall es una de cuatro novedades de seguridad que GitHub relaciona con el crecimiento del software escrito con ayuda de agentes de IA. El objetivo declarado es detectar los problemas antes de que un paquete llegue al portátil de un desarrollador, a una build o al entorno de un agente de programación.

Cómo funciona el firewall

Según Help Net Security:

• el control se hace en el momento de la instalación, comparando el paquete solicitado con una política definida a nivel de enterprise;
• los criterios de bloqueo son tres: malware conocido, vulnerabilidades críticas y versiones recién publicadas;
• cualquier desarrollador puede activarlo apuntando npm hacia el firewall: en la práctica, los paquetes ya no llegan directamente del registro, sino que pasan por el filtro.

Para decidir si una versión es «demasiado nueva», explicó Adam Leftik de GitHub, el firewall usa la fecha de publicación que figura en los metadatos del paquete, que es responsabilidad del gestor de paquetes. Las empresas pueden modificar las reglas y crear políticas personalizadas con un periodo de espera (soak time o cool-down) antes de que una nueva versión se pueda instalar.

Las fuentes disponibles no describen la configuración exacta, la disponibilidad en los distintos planes de GitHub ni las posibles licencias necesarias, y solo hablan de npm.

Por qué importa el periodo de espera

En nuestra lectura, el criterio sobre las versiones nuevas es el más interesante. Una versión maliciosa de un paquete legítimo, publicada con credenciales robadas o aprovechando una debilidad del proceso de publicación (como en el caso SlugFest de npm Trusted Publishing, de este mes), es más peligrosa en las primeras horas y los primeros días, antes de que se denuncie y se retire. Un periodo de espera reduce esa ventana; el bloqueo del malware conocido cubre las versiones ya identificadas. La técnica MITRE ATT&CK de referencia es T1195.001 (Compromise Software Dependencies and Development Tools).

Algunos límites que conviene tener en cuenta, también en nuestra lectura:

• el filtro solo protege las instalaciones que pasan por el firewall: un puesto de trabajo, un job de CI o un agente configurados de otra forma lo eluden;
• el periodo de espera también retrasa las correcciones de seguridad urgentes, que necesitan un procedimiento de excepción;
• el criterio sobre las versiones nuevas depende de que las fechas de los metadatos sean correctas, como precisa la propia GitHub.

Las otras novedades anunciadas

Help Net Security describe también las otras tres novedades, que trabajan sobre el código y las alertas:

• AI Scan analiza cada pull request en busca de vulnerabilidades en los lenguajes que el análisis basado en reglas no cubre, entre ellos PHP, Shell y COBOL. También puede analizar un repositorio completo bajo demanda, llegando al código ya fusionado;
• la extensión GitHub Security para la app de Copilot revisa los cambios del desarrollador antes de que exista una pull request; junto con GitHub Code Security lleva a la app las alertas de code scanning, incluidas las de AI Scan;
• el análisis de alcanzabilidad para las alertas de Dependabot comprueba si el código llama de verdad a la función vulnerable de una dependencia: la ruta de llamada se consulta en GitHub y las alertas se pueden ordenar según ella.

Para las correcciones, Pierre Tempel de GitHub mencionó tanto las sugerencias de corrección en las pull requests como Agentic Autofix, que corrige alertas en bloque en todas las herramientas de GitHub y en más de 70 herramientas de socios.

Impacto para las empresas europeas e italianas

npm es el registro de referencia para JavaScript y TypeScript y alimenta aplicaciones web, herramientas de desarrollo y pipelines de build en la mayoría de las empresas que desarrollan software. Un paquete comprometido ejecuta código en los puestos de los desarrolladores y en los runners de CI, donde están tokens, claves y accesos a los sistemas de producción. Los agentes de IA de programación aumentan el número de instalaciones hechas sin revisión humana.

Para las entidades sujetas a NIS2, la seguridad de la cadena de suministro y del desarrollo está entre las medidas exigidas: un filtro con reglas escritas, aplicado en el momento de la instalación, es una medida concreta y documentable, siempre que cubra de verdad todos los puntos desde los que se instalan paquetes.

Qué hacer ya

1. Si usas GitHub Enterprise, consulta en la documentación de GitHub la disponibilidad y los requisitos del package firewall para tu plan: las fuentes no los indican.
2. Define la política: bloqueo de malware conocido y vulnerabilidades críticas, un periodo de espera para las versiones nuevas y un procedimiento de excepción, con un responsable, para los parches de seguridad urgentes.
3. Haz obligatorio el paso por el firewall: configura npm de forma centralizada en los repositorios, los runners de CI, las imágenes de contenedores y los entornos de los agentes de IA. Donde sea posible, impide que las redes de build accedan directamente al registro público, para que el filtro no se pueda eludir.
4. Mantén las defensas básicas: versiones fijadas con el archivo de lock, instalaciones con npm ci en las pipelines y, donde sea posible, scripts de instalación desactivados (--ignore-scripts).
5. Usa la alcanzabilidad para fijar prioridades, no para cerrar alertas: una dependencia vulnerable que hoy no se llama puede llamarse mañana.

Cómo ayuda ARXDOME

ARX Sentry recoge el inventario de software y procesos de ordenadores y servidores: te ayuda a saber dónde se ejecutan Node.js, npm y los agentes de programación y, por tanto, qué máquinas deben respetar la política. ARX Shield muestra las vulnerabilidades abiertas por máquina y por paquete y, si una máquina ha instalado una versión sospechosa, permite aislarla de la red mientras se hacen las comprobaciones.

Última actualización: 29 de octubre de 2026