GitHub ha anunciado la introducción de un nuevo firewall de paquetes, en fase de vista previa, que bloquea la instalación de paquetes npm sospechosos en el momento de la instalación. La herramienta actúa como una barrera de políticas en tiempo de instalación, inspeccionando tanto las solicitudes de metadatos como las descargas de paquetes en busca de signos de actividad maliciosa.
La funcionalidad, que por ahora solo admite paquetes npm, está disponible en vista previa pública para todos los clientes de GitHub Enterprise Cloud, incluidos los de datos residentes. Según la subsidiaria de Microsoft, el firewall se sitúa entre los endpoints o registros internos y los repositorios de paquetes upstream para frenar ataques de malware que comprometen sistemas al instalar paquetes.
Este comportamiento puede exponer a los usuarios a riesgos de seguridad graves, especialmente cuando agentes de inteligencia artificial (IA) y ejecutores de CI instalan dependencias automáticamente para completar una tarea o compilación sin permiso explícito. La idea es que endpoints como agentes de codificación y hosts de CI/CD utilicen el firewall para sus solicitudes en lugar de apuntar directamente a los registros públicos de paquetes. El firewall verifica las descargas contra controles de políticas como la antigüedad mínima del paquete y los avisos de malware, y bloquea aquellas que no cumplen dichas políticas.
Para usar el firewall, los administradores deben configurar controles de políticas como los siguientes:
- Bloquear malware conocido consultando la base de datos de avisos de GitHub en busca de alertas de malware activo.
- Bloquear paquetes según la gravedad de las vulnerabilidades, consultando la base de datos de avisos de GitHub para fallos que afecten a la versión solicitada. El control se establece por defecto en "Solo críticas" como nivel de gravedad que bloquea la instalación, aunque los usuarios pueden elegir "Altas o superiores", "Medias o superiores" o "Cualquier gravedad".
- Bloquear degradaciones de atestación comparando las atestaciones de la versión solicitada con las de versiones anteriores y detener la descarga si la versión solicitada no cuenta con una atestación SLSA.
- Bloquear scripts de instalación introducidos recientemente verificando si el paquete ha añadido scripts que se ejecutan mediante hooks preinstall o postinstall, los cuales pueden ser explotados para robar datos sensibles.
- Bloquear paquetes según un período de enfriamiento que impide instalar versiones más recientes que la antigüedad mínima configurada. El valor puede oscilar entre 1 y 365 días, con un valor predeterminado de 1 día. Los usuarios pueden desactivarlo estableciéndolo en 0.
Los usuarios que necesiten acceder a un paquete bloqueado erróneamente por el firewall pueden enviar una solicitud de excepción, que luego puede ser aprobada por los administradores de la empresa y los gerentes de seguridad.
Este desarrollo coincide con la preparación de Rust 1.100, cuya publicación está prevista para el 12 de noviembre de 2026, que añadirá soporte para una antigüedad mínima de publicación configurable, dando tiempo a los escáneres de seguridad y a los mantenedores para señalar y bloquear lanzamientos maliciosos de crates antes de que puedan instalarse o usarse. El valor, definido mediante la opción "global-min-publish-age" en "cargo/config.toml", permite especificar una antigüedad mínima de publicación en días o semanas. Si no se especifica, se aplica por defecto un período de espera de siete días para omitir las versiones publicadas dentro de esa ventana.
Durante el último año, se han implementado períodos de espera similares en ecosistemas de código abierto como npm, Python, Microsoft Visual Studio Code, Ruby, Bun, pnpm y Yarn, como forma de reforzar la seguridad de la cadena de suministro de software al reducir la probabilidad de que una versión recién publicada y sin revisar se incorpore inmediatamente a una compilación. Los períodos de enfriamiento ayudan a añadir fricción y ralentizar ataques en los que un actor malicioso publica una versión envenenada de un paquete popular tras tomar el control de una cuenta de mantenedor, evitando así su rápida propagación mediante instalaciones manuales o automatizadas.
"La contrapartida es que las correcciones legítimas también tienen que esperar, a menos que los desarrolladores hagan una excepción. El código malicioso tampoco se vuelve inofensivo mágicamente con la edad. Una versión que escape a la detección puede simplemente superar el período de enfriamiento. El valor está en dar tiempo a investigadores, mantenedores y registros para actuar antes de que la siguiente actualización de dependencias lleve un ataque más lejos", señaló Socket.
Deja una respuesta