Snapscope has become one of the most talked-about tools Within the Snap ecosystem, and for good reason: it puts the security of the packages we install daily from the Snap Store under a microscope. In a context where we almost automatically trust that everything from a software store is safe, having an independent scanner that reveals real vulnerabilities can change the perception of many users.
Far from being a corporate project, Snapscope was born as a personal initiative of Alan PopeA well-known figure in the Ubuntu community, who has worked for years at Canonical, his proposal is as simple as it is powerful: you type the name of a Snap package or its developer, and you get a detailed security report based on known vulnerabilities. All this with a very clear approach: “no judgments, only facts.”
Context: Snap, security, and the need for transparency
When we talk about security in GNU/Linux, Many users assume that installing from official repositories or stores The Snap Store is often seen as synonymous with complete peace of mind. However, experience over the past few years has made it clear that absolute security doesn't exist, neither in Snap nor in any other format. Canonical works to prevent problems, but an outdated, poorly maintained package, or one with vulnerable dependencies, can always slip through.
In the case of Snaps there is an important nuance: Not only official project teams can publish packagesAny developer or company that meets the minimum requirements can upload their application to the Snap Store. This opens the door to a wide variety—already a wealth of software—but it also means that the trust we place in these packages must be accompanied by auditing mechanisms.
That's where Snapscope comes in. The big question this tool tries to answer is simple.What's inside each Snap package, and what's its actual security status? Instead of blindly trusting it, we can consult an analysis based on globally recognized vulnerability databases.
What is Snapscope and who is behind it?
Snapscope is a web application focused on analyzing Snap packages for CVEs and vulnerabilities It's well-known. It's developed by Alan Pope (known as "Popey" in the community), a former Canonical employee and a regular in the Free Software world. It's not an official Ubuntu product, but a personal project that has taken shape with the idea of bringing more transparency to the Snap ecosystem.
The website works very simply: You enter the name of a Snap package or the editor. (organization or developer) in the search engine, and the system launches a scan using security analysis tools. The result is a report with all the vulnerabilities detected, classified by severity, along with links for further information.
Furthermore, Snapscope has a curious feature: Alan comments that he “vibe-coded” the site in the context of VibelympicsA Chainguard initiative where developers create creative and fast-paced projects, with a prize going to charity. Although its origins are relatively playful, the project's practical utility is very serious for administrators, developers, and advanced users.
The technical basis: analysis with Grype and CVEs
The core of Snapscope relies on Grype, an open-source tool specializing in vulnerability analysis in container images and file systems. Grype compares the package contents (especially libraries and dependencies) against a database of CVEs to detect potential security vulnerabilities.
When analyzing a Snap, The vulnerabilities detected are grouped by level of severityCategories such as CRITICAL, HIGH, MEDIUM, and LOW are included, along with vulnerabilities listed in KEV (Known Exploited Vulnerabilities) lists. This allows for a quick assessment of whether the risk is merely theoretical or if exploits are actually circulating.
In practice, the report for each package shows the vulnerability identifier (CVE-ID), its severity, and external links with expanded information. That is, you not only see that a problem exists, but what it entails, which versions it affects, and in many cases what measures security managers recommend to mitigate it.
For now, Snapscope focuses on packages for x86_64 architecturewhich is where the tool is most mature. Alan has hinted that more architectures could be added in the future, but the current priority is maintaining reliable analysis on the most widely used desktop and server platform.
Practical features of the Snapscope website
Beyond the one-off scanning of a package, The Snapscope website incorporates several utilities that facilitate exploration and auditing. from the Snap Store:
- Search by package name or by developer/organizationYou can directly type the Snap name (for example, a well-known application) or the publisher's name, and see all related packages that have already been analyzed.
- Lists of recently scanned packagesThe homepage displays the Snaps that have been scanned in recent analyses, helping you see what's being reviewed most often.
- Rankings of packages with the highest number of vulnerabilitiesThere are charts that highlight the packages with the most detected CVEs, which serves as an early warning for administrators and users who use those Snaps in production.
- Links to detailed information for each CVEEach entry allows access to external resources to understand the context of the failure, its impact, and whether patches or mitigations exist.
- Ability to queue packages for rescanningIf someone wants to get an updated analysis, they can force a new scan of a specific Snap, which is useful when the vulnerability database has been recently updated.
All of this is presented in a A fairly clear and uncluttered interfaceNo registration or complex configuration is required. Anyone with a browser can go to the website, search for a Snap, and instantly see its "security posture."
Why most vulnerabilities are not the fault of the Snap format
One of the key points that Snapscope highlights is that Most of the vulnerabilities detected are linked to the libraries included within the packagenot to the Snap format itself. As self-contained applications, Snaps typically carry specific versions of their dependencies, rather than using system versions.
This design has obvious advantages: It allows modern applications to run on older distributions.or that older applications continue to run on newer systems with significant changes to their core libraries. Furthermore, it gives the Snap maintainer more control over the environment in which the application runs.
However, it also has a less friendly side: if a library embedded in the Snap has a security flawOnly the package maintainer can update and rebuild the Snap. Simply updating the operating system or system libraries is insufficient because the vulnerable copy is embedded within the package.
In other words, The problem is not exclusive to Snap.That same vulnerable version of a library would be dangerous in a DEB package, an AppImage, a Flatpak, or any other format if included as is. The difference is that in Snaps, the decoupling between the system's update cycle and the package's own update cycle becomes more apparent.
Canonical attempts to mitigate this situation through what are called “base snaps”, which group shared key components Many packages are used to reduce duplication and facilitate the maintenance of critical libraries. However, this does not completely eliminate the risk, because dependencies still exist that each package carries on its own.
Security, sandboxing and risk perception
Reviewing Snapscope reports can give the impression that The snaps are full of security holesHowever, it's important to put the figures into context. Firstly, many of the listed vulnerabilities will be limited to libraries that, while vulnerable, are used in very specific scenarios or already have mitigations in place.
In addition, Snap's security model incorporates fairly strict confinement and sandboxing mechanismsThis means that even if a vulnerability is exploited within a Snap, the impact is generally contained within the package's isolated environment, as long as the user has not manually relaxed permissions.
That doesn't mean everything is magically solved, but Yes, it reduces the potential impact of many vulnerabilities.The real concern is less about the format itself and more about maintenance: packages that haven't been updated in years, outdated libraries, or Snaps uploaded as tests that have never been reviewed again.
In fact, it is estimated that A huge number of packages in the Snap Store haven't been touched in years.Many are simple "hello world" messages or developer experiments testing the format, which have been left published and available to anyone. Snapscope helps to highlight these situations, encouraging maintainers to review and clean up their posts.
Transparency and auditability: the true value of Snapscope
One of the messages that Alan Pope repeats when talking about Snapscope is that The tool does not intend to demonstrate that Snap is less secure than other formats.What this highlights is the importance of auditability: being able to inspect what's in a package and know what vulnerabilities it carries.
That a tool like Snapscope exists This is possible precisely because the operation of Snaps is reasonably transparent.The content can be analyzed with standard security tools, cross-referenced with public CVEs, and presented in a readable format for developers and advanced users.
In this sense, Snapscope functions as a silent feedback channel to the maintainersAlthough the site doesn't make explicit "judgments," seeing your package listed among those with the most vulnerabilities or checking that your Snap hasn't been scanned in years might be the push you needed to update it.
This idea connects with another recurring reflection in the community: Feedback is not always an attackFor years, when users complained that Snaps were slower to start than other formats, part of the response was defensive, attributing the criticism to "haters." Over time, it was acknowledged that there was indeed a performance issue, it was investigated, and improvements were made. Today, in many cases, Snaps are on par in speed with "native" packages.
Snapscope fits perfectly into that kind of dynamic: It doesn't say that Snap is insecureInstead, it offers data that helps improve it. The difference between repeating a mantra (“it’s safe, trust it”) and showing a concrete report with CVEs, dates, and versions is significant, especially for users and companies that need to justify technical decisions.
Practical use: who benefits most from Snapscope
Although anyone can go online and search for a package out of curiosity, Snapscope is especially useful for three profiles very clear within the GNU/Linux ecosystem.
First, System administrators who manage environments with many Snaps installedFor them, having a tool that allows them to quickly check the security status of critical packages is invaluable. They can review which applications have the most pending CVEs, prioritize migrations or replacements, or even decide whether to continue using a Snap or opt for another format.
In second place, Snap package developers and maintainers They find Snapscope a convenient ally. It allows them to see at a glance which vulnerabilities affect the libraries they've included in their package, linking to the information needed to update dependencies and release new patches. Furthermore, the fact that anyone can request a new scan adds a healthy layer of pressure to keep the software up to date.
And thirdly, users concerned about security People who want to be clear about the risks before installing something can, before clicking "install" in the Snap Store, use Snapscope to quickly check the package's health. The goal isn't to cause alarm, but to provide tools for making informed decisions.
Relationship with other formats and the role of Canonical
One of the points that is often misinterpreted is the idea that Snapscope would prove that Snap is worse or less secure than other formats.Nothing could be further from the truth: the same vulnerable libraries detected in a Snap could be packaged in a DEB, an AppImage, a Flatpak or even in a container, and Grype would still be able to flag them.
In fact, if the same type of analysis were configured for traditional DEB packages or container imagesVery similar vulnerabilities, both in number and type, would likely appear. The difference is that, for now, the tool has focused on Snaps because that's the ecosystem in which Alan Pope is most comfortable.
On behalf of Canonical, The company has worked on reducing the attack surface and improving performance of the format both on desktop and servers, an example of the recent challenges in Linux softwareThe "base snaps" mentioned earlier, the improvement in start times, and the strict lockdown are all part of that ongoing effort.
Some critics have also pointed out aspects such as the Snap Store's proprietary backend or automatic update policyThis has even led distributions like Linux Mint to limit the use of Snap by default. In this context, an external tool like Snapscope can serve as a bridge: it provides objective data and allows each user to decide to what extent it is worthwhile to use this format.
Alan commented that You cannot directly integrate your work into the Snap StoreBecause that would require changes and access to Canonical infrastructure that he doesn't have. However, he has indicated that Canonical is free to take ideas or code from the project to integrate or evolve it, whether in the form of a public service or other kind of internal auditing tools.
Updates, rescans and future evolution of the tool
An interesting detail about Snapscope is that It allows you to rescan the same packet multiple times.At first glance it may seem redundant, but it makes perfect sense: vulnerability databases are constantly being updated, so a scan today may yield different results than one from last week, even if the Snap hasn't changed.
This explains why Multiple requests for analysis for the same version of a package appear on the webEach new scan benefits from the latest information available in security data sources, potentially revealing issues that were not previously listed.
Regarding future improvements, Alan has expressed interest in to be able to scan different revisions and channels of the same Snap (For example, stable, beta, edge, or ESR versions of applications like Firefox and Thunderbird). Currently, it's limited by the capabilities of the underlying tools, but there are open issues and pull requests to add support for selecting specific revisions. Once that functionality is mature, the idea is to integrate it into Snapscope.
Meanwhile, the project remains a work in progress that is already very useful in its current stateAs the community uses it, reports problems, and suggests improvements, its scope and accuracy are expected to grow, just as vulnerability databases themselves do.
Snapscope positions itself as a key tool for shedding light on the actual security of Snap packages.Without resorting to easy alarmism or blindly defending the format, it offers clear data, helps identify outdated libraries, encourages maintainers to get their act together, and gives users and administrators a practical tool for making informed decisions. In an ecosystem where debates about performance, trust in repositories, and update models coexist, having a standalone scanner like this makes a significant difference.