fix: [bug description] Not able to generate any vuln report in STDOUT nor SBOMs for mounted qcow2

[omkhard]

Description

Not able to generate any vuln report in STDOUT nor SBOMs for mounted qcow2

To reproduce

okhard@keep-platform-utility:~/$ cve-bin-tool /mnt/
[11:20:22] INFO cve_bin_tool - CVE Binary Tool v3.4 cli.py:624
INFO cve_bin_tool - This product uses the NVD API but is not endorsed or cli.py:625
certified by the NVD.
INFO cve_bin_tool - For potentially faster NVD downloads, mirrors are available cli.py:628
using -n json-mirror
[11:20:23] INFO cve_bin_tool - Getting NVD CVE data... nvd_source.py:389
INFO cve_bin_tool - Getting GitLab Advisory Database CVEs... gad_source.py:86
INFO cve_bin_tool - Getting RedHat CVEs... redhat_source.py:69
INFO cve_bin_tool - Getting PURL2CPE data... purl2cpe_source.py:36
ERROR CVEDB - Unable to fetch EPSS, skipping EPSS. epss_source.py:158
Downloading CVEs... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:41
[11:24:55] INFO cve_bin_tool - Adding 35598 RedHat CVE entries redhat_source.py:136
[11:29:12] INFO cve_bin_tool - Getting Open Source Vulnerability Database CVEs... osv_source.py:161
Killed

Expected behaviour: Should show the vulnerable packages with CVE in stdout as well as in SBOM if sbom tags are given.
Actual behaviour: Not happening as Expected.

Version/platform info

Version of CVE-bin-tool( e.g. output of cve-bin-tool --version):
Installed from pypi or github?
Operating system: Linux/Windows (other platforms are unsupported but feel free to report issues anyhow)

• okhard@keep-platform-utility:~/$ uname -a
  Linux keep-platform-utility 5.15.0-122-generic 132-Ubuntu SMP Thu Aug 29 13:45:52 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
• okhard@keep-platform-utility:~/$ python3 --version
  Python 3.10.12
  Running in any particular CI environment we should know about? (e.g. Github Actions)

[terriko]

That last line is just Killed which tells me that your setup killed the job for some reason, probably a timeout but it could be disk space.

Potential things to try:

• make sure there's no timeouts that are terminating the job early. How long you need will depend on your network connection/disk speed for data updates but probably you need at least a half hour the first time you run things and after that you'll have a cache so it should be faster?
• Make sure you have enough disk space. The full CVE data takes over 2.5G of space.
• Try skipping some of the data sources and seeing if that helps
• Try separating out the data cache update and the scan into separate jobs so a random network timeout won't block your scan.

[omkhard]

There is over ~ 9G of space present in root fs ,

okhard@keep-platform-utility:~/$ df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 1.6G 1.2M 1.6G 1% /run
/dev/vda1 78G 69G 9.2G 89% /
tmpfs 7.9G 168K 7.9G 1% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 7.9G 216K 7.9G 1% /run/qemu
/dev/vda15 105M 6.1M 99M 6% /boot/efi
tmpfs 1.6G 12K 1.6G 1% /run/user/1006
/dev/loop7 2.3G 2.3G 0 100% /tmp/mntsomething
/dev/mapper/debian-root 25G 6.0G 18G 26% /mnt

still the cve-bin-tool keeps on getting killed , may I know what are the other minimum requirements for running cve-bin-tool?

I tried -l debug which even didn't give any error regarding space , disk or io operation related.

[terriko]

Maybe it was killed due to memory issues? I can't really debug this from the cve-bin-tool side, so you'll need to use your linux utilities to figure it out. I'd start with dmesg | less personally. Those logs rotate so you might have to try running it again just so you can watch and see what happens.

In case you've never debugged something similar, here's a random blog post that explains a bit more about figuring out when something was killed by the system: https://www.baeldung.com/linux/what-killed-a-process -- it might not be the answer for you but I don't want to assume that you've ever read a dmesg trace before so I figured I'd include something with more detail.

[terriko]

Also, I don't think you're using github actions but I will say that I've been seeing jobs killed after about 30-45 minutes even when their timeouts are set considerably longer, so I won't rule out being killed by a timeout if you're running in a CI or cloud system that may have additional restrictions enabled.