Kushal Das

FOSS and life. Kushal Das talks here.


SBOM and vulnerability scanning

Software Bill of Materials became one of the latest buzzword. A lot of people and companies talking about it like a magical thing, if you use it then all of your security problems will be solved, just like what happened with Blockchain!!.

Though a hand full of projects (or companies building those projects) focused on the actual tooling part. Things we can use and see some useful output than blogposts/presentations with fancy graphics.

In this post we will try to see how can we use these tools today (2023/09/20).

SBOM currently comes in two major flavors, SPDX aka Software Package Data Index and CycloneDX. There are existing tooling to convert in between.


We will use syft from Anchore to generate our SBOM(s).

This tool can generate from various sources, starting from container images to Python projects, RPM/Debian dbs, Rust or Go projects.

Let us generate the SBOM for a Debian 12 VM.

$ syft /var/lib/dpkg -o spdx-json=server.spdx.json --source-name debian12 
 ✔ Indexed file system                                                                                         /var/lib/dpkg
 ✔ Cataloged packages              [395 packages]  

For for a Rust project:

$ syft /home/kdas/code/johnnycanencrypt/Cargo.lock -o spdx-json=jce.spdx.json
 ✔ Indexed file system                                                                      /home/kdas/code/johnnycanencrypt
 ✔ Cataloged packages              [203 packages]

We generated the SBOMs. Now this should solve the security issues, isn't?

SBOM joke

I found the above in Matthew Martin's timeline.


This is where Grype comes handy, it is a vulnerability scanner for container images and filesystems and works with the SBOM(s) generated by syft.

$ grype jce.spdx.json 
 ✔ Vulnerability DB                [updated]  
 ✔ Scanned for vulnerabilities     [1 vulnerability matches]  
   ├── by severity: 0 critical, 0 high, 1 medium, 0 low, 0 negligible
   └── by status:   1 fixed, 0 not-fixed, 0 ignored 
time  0.1.45     0.2.23    rust-crate  GHSA-wcg3-cvx6-7396  Medium


grype server.spdx.json 
 ✔ Vulnerability DB                [no update available]  
 ✔ Scanned for vulnerabilities     [178 vulnerability matches]  
   ├── by severity: 6 critical, 136 high, 34 medium, 2 low, 0 negligible
   └── by status:   0 fixed, 178 not-fixed, 0 ignored 
file     1:5.44-3                      CVE-2007-1536     High      
git      1:2.39.2-1.1                  CVE-2020-5260     High      
gnupg    2.2.40-1.1                    CVE-2022-3515     Critical  
gnupg    2.2.40-1.1                    CVE-2022-34903    Medium    
gnupg    2.2.40-1.1                    CVE-2022-3219     Low       
openssl  3.0.9-1                       CVE-2023-4807     High      
openssl  3.0.9-1                       CVE-2023-3817     Medium    
openssl  3.0.9-1                       CVE-2023-2975     Medium    
openssl  3.0.9-1                       CVE-2023-1255     Medium    
perl     5.36.0-7                      CVE-2023-31486    High      
perl     5.36.0-7                      CVE-2023-31484    High      
vim      2:9.0.1378-2                  CVE-2022-3520     Critical  
vim      2:9.0.1378-2                  CVE-2022-0318     Critical  
vim      2:9.0.1378-2                  CVE-2017-6350     Critical  
vim      2:9.0.1378-2                  CVE-2017-6349     Critical  
vim      2:9.0.1378-2                  CVE-2017-5953     Critical  
vim      2:9.0.1378-2                  CVE-2023-4781     High      
vim      2:9.0.1378-2                  CVE-2023-4752     High      


Now it is on your team members to decide how to react to information we gather from these tools. The tools themselves will not solve the problems at hand. You have to decide the update steps and if that is at all required or not.

Also please remember, there is and will be a lot of false positives (not in Grype output yet, but other tools in the SBOM ecosystem). The projects (I am talking about in general most of the tooling in this field) are trying hard to reduce these, but not possible always to remove every such edge case.

Fixing missing yubikey trouble on fedora 38

From the time I updated to Fedora 38, I am having trouble with my Yubikey. If I remove the key, just plugging it back does not help. gpg can not detect it.

$ gpg --card-status 
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

The only way to get it working is restarting the pcscd service, again & again.

As Heiko pointed out, this is the trouble between pcscd and scdaemon, the second one comes via gnupg package in Fedora.

To solve the issue, first I tried the following

$ echo disable-ccid >> ~/.gnupg/scdaemon.conf
$ gpgconf --reload gpg-agent

Then I figured that I have opensc package installed, just removing that one and then a reboot solved the trouble for me.

$ sudo dnf remove opensc -y

Tumpa 0.10.0 is ready

I am happy to announce Tumpa 0.10.0 release. Tumpa is a desktop application which allows you to create OpenPGP keys and also allows uploading them to Yubikeys with a user friendly GUI. With Tumpa, all you need is a few form inputs and few clicks, and done! No more wrangling and breaking your head with command line interface.


This version is a complete rewrite of the initial version I released around 2 years ago. With the help from Elio and his excellent team, we have a new design. Thank you OTF for providing the funding for the work.

Saptak & I decided that the code is ready to be consumed. There are still things to work on, including the UI flows. In the coming months we are going to add more features to the application to make it super useful for advanced users too.

You can create Cv25519 or RSA4096 keys via the "Generate Key" button. You can upload any key to an attached Yubikey, but remember that to use a Cv25519 key, you will need Yubikey 5.

Showing all avaialble keys


For Linux we have an AppImage and for Apple M1/M2 devices we have a dmg. You can download them from the release page. Remember to have a look at the user guide, specially because you need to have pcscd service running on Linux.

Upload successful

Technologies used

This project works because we have Johnnycanencrypt , a Python module written in Rust to do OpenPGP operations (including Smartcard operations). Which in turn uses Sequoia Project for the rust library to create/manipulate OpenPGP keys.

The UI is made via QML, using PySide6. This also shows that we can have decent looking desktop applications in Python.

The AppImage and Apple dmg files are available because of briefcase project from BeeWare team.

Give feedback

Since the focus of Tumpa is on making the use of OpenPGP with smart cards user friendly and intuitive, we need a lot of feedback from the user. So, if you find issues and have other feedback to improve the application, feel free to submit [issues])(https://github.com/tumpaproject/tumpa/issues). We are also available in #tumpa channel on IRC on libera.chat server. Feel free to ping the IRC nicknames saptaks or kushal.