Snapscope se ha convertido en una de las herramientas más comentadas dentro del ecosistema Snap, y no es para menos: pone bajo el microscopio la seguridad de los paquetes que instalamos a diario desde la Snap Store. En un contexto donde confiamos, casi por defecto, en que todo lo que viene de una tienda de software es seguro, contar con un escáner independiente que muestre vulnerabilidades reales es algo que puede cambiar la percepción de muchos usuarios.

Lejos de ser un proyecto corporativo, Snapscope nace como iniciativa personal de Alan Pope, una figura muy conocida en la comunidad de Ubuntu, que ha trabajado años en Canonical. Su propuesta es tan sencilla como potente: escribes el nombre de un paquete Snap o el de su desarrollador, y obtienes un informe de seguridad detallado basado en vulnerabilidades conocidas. Todo ello con un enfoque muy claro: “no hay juicios, solo hechos”.

Contexto: Snap, seguridad y la necesidad de transparencia

Cuando hablamos de seguridad en GNU/Linux, muchos usuarios asumen que instalar desde repositorios oficiales o tiendas como la Snap Store es sinónimo de tranquilidad total. Sin embargo, la experiencia de los últimos años ha dejado claro que la seguridad absoluta no existe, ni en Snap ni en ningún otro formato. Canonical trabaja para prevenir problemas, pero siempre puede colarse algún paquete desactualizado, mal mantenido o con dependencias vulnerables.

En el caso de los Snaps hay un matiz importante: no solo los equipos oficiales de un proyecto pueden publicar paquetes. Cualquier desarrollador o empresa que cumpla los requisitos mínimos puede subir su aplicación a la Snap Store. Esto abre la puerta a mucha variedad —y a una gran riqueza de software—, pero también implica que la confianza que depositamos en los paquetes tiene que ir acompañada de mecanismos de auditoría.

Ahí entra en juego Snapscope. La gran pregunta que intenta responder esta herramienta es simple: ¿qué hay dentro de cada paquete Snap y cuál es realmente su estado de seguridad? En lugar de fiarnos a ciegas, podemos consultar un análisis apoyado en bases de datos de vulnerabilidades reconocidas a nivel global.

Qué es Snapscope y quién está detrás

Snapscope es una aplicación web enfocada en analizar paquetes Snap en busca de CVE y vulnerabilidades conocidas. Está desarrollada por Alan Pope (conocido como “popey” en la comunidad), antiguo empleado de Canonical y habitual en el mundo del Software Libre. No se trata de un producto oficial de Ubuntu, sino de un proyecto personal que ha ido tomando forma con la idea de aportar más transparencia al ecosistema Snap.

El funcionamiento de la web es muy directo: introduces el nombre de un paquete Snap o el del editor (organización o desarrollador) en el buscador, y el sistema lanza un escaneo utilizando herramientas de análisis de seguridad. El resultado es un informe con todas las vulnerabilidades detectadas, clasificadas por severidad, junto con enlaces para ampliar información.

Además, Snapscope tiene un punto curioso: Alan comenta que “vibe-codeó” el sitio en el contexto de Vibelympics, una iniciativa de Chainguard donde los desarrolladores crean proyectos creativos y rápidos, con un premio destinado a una causa benéfica. Aunque el origen sea relativamente lúdico, la utilidad práctica del proyecto es muy seria para administradores, desarrolladores y usuarios avanzados.

La base técnica: análisis con Grype y CVEs

El núcleo de Snapscope se apoya en Grype, una herramienta de código abierto especializada en análisis de vulnerabilidades en imágenes de contenedores y sistemas de archivos. Grype compara el contenido del paquete (especialmente bibliotecas y dependencias) con una base de datos de CVEs para detectar posibles fallos de seguridad.

Cuando se analiza un Snap, las vulnerabilidades detectadas se agrupan por nivel de gravedad: categorías como CRITICAL, HIGH, MEDIUM y LOW, además de las vulnerabilidades incluidas en listas KEV (Known Exploited Vulnerabilities, es decir, fallos que se sabe que están siendo explotados activamente). Esto permite tener una idea rápida de si el riesgo es meramente teórico o si hay exploits circulando por ahí.

En la práctica, el informe de cada paquete muestra el identificador de la vulnerabilidad (CVE-ID), su severidad y enlaces externos con información ampliada. Es decir, no solo ves que existe un problema, sino qué implica, a qué versiones afecta, y en muchos casos qué medidas recomiendan los responsables de seguridad para mitigarlo.

Por ahora, Snapscope se centra en paquetes para arquitectura x86_64, que es donde la herramienta está más madura. Alan ha dejado caer que en el futuro se podrían añadir más arquitecturas, pero la prioridad actual es mantener un análisis fiable en la plataforma más utilizada en escritorio y servidores.

Funciones prácticas de la web de Snapscope

Más allá del escaneo puntual de un paquete, la web de Snapscope incorpora varias utilidades que facilitan la exploración y auditoría de la Snap Store:

• Búsqueda por nombre de paquete o por desarrollador/organización: puedes escribir directamente el nombre del Snap (por ejemplo, una aplicación conocida) o el nombre del publisher, y ver todos los paquetes relacionados que ya han sido analizados.
• Listados de paquetes escaneados recientemente: en la portada se muestran los Snaps que han pasado por el escáner en los últimos análisis, lo que ayuda a ver qué se está revisando con más frecuencia.
• Rankings de paquetes con mayor número de vulnerabilidades: hay gráficos que resaltan los paquetes con más CVEs detectados, lo que sirve de alerta temprana para administradores y usuarios que utilicen esos Snaps en producción.
• Enlaces a la información detallada de cada CVE: cada entrada permite acceder a recursos externos para entender el contexto del fallo, su impacto y si existen parches o mitigaciones.
• Posibilidad de poner paquetes en cola para volver a escanear: si alguien quiere obtener un análisis actualizado, puede forzar un nuevo escaneo de un Snap concreto, algo útil cuando la base de datos de vulnerabilidades se ha actualizado recientemente.

Todo esto se presenta en una interfaz bastante clara y sin florituras, sin necesidad de registro ni configuraciones complejas. Cualquier persona con un navegador puede entrar en la web, buscar un Snap y ver al momento su “postura de seguridad”.

Por qué la mayoría de vulnerabilidades no son culpa del formato Snap

Uno de los puntos clave que deja Snapscope en evidencia es que la mayoría de vulnerabilidades detectadas están ligadas a las bibliotecas incluidas dentro del paquete, no al formato Snap en sí. Al ser aplicaciones autocontenidas, los Snaps suelen llevar consigo versiones concretas de sus dependencias, en lugar de usar las del sistema.

Este diseño tiene ventajas obvias: permite que aplicaciones modernas funcionen en distribuciones antiguas, o que aplicaciones más viejas sigan ejecutándose en sistemas recientes con cambios profundos en sus librerías base. Además, da más control al mantenedor del Snap sobre el entorno en el que corre la aplicación.

Sin embargo, también tiene una cara menos amable: si una librería integrada en el Snap tiene un fallo de seguridad, solo el propio mantenedor del paquete puede actualizarla y reconstruir el Snap. No basta con actualizar el sistema operativo o las bibliotecas del sistema, porque la copia vulnerable va “embebida” en el paquete.

En otras palabras, el problema no es exclusivo de Snap: esa misma versión vulnerable de una biblioteca sería peligrosa en un DEB, un AppImage, un Flatpak o cualquier otro formato si se incluye tal cual. La diferencia es que en los Snaps se hace más evidente el desacople entre el ciclo de actualizaciones del sistema y el del propio paquete.

Canonical intenta mitigar esta situación mediante los llamados “base snaps”, que agrupan componentes clave compartidos por muchos paquetes para reducir duplicaciones y facilitar el mantenimiento de bibliotecas críticas. No obstante, esto no elimina por completo el riesgo, porque siguen existiendo dependencias que cada paquete arrastra por su cuenta.

Seguridad, sandboxing y percepción del riesgo

Al revisar los informes de Snapscope puede dar la sensación de que los Snaps están llenos de agujeros de seguridad, pero conviene poner las cifras en contexto. En primer lugar, muchas de las vulnerabilidades listadas se limitarán a bibliotecas que, aun siendo vulnerables, se usan en escenarios muy concretos, o ya cuentan con mitigaciones.

Además, el modelo de seguridad de Snap incorpora mecanismos de confinamiento y sandboxing bastante estrictos. Esto significa que, incluso si una vulnerabilidad se explota dentro de un Snap, el impacto queda en principio contenido dentro del entorno aislado del paquete, siempre y cuando el usuario no haya relajado manualmente los permisos.

Eso no quiere decir que todo esté resuelto mágicamente, pero sí reduce el impacto potencial de muchas vulnerabilidades. La verdadera preocupación pasa menos por el formato en sí y más por el mantenimiento: paquetes que llevan años sin actualizarse, bibliotecas desfasadas, o Snaps subidos como pruebas que nunca más han sido revisados.

De hecho, se estima que un número enorme de paquetes en la Snap Store no se han tocado en años. Muchos son simples “hello world” o experimentos de desarrolladores probando el formato, que han quedado publicados y disponibles para cualquiera. Snapscope ayuda a visibilizar este tipo de situaciones, empujando a los mantenedores a revisar y limpiar sus publicaciones.

Transparencia y auditabilidad: el verdadero valor de Snapscope

Uno de los mensajes que Alan Pope repite al hablar de Snapscope es que la herramienta no pretende demostrar que Snap sea menos seguro que otros formatos. Lo que pone sobre la mesa es la importancia de la auditabilidad: poder inspeccionar qué hay en un paquete y saber qué vulnerabilidades arrastra.

Que una herramienta como Snapscope exista es posible precisamente porque el funcionamiento de los Snaps es razonablemente transparente. El contenido puede analizarse con herramientas estándar de seguridad, cruzarse con bases de datos públicas de CVEs y presentarse de forma legible para desarrolladores y usuarios avanzados.

En este sentido, Snapscope funciona como un canal de feedback silencioso hacia los mantenedores. Aunque el sitio no haga “juicios” explícitos, ver tu paquete listado entre los que tienen más vulnerabilidades o comprobar que tu Snap no se ha escaneado en años puede ser el empujón que faltaba para actualizarlo.

Esta idea enlaza con otra reflexión recurrente en la comunidad: el feedback no siempre es un ataque. Durante años, cuando los usuarios se quejaban de que los Snaps eran más lentos al arrancar que otros formatos, parte de la respuesta fue defensiva, atribuyendo las críticas a “haters”. Con el tiempo se reconoció que, efectivamente, había un problema de rendimiento, se investigó y se mejoró. Hoy, en muchos casos, los Snaps están a la par en velocidad con paquetes “nativos”.

Snapscope encaja justo en ese tipo de dinámica: no dice que Snap sea inseguro, sino que ofrece datos que ayudan a mejorarlo. La diferencia entre repetir un mantra (“es seguro, confía”) y enseñar un informe concreto con CVEs, fechas y versiones es notable, sobre todo de cara a usuarios y empresas que necesitan justificar decisiones técnicas.

Uso práctico: quién se beneficia más de Snapscope

Aunque cualquiera puede entrar en la web y buscar un paquete por curiosidad, Snapscope resulta especialmente útil para tres perfiles muy claros dentro del ecosistema GNU/Linux.

En primer lugar, los administradores de sistemas que gestionan entornos con muchos Snaps instalados. Para ellos, disponer de una herramienta que permita comprobar rápidamente el estado de seguridad de los paquetes críticos es oro puro. Pueden revisar qué aplicaciones tienen más CVEs pendientes de parchear, priorizar migraciones o reemplazos, o incluso decidir si seguir usando un Snap o optar por otro formato.

En segundo lugar, los desarrolladores y mantenedores de paquetes Snap encuentran en Snapscope un aliado cómodo. Les permite ver de un vistazo qué vulnerabilidades afectan a las bibliotecas que han incluido en su paquete, enlazando a la información necesaria para actualizar dependencias y lanzar nuevas revisiones. Además, el hecho de que cualquiera pueda solicitar un nuevo escaneo añade una capa de presión sana para mantener el software al día.

Y en tercer lugar, los usuarios preocupados por la seguridad —gente que antes de instalar algo quiere tener claro qué riesgos asume— pueden, antes de pulsar “instalar” en la Snap Store, pasar por Snapscope y echar un vistazo rápido a la salud del paquete. No se trata de provocar alarma, sino de dar herramientas para tomar decisiones informadas.

Relación con otros formatos y el papel de Canonical

Uno de los puntos que se suele malinterpretar es la idea de que Snapscope probaría que Snap es peor o más inseguro que otros formatos. Nada más lejos de la realidad: las mismas bibliotecas vulnerables detectadas en un Snap podrían estar empaquetadas en un DEB, un AppImage, un Flatpak o incluso en un contenedor, y Grype sería capaz de señalarlas igual.

De hecho, si se configurase el mismo tipo de análisis para paquetes DEB tradicionales o imágenes de contenedores, probablemente aparecerían vulnerabilidades muy similares en número y tipo. La diferencia es que, por ahora, la herramienta se ha orientado a Snaps porque es el ecosistema en el que Alan Pope se mueve con más soltura.

Por parte de Canonical, la compañía ha trabajado en reducir la superficie de ataque y mejorar el rendimiento del formato tanto en escritorio como en servidores, un ejemplo de los retos recientes en el software para Linux. Los “base snaps” mencionados antes, la mejora en los tiempos de arranque y el confinamiento estricto forman parte de ese esfuerzo continuo.

Algunos críticos han señalado también aspectos como el backend propietario de la Snap Store o la política de actualizaciones automáticas, algo que incluso ha llevado a distribuciones como Linux Mint a limitar el uso de Snap por defecto. En este contexto, una herramienta externa como Snapscope puede servir de puente: aporta datos objetivos y permite a cada cual decidir hasta qué punto le compensa usar o no este formato.

Alan ha comentado que no puede integrar directamente su trabajo dentro de la Snap Store, porque eso requeriría cambios y acceso a infraestructuras de Canonical que él no tiene. Sin embargo, ha señalado que Canonical es libre de tomar ideas o código del proyecto para integrarlo o evolucionarlo, ya sea en forma de servicio público u otra clase de herramientas internas de auditoría.

Actualizaciones, reescaneos y evolución futura de la herramienta

Un detalle interesante de Snapscope es que permite volver a escanear varias veces el mismo paquete. A primera vista puede parecer redundante, pero tiene mucho sentido: las bases de datos de vulnerabilidades se actualizan constantemente, de modo que un escaneo de hoy puede arrojar resultados distintos a uno de la semana pasada, incluso si el Snap no ha cambiado.

Esto explica por qué aparecen en la web múltiples peticiones de análisis para la misma versión de un paquete. Cada nuevo escaneo se beneficia de la información más reciente disponible en las fuentes de datos de seguridad, pudiendo sacar a la luz problemas que antes no figuraban en la lista.

En cuanto a futuras mejoras, Alan ha expresado interés en poder escanear distintas revisiones y canales de un mismo Snap (por ejemplo, estable, beta, edge, o versiones ESR de aplicaciones como Firefox y Thunderbird). Actualmente está limitado por las capacidades de las herramientas subyacentes, pero hay issues y pull requests abiertos para añadir soporte a la selección de revisiones específicas. Cuando esa funcionalidad esté madura, la idea es integrarla en Snapscope.

Mientras tanto, el proyecto sigue siendo un trabajo en curso que ya es muy útil en su estado actual. A medida que la comunidad lo use, reporte problemas y sugiera mejoras, es de esperar que su alcance y precisión vayan creciendo, del mismo modo que lo hacen las propias bases de datos de vulnerabilidades.

Snapscope se coloca como una pieza clave para aportar luz sobre la seguridad real de los paquetes Snap, sin caer ni en el alarmismo fácil ni en la defensa ciega del formato. Ofrece datos claros, ayuda a identificar bibliotecas desactualizadas, empuja a los mantenedores a ponerse las pilas y da a usuarios y administradores una herramienta práctica para tomar decisiones con información en la mano; en un ecosistema donde conviven debates sobre rendimiento, confianza en las tiendas y modelos de actualización, contar con un escáner independiente como este marca una diferencia importante.