Checking Ubuntu Security Notices for a snap

Snap publishers will receive emails periodically from the store indicating stage-packages that their snap revisions were built with that are now out of date and can be updated to resolve Ubuntu Security Notices (USN’s) which are associated with CVE’s.

However, it is also possible for anyone to perform this same check and see what packages a snap was built with that have USN’s associated with them, provided two things.

  1. They have access to the snap file (either through snap download from the store or possibly from their own machine.
  2. That the snap file was built with a manifest.yaml, which is produced by snapcraft by default when the snap is built in launchpad or on, or via the GitHub Action for snapcraft or if the snapcraft option --enable-manifest is specified or finally if the environment variable SNAPCRAFT_BUILD_INFO=1 is defined when snapcraft is run to build the snap.

To check the USN’s for a snap, one has to install the review-tools snap, which provides a command, check-notices, to do this, and it produces JSON output. For example:

$ review-tools.check-notices somesnap_80.snap
  "somesnap": {
    "80": {
      "libglib2.0-0": [
      "libtiff5": [

The referenced numbers are USN numbers, information about which can be found at (or directly with the USN number at for the libglib2.0-0 package in the example above).

Database prefetch

If you are doing this at the same time for multiple snaps, you can pre-fetch and cache the USN database that is used for this:

$ cd $HOME/snap/review-tools/common
$ review-tools.fetch-usn-db database.json.bz2

And then use check-notices with the --no-fetch argument:

$ review-tools.check-notices --no-fetch somesnap_80.snap


The fact that a snap was built with, or includes, a package that had a USN issued for it, does not automatically mean that the snap is vulnerable. The vulnerable part of the package may not actually be used by the snap, or snap confinement may protect the snap from being attacked and abused the same way that an attacker using the vulnerability may do with traditional unconfined Linux packages.


It might possibly be worth adding that the Github Build Action also defaults to creating a manifest, since it’s a fairly common way of producing snaps too.

1 Like

Great suggestion, I added a mention about that there

Great tool. Thanks.

Can this also be used to check core, core18 and core20 snaps?


It would be cool if it was additionally possible to query such information without needing the snap being available in the environment, so fetching the information from the store. If we need to prevent random people to access security information, it could require an auth using snap login. I think, this would make the process much easier.

Use case:

I want a GH action to just check if security notices are available, and eventually rebuild the same snap, just with fixed packages.

What happens:

I currently need to fetch my own snap from the store and then analyse it with review-tools.

What I would like to be possible:

review-tools.check-notices --use-store-snap my-snap --channel=stable
and to obtain the output directly from the server. A possible implementation could be that such info is stored in the store itself, for each snap, and gets updated in the same way which is employed to produce the email we currently receive.


Is this doc editable? :blush: I tried but failed :sweat_smile:

It is now - we just made it a wiki. Thanks for the ping.

1 Like

yes, you should be able to check core/18/20 with it too … (note that local snaps in /var/lib/snapd/snaps have their permissions set in a way you can not scan them easily, so better do a “snap download core20” and use a fresh download)

(one thing to notice for these snaps is that these snaps do not ship proper manifest.yaml files but instead have a usr/share/snappy/dpkg.list inside that lists the binaries they were built from, review-tools has a special case in the code for this)

1 Like