Seguridad de los paquetes Snap: riesgos reales, mitos y herramientas

Guía Hardware » Guías de compra » Seguridad de los paquetes Snap: riesgos reales, mitos y herramientas

Si usas GNU/Linux desde hace tiempo es bastante probable que te hayas topado con los paquetes Snap, ya sea porque vienen preinstalados en Ubuntu o porque alguna aplicación que quieres probar solo está disponible en este formato. Alrededor de Snap hay un debate constante sobre seguridad, rendimiento, privacidad y usabilidad, y no siempre es fácil separar los mitos de los hechos comprobables.

Además, cuando hablamos de instalar software en Linux, muchas veces se da por hecho que todo lo que viene de una tienda “oficial” es seguro por defecto. La realidad es que el empaquetado moderno (Snap, Flatpak, AppImage, deb, rpm…) tiene matices importantes en cómo gestiona dependencias, vulnerabilidades, aislamiento y control del usuario. En este artículo vamos a profundizar en la seguridad de los paquetes Snap, los problemas reales que se han visto en la Snap Store, herramientas como Snapscope para auditar vulnerabilidades y cómo encaja todo esto frente a otros formatos.

Qué es Snap y por qué genera tanta polémica

Snap es un sistema de empaquetado desarrollado por Canonical que busca ofrecer aplicaciones “autocontenidas”, con todas sus dependencias incluidas, de forma que el mismo paquete funcione en múltiples distribuciones sin tener que recompilar ni pelearse con librerías del sistema. La idea es que el desarrollador empaquete una vez y el usuario instale sin dolores de cabeza, esté usando Ubuntu, Debian, Fedora o Arch.

Junto al formato de los paquetes, Snap depende de un servicio llamado snapd, que se encarga de la gestión, instalación, actualizaciones y ejecución de las aplicaciones. Snapd controla también el sistema de permisos y confinamiento (sandbox), que limita qué partes del sistema puede ver y tocar cada aplicación Snap.

A nivel práctico, un Snap es una imagen SquashFS que se monta en el sistema de archivos, generalmente bajo /snap. Cada paquete trae sus propias librerías, binarios y metadatos, y puede basarse en un “base snap” (como core, core18, core20 o similares) para compartir componentes comunes con otros paquetes y reducir duplicaciones.

La polémica viene porque, aunque esta aproximación resuelve muchos dolores de cabeza de compatibilidad, también arrastra problemas de rendimiento, consumo de espacio, duplicación de dependencias y un fuerte control centralizado por parte de Canonical a través de la Snap Store. Además, ha habido incidentes de seguridad y casos de malware que han hecho saltar las alarmas en la comunidad.

Distribuciones como Linux Mint han llegado a deshabilitar Snap por defecto, argumentando que su modelo de distribución y actualizaciones automáticas choca con la filosofía de control del usuario. Otros usuarios simplemente lo evitan porque han tenido malas experiencias con la integración o la velocidad de algunas aplicaciones empaquetadas como Snap.

Ventajas y desventajas de Snap desde la óptica de la seguridad

Desde el punto de vista teórico, Snap aporta varias ventajas relacionadas con la seguridad. El confinamiento mediante sandbox y el sistema de permisos permiten limitar el daño potencial de una aplicación comprometida: restringir su acceso al sistema de archivos, la red, dispositivos de hardware, etc., según los “conectores” que se le concedan.

Otra ventaja es que, al controlar Canonical la tienda de Snap, existe un punto central de distribución donde se pueden revocar, despublicar o corregir rápidamente paquetes problemáticos. Esto contrasta con repositorios distribuidos o PPA desatendidos, donde el mantenimiento puede ser más errático.

Sin embargo, la cara B es importante: al empaquetar las aplicaciones con sus propias dependencias, cada Snap puede arrastrar versiones antiguas de librerías con vulnerabilidades conocidas, que no se benefician automáticamente de las actualizaciones del sistema base. Si el mantenedor del Snap se olvida de actualizar, ese paquete puede quedarse obsoleto durante años.

Conviene remarcar que este problema no es exclusivo de Snap. Flatpak, AppImage o incluso imágenes de contenedores sufren exactamente el mismo riesgo: se incluyen dependencias dentro del paquete y, si nadie las actualiza, se quedan atrás en cuanto a parches de seguridad.

Donde Snap sí recibe críticas adicionales es en cuestiones como el rendimiento y la integración. Montar un sistema SquashFS por cada Snap instalado implica que el sistema tenga que gestionar múltiples “mini sistemas de archivos”, lo que puede hacer que el arranque del sistema y el de las aplicaciones sea más lento y consuma más memoria, especialmente en equipos con hardware más modesto.

Problemas prácticos: rendimiento, espacio y duplicación de librerías

Uno de los argumentos más repetidos entre quienes desaconsejan Snap es el de la duplicación masiva de librerías. Cada aplicación empaquetada como Snap incluye sus propias dependencias, aunque el sistema ya tenga versiones iguales o más nuevas instaladas. Esto hace que programas que en deb o rpm ocuparían unos pocos megas, pasen a usar cientos.

Para usuarios con discos SSD pequeños, esta duplicación puede ser especialmente molesta. Cuantos más Snaps instalas, más se llena el disco con copias distintas de las mismas librerías, y el sistema de archivos termina trabajando siempre sobre los mismos bloques, algo nada ideal a largo plazo para la vida útil de un SSD.

Además, cuando cada Snap monta su propio sistema SquashFS, el número de montajes del sistema de archivos se multiplica. Incluso si no estás ejecutando todas esas aplicaciones, los sistemas de archivos asociados a los paquetes siguen presentes y deben gestionarse, lo que se traduce en consumo de recursos extra en el arranque y, en algunos casos, en una sensación de “pesadez” del sistema muy similar a la que muchos asocian con Windows cuando se instala mucho software.

Otro punto conflictivo es la velocidad de inicio de algunas aplicaciones Snap, especialmente en sus primeros años de vida. Firefox, Telegram Desktop y otras aplicaciones gráficas en formato Snap han sido criticadas por arrancar mucho más lento que sus equivalentes instaladas desde la web oficial o vía paquetes tradicionales. Aunque Canonical ha trabajado para mejorar este aspecto, la percepción de lentitud sigue siendo recurrente en parte de la comunidad.

Por si fuera poco, la integración con el entorno de escritorio tampoco siempre es perfecta. Problemas con temas visuales, portapapeles, acceso a directorios del usuario o interacción con otros programas nativos pueden surgir, sobre todo cuando el confinamiento es estricto y la aplicación necesita hablar con otras piezas del sistema que no están contempladas por los conectores estándar.

Casos reales de malware y problemas de confianza en la Snap Store

Aunque Snap se presente como una opción cómoda y en teoría segura, la historia nos recuerda que ninguna tienda de software está libre de incidentes. En la Snap Store de Ubuntu se han detectado paquetes con comportamiento malicioso o al menos muy poco transparente, como el caso de las aplicaciones 2048Ubuntu y Hextris.

Estos juegos, publicados por un desarrollador identificado como Nicolas Tomb, incluían código de minería de criptomonedas integrado en el paquete Snap. Técnicamente, se apoyaban en que el código era de fuente abierta y, por tanto, cualquiera podía inspeccionarlo, pero en la práctica, la mayoría de usuarios no revisa el contenido de los paquetes antes de instalarlos.

Esto plantea una cuestión delicada: si un desarrollador añade un minero de criptomonedas sin avisar de forma clara, ¿estamos ante malware o “solo” un comportamiento abusivo pero legalmente ambiguo? Desde el punto de vista del usuario, que ve cómo su CPU trabaja para minar monedas sin haber dado un consentimiento explícito, la sensación es la de haber instalado software malicioso.

El problema de fondo es que, a diferencia de los paquetes deb de los repositorios oficiales, casi cualquiera puede subir paquetes Snap a la tienda, con revisiones automatizadas y controles que no siempre detectan este tipo de prácticas. Esto amplía mucho la oferta de software, pero también abre la puerta a abusos, especialmente si la auditoría de los contenidos no es exhaustiva.

Este tipo de incidentes no son exclusivos del ecosistema Snap: Google Play, extensiones de navegadores, repositorios de terceros y otras tiendas han sufrido casos similares. Pero el hecho de que se haya producido en la Snap Store ha reforzado la desconfianza de quienes ya veían con recelo la centralización en Canonical y la menor transparencia en comparación con repositorios comunitarios más revisados.

Snapscope: auditoría de seguridad y transparencia para los paquetes Snap

En este contexto de dudas sobre la seguridad real de los paquetes, surge Snapscope, una herramienta que ha dado mucho que hablar en el ecosistema Snap. Snapscope es una aplicación web orientada a analizar paquetes Snap en busca de vulnerabilidades conocidas (CVE) y mostrar de forma clara el “estado de salud” de cada paquete desde el punto de vista de la seguridad.

El proyecto nace como iniciativa personal de Alan Pope, figura muy conocida en la comunidad de Ubuntu y antiguo empleado de Canonical. No es un producto oficial de Canonical, sino un proyecto independiente que busca aportar transparencia y herramientas de auditoría para usuarios, administradores y desarrolladores.

El funcionamiento es sencillo: entras en la web de Snapscope, escribes el nombre de un paquete Snap o el del editor/desarrollador y obtienes un informe con las vulnerabilidades detectadas en ese paquete, clasificadas por severidad. También puedes ver listados de los paquetes escaneados recientemente, rankings de los Snaps con más vulnerabilidades y acceder a enlaces directos a la información detallada de cada CVE.

La filosofía del proyecto se resume en una frase que el propio Pope repite a menudo: “no hay juicios, solo hechos”. La idea no es demonizar Snap ni asustar al usuario, sino ofrecer datos objetivos para que cada cual pueda tomar decisiones informadas sobre qué instalar y cuándo conviene presionar al mantenedor para que actualice dependencias.

Un detalle llamativo es que Snapscope se desarrolló inicialmente en el contexto de Vibelympics, una iniciativa de Chainguard en la que los desarrolladores crean proyectos de forma rápida y creativa con un componente benéfico. Aunque surgiera casi como un experimento, se ha convertido en una herramienta muy útil para quienes se toman en serio la seguridad de sus sistemas.

Base técnica de Snapscope: Grype, CVE y vulnerabilidades explotadas

La potencia de Snapscope se apoya en Grype, una herramienta de código abierto especializada en el análisis de vulnerabilidades en imágenes de contenedores y sistemas de archivos. Grype compara las librerías y componentes encontrados dentro del paquete Snap con bases de datos públicas de vulnerabilidades (CVE) para detectar fallos de seguridad conocidos.

Cuando Snapscope analiza un paquete, agrupa las vulnerabilidades encontradas por nivel de gravedad, usando categorías como CRITICAL, HIGH, MEDIUM y LOW. Además, marca aquellas vulnerabilidades catalogadas como KEV (Known Exploited Vulnerabilities), es decir, fallos que se sabe que están siendo explotados activamente en el mundo real.

El informe que se obtiene para cada paquete muestra el identificador de la vulnerabilidad (CVE-ID), su severidad y enlaces a recursos externos donde se explican los detalles técnicos, versiones afectadas, impacto y posibles mitigaciones. Esto facilita que administradores y desarrolladores entiendan rápidamente qué riesgos asumen al usar un Snap determinado y qué acciones deberían priorizar.

Por ahora, Snapscope se centra en paquetes para arquitectura x86_64, que es donde se concentra la mayoría de instalaciones de escritorio y servidor. La idea es mantener un análisis fiable y sólido en la plataforma más extendida antes de ampliar a otras arquitecturas, aunque no se descarta hacerlo en el futuro.

Otro aspecto interesante es que la herramienta permite volver a escanear el mismo paquete varias veces. Aunque la versión del Snap no cambie, las bases de datos de vulnerabilidades sí lo hacen constantemente, así que un análisis de hoy puede arrojar resultados distintos de uno hecho hace unas semanas, descubriendo problemas que antes no existían o no estaban catalogados.

Funciones prácticas de Snapscope y quién se beneficia más

Snapscope no se limita a un cuadro de búsqueda. La web incluye listados de paquetes analizados recientemente, rankings de Snaps con mayor número de vulnerabilidades y la posibilidad de poner en cola paquetes para que se vuelvan a escanear con las bases de datos más recientes.

La interfaz es sencilla y directa: no hace falta crear cuenta ni pelearse con filtros complicados. Cualquier usuario puede entrar, buscar un paquete concreto y ver al instante cómo está en términos de seguridad. Esto da una capa de control adicional a personas que, de otro modo, solo tendrían la información proporcionada por la propia Snap Store.

El perfil que más provecho saca de Snapscope son los administradores de sistemas que gestionan servidores o puestos de trabajo donde se usan múltiples Snaps. Para ellos, poder identificar rápidamente qué paquetes acumulan más vulnerabilidades críticas o explotadas activamente es fundamental para priorizar actualizaciones, migraciones o sustituciones por alternativas más seguras.

Los desarrolladores y mantenedores de Snaps también se benefician. Ver que tu paquete aparece con un buen puñado de CVEs de alta severidad, enlazados a bibliotecas concretas, sirve como recordatorio contundente de que toca revisar dependencias y lanzar nuevas versiones. Además, que cualquier usuario pueda lanzar un nuevo escaneo añade una presión sana hacia el mantenimiento responsable.

Por último, está el usuario preocupado por la seguridad que, antes de instalar un paquete, quiere echar un vistazo a qué se está llevando a su sistema. Snapscope le permite decidir si quiere asumir el riesgo de usar un Snap con varias vulnerabilidades sin parchear, o si prefiere buscar otra fuente (deb, Flatpak, AppImage) o incluso compilar desde código.

El verdadero foco del problema: librerías incluidas y mantenimiento

Al revisar los resultados de Snapscope, puede parecer que los Snaps están plagados de agujeros. Sin embargo, el análisis más sosegado muestra que la mayoría de vulnerabilidades detectadas se asocian a librerías incluidas dentro de los paquetes, no al formato Snap en sí. Es decir, el problema no es tanto la “caja” como lo que se mete dentro y, sobre todo, cuánto tiempo pasa sin actualizarlo.

Que los Snaps sean autocontenidos tiene una ventaja importante: permiten que aplicaciones recientes funcionen en distribuciones antiguas o que apps más viejas sigan tirando en sistemas nuevos sin romperse por cambios de ABI. Es una especie de burbuja controlada donde el desarrollador define exactamente el entorno en el que se ejecuta su software.

La contrapartida es que, si una de esas librerías integradas tiene una vulnerabilidad crítica, la única forma de corregirla es que el mantenedor del Snap actualice la dependencia y reconstruya el paquete. Actualizar el sistema base no arregla nada, porque la copia vulnerable va empaquetada dentro del propio Snap.

Canonical intenta mitigarlo con los “base snaps”, que agrupan componentes comunes (bibliotecas del sistema, runtime básico, etc.) compartidos por múltiples aplicaciones. Al centralizar parte del contenido común en estos base snaps, se reduce la duplicación y se facilita aplicar parches de seguridad a varios paquetes a la vez. Aun así, muchas dependencias específicas siguen viajando con cada aplicación, con el riesgo consiguiente si se dejan envejeciendo.

Conviene insistir en que si se analizasen con una herramienta similar los paquetes deb, Flatpak o contenedores de Docker, encontraríamos un panorama muy similar: bibliotecas desactualizadas, vulnerabilidades de diferente severidad y casos de mantenimiento deficiente. Snapscope simplemente hace muy visible este problema en el ecosistema Snap.

Sandbox, permisos y límites reales de la seguridad en Snap

Uno de los argumentos frecuentemente utilizados para defender a Snap es su modelo de sandboxing. Cada aplicación se ejecuta en un entorno parcialmente aislado, con un conjunto de permisos explícitos que determinan a qué partes del sistema puede acceder: archivos personales, red, hardware, bus de sesión, etc.

Esto ayuda a reducir el impacto en caso de explotación de una vulnerabilidad dentro del Snap, pero no convierte automáticamente a cualquier paquete en “seguro”. Si un Snap tiene permiso para conectar a internet y manejar datos sensibles, un atacante puede seguir exfiltrando información o interactuando con servicios externos, incluso dentro de un sandbox.

El caso de las aplicaciones de criptomonedas comprometidas en la Snap Store ilustra esta realidad. Aunque estuvieran confinadas, tenían acceso a la red y podían comportarse de forma maliciosa o abusiva, aprovechando la confianza del usuario en que venían de una tienda “oficial”. Lo mismo sucede en otros ecosistemas: un sandbox limita daños, pero no es una garantía absoluta.

En el lado de Flatpak también hay matices. Su modelo de permisos tiende a ser algo más estricto por defecto en ciertos contextos, pero muchas aplicaciones tienen acceso casi sin restricciones a la carpeta Documentos del usuario o a otras rutas críticas, en función de cómo se haya empaquetado. El peligro no desaparece por el simple hecho de usar sandboxing; cambia de forma.

En resumen, el sandbox es una capa de defensa muy útil, pero no sustituye a la necesidad de código bien auditado, dependencias actualizadas y buenas prácticas de desarrollo. Un paquete Snap totalmente actualizado pero mal diseñado desde el punto de vista de permisos puede seguir siendo un problema de seguridad.

Snap frente a Flatpak y empaquetado tradicional: percepción y realidad

Más allá de los aspectos puramente técnicos, en la comunidad pesa mucho la percepción. Snap compite en el imaginario colectivo con Flatpak, AppImage y los formatos tradicionales deb/rpm, y cada uno tiene sus defensores acérrimos y sus detractores.

En cuanto a seguridad, ningún formato tiene el monopolio de las buenas prácticas. El empaquetado por parte de distribuidores (deb, rpm) no es automáticamente más seguro que Snap o Flatpak. Los mantenedores de paquetes pueden no ser expertos en el código que empaquetan, pueden tardar en actualizar versiones y, en más de una ocasión, han introducido cambios discutibles sin coordinar con los desarrolladores originales.

Casos como la vulnerabilidad de log4j o el hackeo de la biblioteca XZ han demostrado que incluso paquetes firmados y verificados, presentes en repositorios oficiales, pueden contener puertas traseras o fallos críticos. La verificación garantiza procedencia, no ausencia de vulnerabilidades.

Por otra parte, Flatpak ofrece un enfoque muy similar a Snap: aplicaciones autocontenidas, runtimes compartidos, sandboxing y un repositorio central (Flathub) muy popular. La preferencia de algunos usuarios por Flatpak suele basarse en la percepción de mayor apertura del ecosistema, mejor integración en ciertas distros (como Fedora) y menos control central corporativo, más que en diferencias abismales de seguridad.

AppImage, en cambio, apuesta por la portabilidad extrema: descargas un archivo, le das permisos de ejecución y listo. No hay demonio central ni tienda obligatoria, pero tampoco un modelo de permisos tan granular como Snap o Flatpak. La responsabilidad de evaluar la seguridad de lo que ejecutas recae aún más en el usuario.

Responsabilidad del usuario y buenas prácticas al instalar Snaps

Independientemente del formato elegido, la seguridad de lo que instalas en tu sistema nunca se puede delegar al 100 % en una tienda o en un mecanismo automático. Como usuario, especialmente en entornos Linux, sigues siendo la última línea de defensa.

En el caso concreto de Snap, conviene seguir algunas pautas mínimas. Primero, priorizar paquetes publicados por desarrolladores oficiales o organizaciones reconocibles frente a clones o forks de origen dudoso. La Snap Store indica quién es el “publisher” de cada paquete, y muchas veces este dato es clave.

También es importante revisar la frecuencia de actualizaciones. Si un Snap no se actualiza desde hace años, es muy probable que arrastre dependencias con vulnerabilidades. Herramientas como Snapscope ayudan a confirmar esta sospecha y a evaluar la severidad de los problemas existentes.

Otra buena práctica es ser conservador con los permisos. Si un Snap solicita accesos que no parecen necesarios para su función (por ejemplo, acceso a todos tus archivos personales o a recursos sensibles sin motivo claro), puede ser preferible buscar otra alternativa o revisar más a fondo qué está haciendo esa aplicación.

Por último, aunque sea tentador confiar ciegamente en el hecho de que algo está en la Snap Store, no está de más echar un vistazo a los comentarios de otros usuarios, la reputación del paquete y, cuando sea posible, a su código fuente. Cuanta más visibilidad tenga un proyecto, más probable es que alguien detecte y reporte comportamientos sospechosos.

La seguridad de los paquetes Snap no se puede reducir a un simple “es seguro” o “es peligroso”: se mueve en una zona gris donde influyen el formato, la manera de empaquetar, el mantenimiento de librerías, el modelo de tienda centralizada, las herramientas de auditoría como Snapscope y, sobre todo, el uso responsable por parte del usuario; entendiendo cómo funciona Snap, qué problemas arrastra y qué mecanismos existen para detectar vulnerabilidades, es mucho más fácil aprovechar sus ventajas sin caer en una falsa sensación de seguridad ni en un rechazo visceral sin datos que lo respalden.