Hello! I made something that might be useful for Snap publishers. It scans snaps for vulnerabilities. It’s called SnapScope, and you can see it at:
It scans any snap package you specify that is publicly available on the Snap Store. Each publisher has a page where you can view previously scanned snaps, results, and the queue of snaps waiting to be checked.
I made a 5-minute video to show you around:
https://www.youtube.com/watch?v=-hB2Z2xI5vY
Feedback and suggestions welcome!
It’s amazing and I’ve already rebuilt some of my snaps based on SnapScope data! Thanks so much for this.
Thanks! A truly useful tool.
Thanks for the feedback.
I plan to move this to a separate repo, and take issues and pull requests on it. It’s already open source, but the version in “production” (such that it is), is ahead of the repo.
Once I have a little time (likely over the christmas break), I’ll put it in a repo and follow up here.
In the meantime, if anyone has suggestions for improving it, let me know.
Some things I have been noodling:
Further suggestions would be most welcome!
Thanks for building this @popey - however I notice a lot of false-positives - it doesn’t seem to know about versions properly
e.g. from https://snapscope.popey.com/scan/6639 we see
which only affects emacs before 29.4 and it seems to know this is emacs 30.2 so it seems false to say it is vulnerable.
Do you know what might be happening here?
Hey @alexmurray - thanks for the feedback - this is very helpful.
I think this could be an upstream issue in syft/grype. I filed it here: https://github.com/anchore/grype/issues/3122
Everything shown is based on data from Syft and Grype.
Grype pulls from distro and other feeds via vunnel, into grype-db.
Syft generates the SBOM, and Snapscope stores that. Grype reads the SBOM and compares it with the vulnerability database, which is updated frequently. Grype also has Syft built in as a library, so while Snapscope uses Syft to build the SBOM, Grype can internally do that, without calling Syft first.
Note that support for introspecting snaps was landed relatively recently (a short while before I left Anchore in September), and there are still missing features, such as scanning specific revisions and specifying different architectures.
Let’s look at your specific example, let’s manually run grype against the emacs snap. Note that I’m specifying --distro because otherwise it doesn’t detect the “OS” (base snap) the snap was built on top of (core22,core24 etc). Snapscope does this too.
$ grype snap:emacs --distro ubuntu:24.04
✔ Downloaded snap emacs@stable (amd64)
✔ Indexed file system 4gE2S31SnK2LeqsZF8XTPuHOlqlzbqsW_3516.snap
✔ Cataloged contents 4dfa0a42afe4b18ebe2dc78129c8555e7c7d8d1f5da49883da842b058f51e666
├── ✔ Packages [355 packages]
├── ✔ File metadata [5 locations]
├── ✔ File digests [5 files]
└── ✔ Executables [1,386 executables]
✔ Scanned for vulnerabilities [11 vulnerability matches]
├── by severity: 0 critical, 0 high, 5 medium, 6 low, 0 negligible
NAME INSTALLED TYPE VULNERABILITY SEVERITY EPSS RISK
emacs 30.2 deb CVE-2024-39331 Medium 0.4% (62nd) 0.2
binutils 2.42-4ubuntu2.8 deb CVE-2025-1180 Medium 0.3% (50th) 0.1
emacs 30.2 deb CVE-2025-1244 Medium 0.2% (43rd) 0.1
binutils 2.42-4ubuntu2.8 deb CVE-2017-13716 Low 0.2% (46th) < 0.1
libgcrypt20 1.10.3-2build1 deb CVE-2024-2236 Low 0.2% (44th) < 0.1
emacs 30.2 deb CVE-2024-53920 Medium 0.1% (31st) < 0.1
binutils 2.42-4ubuntu2.8 deb CVE-2025-1150 Low 0.2% (40th) < 0.1
binutils 2.42-4ubuntu2.8 deb CVE-2025-1152 Low 0.2% (40th) < 0.1
binutils 2.42-4ubuntu2.8 deb CVE-2025-1151 Low 0.2% (38th) < 0.1
emacs 30.2 deb CVE-2024-30202 Medium < 0.1% (15th) < 0.1
libxml2 2.9.14+dfsg-1.3ubuntu3.6 deb CVE-2025-8732 Low < 0.1% (0th) < 0.1
So that’s where the data comes from. Grype also has an ‘explain’ feature, which tells you why a vuln shows up.
$ grype snap:emacs --distro ubuntu:24.04 --output json | grype explain --id CVE-2024-39331
[0000] WARN grype explain is a prototype feature and is subject to change
✔ Downloaded snap emacs@stable (amd64)
✔ Indexed file system 4gE2S31SnK2LeqsZF8XTPuHOlqlzbqsW_3516.snap
✔ Cataloged contents 4dfa0a42afe4b18ebe2dc78129c8555e7c7d8d1f5da49883da842b058f51e666
├── ✔ Packages [355 packages]
├── ✔ Executables [1,386 executables]
├── ✔ File metadata [5 locations]
└── ✔ File digests [5 files]
✔ Scanned for vulnerabilities [11 vulnerability matches]
├── by severity: 0 critical, 0 high, 5 medium, 6 low, 0 negligible
CVE-2024-39331 from nvd:cpe (Critical)
In Emacs before 29.4, org-link-expand-abbrev in lisp/ol.el expands a %(...) link abbrev even when it specifies an unsafe function, such as shell-command-to-string. This affects Org Mode before 9.7.5.
Related vulnerabilities:
- ubuntu:distro:ubuntu:24.04 CVE-2024-39331 (Medium)
Matched packages:
- Package: emacs, version: 30.2
PURL: pkg:generic/snap/emacs@30.2?base=core24&type=app
Match explanation(s):
- ubuntu:distro:ubuntu:24.04:CVE-2024-39331 Direct match (package name, version, and ecosystem) against emacs (version 30.2).
Locations:
- /meta/snap.yaml
URLs:
- https://nvd.nist.gov/vuln/detail/CVE-2024-39331
- https://ubuntu.com/security/CVE-2024-39331
So we see here that the data about packages in use came from the /meta/snap.yaml.
$ snap download emacs
Fetching snap "emacs"
Fetching assertions for "emacs"
Install the snap with:
snap ack emacs_3516.assert
snap install emacs_3516.snap
unsquashfs emacs_3516.snap meta/snap.yaml
Parallel unsquashfs: Using 2 processors
1 inodes (1 blocks) to write
[==========] 2/2 100%
created 1 file
created 2 directories
created 0 symlinks
created 0 devices
created 0 fifos
created 0 sockets
created 0 hardlinks
$ cat squashfs-root/meta/snap.yaml
name: emacs
title: GNU Emacs
version: '30.2'
summary: GNU Emacs is the extensible self-documenting text editor
description: |
Emacs is the extensible, customizable, self-documenting real-time
display editor.
Features include:
* Content-aware editing modes, including syntax coloring, for many file types.
* Complete built-in documentation, including a tutorial for new users.
* Full Unicode support for nearly all human scripts.
* Highly customizable, using Emacs Lisp code or a graphical interface.
* An entire ecosystem of functionality beyond text editing, including a project
planner, mail and news reader, debugger interface, calendar, and more.
* A packaging system for downloading and installing extensions.
This snap is built via the build.snapcraft.io service from the
snapcraft.yaml definition at https://github.com/alexmurray/emacs-snap to
ensure source and build transparency.
The snap offers both the 'gtk' and 'pgtk' variants in separate snap tracks -
the 'latest' track offers the gtk variant whereas the 'pgtk' track offers the
pgtk variant of emacs.
license: GPL-3.0+
architectures:
- amd64
base: core24
assumes:
- command-chain
apps:
emacs:
command: usr/bin/emacs
command-chain:
- setup-env
emacsclient:
command: emacsclient
ctags:
command: usr/bin/ctags
ebrowse:
command: usr/bin/ebrowse
etags:
command: usr/bin/etags
confinement: classic
grade: stable
Looking at the snapcraft.yaml in the snap, I note you’re using the upstream source, but syft thinks it’s the emacs deb.
Does Grype only parses the meta/snap.yaml?
No, it parses other files as well, but perhaps not optimally, which is why I filed an issue.
(Technically, it’s syft that parses them, not grype, but grype uses syft as a library too, so this is just a minor point)
Thanks to this I removed all the stage packages from joplin-desktop to ensure a perfect score. Technically it was only one package anyway (libnotify-bin) but I’ll never get another email about libxml for that snap again 
(Please don’t peek further into the Electron bits and ruin my perfect score, npm during the build scares me enough)
(p.s notifications still work because Electron bundles its own libnotify these days)
I am delighted that this tool (rightly or not) has triggered some snap publishers to re-examine their snaps. This can only be a good thing.
I am hoping this PR helps, along with another which landed before mine.