GitHub lanza Package Firewall en fase previa para Enterprise Cloud
GitHub ha abierto la vista previa pública de Package Firewall para bloquear software malicioso durante la instalación de dependencias, aunque solo está disponible para GitHub Enterprise Cloud y actualmente solo admite npm.
GitHub anunció el 20 oct 2026 en su blog oficial el lanzamiento en fase previa (public preview) de su cortafuegos de paquetes (Package Firewall). Se trata de una capa de inspección en línea pensada para neutralizar scripts maliciosos cuando los equipos de desarrollo, los ejecutores de CI o los agentes de programación instalan dependencias de software. El acceso está abierto para toda la clientela de GitHub Enterprise Cloud (GHEC), incluidas las organizaciones con residencia de datos local.
Quién puede usarlo y cómo se factura
Package Firewall no está al alcance de todas las cuentas de GitHub. Su uso queda restringido a las organizaciones suscritas a GitHub Enterprise Cloud, por lo que las cuentas individuales (Free y Pro) y los planes GitHub Team quedan fuera del soporte.
| Plan | Compatibilidad con Package Firewall | Precio en fase previa | Precio en disponibilidad general (GA) | Ecosistemas admitidos |
|---|---|---|---|---|
| GitHub Free / Team | No disponible | No aplica | No aplica | No aplica |
| GitHub Enterprise Cloud (GHEC) | Disponible (incluye residencia de datos) | Gratuito | Pago por uso (previsto) | npm (único disponible) |
Durante este periodo de prueba pública, el servicio no tiene coste adicional. GitHub ha indicado que, cuando alcance la disponibilidad general (GA), adoptará un modelo de facturación basado en el consumo, similar al esquema de GitHub Actions. Las tarifas exactas y la fecha de lanzamiento definitivo todavía no se han publicado.
Qué inspecciona y cuáles son sus límites actuales
Las herramientas habituales de seguridad en la cadena de suministro de software suelen actuar tras la confirmación de cambios (post-commit), ya sea analizando repositorios o enviando alertas de vulnerabilidad. Sin embargo, cada vez más ataques aprovechan los propios ganchos de instalación (como los scripts preinstall) para sustraer credenciales y variables de entorno antes de que el código del proyecto llegue a ejecutarse. Los agentes de código autónomos y los ejecutores de CI resultan especialmente vulnerables a esta técnica, ya que instalan dependencias de forma automática para completar sus tareas.
Package Firewall se ubica entre los puntos de conexión y el registro público oficial (registry.npmjs.org), donde examina en tiempo real tanto los metadatos como los archivos descargados (tarballs). El equipo de administración puede activar cuatro reglas esenciales:
- Bloqueo de malware conocido: descarta al instante los paquetes catalogados como dañinos en la base de datos GitHub Advisory Database.
- Filtrado por alertas de vulnerabilidad: restringe las versiones afectadas por fallos de seguridad reportados que superen un umbral de gravedad configurado (como crítico o alto).
- Control de degradación de atestados (attestations): si una versión previa contaba con un atestado criptográfico de procedencia (la garantía de una compilación verificada) y la nueva versión solicitada carece de él, se bloquea la actualización por sospecha de manipulación.
- Periodo de enfriamiento (cooldown): retiene temporalmente las versiones recién publicadas para que la comunidad de código abierto disponga de margen para detectar y notificar anomalías.
La limitación más relevante radica hoy en su alcance: Package Firewall solo admite paquetes npm. Otros registros de uso masivo como PyPI (Python), Maven (Java) o Cargo (Rust) no pueden canalizarse a través de este filtro por el momento.
Configuración y riesgos del flujo de excepciones
Para poner en marcha esta protección, el equipo de administración activa la política correspondiente en el panel de la empresa y redirige la configuración del gestor de paquetes (.npmrc) en los equipos y ejecutores de CI hacia la dirección del cortafuegos.
En caso de que un paquete interno legítimo o una versión urgente queden bloqueados por error (falso positivo), la consola o el registro de CI proporcionan un enlace directo para solicitar una excepción. El personal de desarrollo puede justificar la petición a través de ese enlace, y el equipo de seguridad revisará y aprobará el caso mediante un flujo similar al de GitHub Advanced Security (GHAS).
No obstante, en entornos donde operan decenas de agentes autónomos en paralelo, un falso positivo puede congelar por completo un proceso de integración continua hasta que una persona revise la solicitud de forma manual. Un periodo de enfriamiento excesivamente amplio también puede retrasar las actualizaciones habituales. Por ello, conviene comenzar con plazos breves y designar con antelación a las personas responsables de validar estas excepciones.
Aspectos a seguir en adelante
GitHub ha manifestado su intención de ampliar la infraestructura y sumar capacidades según la respuesta de las empresas usuarias. La extensión del cortafuegos hacia otros registros como PyPI y el impacto económico del modelo de pago por uso en los presupuestos de CI marcarán la pauta en cuanto el servicio esté listo para producción.
Fuentes
- GitHub package firewall in public preview (The GitHub Blog)
- Protecting endpoints with package firewall (GitHub Docs)
Fuente: github.blog