Why Scanning for CVEs is Essential in Open Source Software Maintenance
Scanning your open source software for CVEs (Common Vulnerabilities and Exposures) is a very important maintenance step for any software project.
Generally, these CVEs are stored in publicly accessible databases (such as the National Vulnerability Database or the NVD) with an associated package name (openssl, openssh, busybox, mbedtls, etc.). Security scanning tools can then access these databases and process this available CVE information appropriately. For example, each entry in the NVD has an associated severity score and attack vector. As you would expect, the most concerning entries tend to be ones with a high vulnerability score and a network-based attack vector. Security scanning tools can help you sort for these specific criteria, so you know which CVEs should be patched most urgently.
So, how do these security scanning tools know which packages you are using in your software? This is what the SBOM (Software Bill of Materials) and associated specifications like SPDX, CycloneDX, and SWID are attempting to solve.
How to Generate SBOMs from Linux Binaries
What if you don’t have access to the sources or don’t have an SBOM? Intel’s cve-bin-tool attempts to scan produced code binaries to determine which source packages are associated.
Let’s say we have a Linux distribution’s root filesystem available, but do not have any corresponding source information. We can extract the filesystem and generate an SBOM using cve-bin-tool via:
$ tar -xf linux_rootfs.tar.gz $ cve-bin-tool . --sbom-type spdx --sbom-output output.spdx
This generates output.spdx, which we can feed into other scanning tools.
Interestingly, when I ran it on this particular root filesystem, it detected a Linux kernel version of 3.16. The root filesystem tarball itself does not have the kernel or bootloader included… so to see what it was doing, I added debug logging to the CLI:
$ cve-bin-tool . --sbom-type spdx --sbom-output output.spdx -ldebug <clipped> DEBUG ... contains /lib/firmware/tee-raw.bin contains linux_kernel 3.16.0 version_scanner.py:273 <clipped>
So, an OP-TEE binary inside our root filesytem is being incorrectly picked up as the Linux kernel. This raises a good point — you probably need to manually adjust the SBOM for the Linux kernel and bootloader.
Let’s do that now. Edit your output.spdx file:
$ /bin/your-favorite-text-editor output.spdx
Check for any existing entries for the kernel or bootloader which may have inappropriate version tags. In this case, we see:
PackageName: linux_kernel SPDXID: SPDXRef-Package-7-linux-kernel PackageVersion: 3.16.0
So, I’ll replace 3.16.0 with our real version (5.10.184-sp0)
I do not see our bootloader included anywhere (U-Boot). I’ll manually add an entirely new entry for that too:
PackageName: u-boot SPDXID: SPDXRef-Package-10-u-boot PackageVersion: 2020.01 PrimaryPackagePurpose: LIBRARY PackageSupplier: Organization: u-boot PackageDownloadLocation: NOASSERTION FilesAnalyzed: false PackageLicenseDeclared: NOASSERTION PackageLicenseConcluded: NOASSERTION PackageCopyrightText: NOASSERTION ##### Relationship: SPDXRef-Package-1-CVEBINTOOL- DEPENDS_ON SPDXRef-Package-10-u-boot
You can then feed this SBOM into your security scanning tool of choice.
Analyzing CVEs: Comparing Tools and Techniques
Feel free to skip this section if you’re not interested in an analysis or comparison of the CVE lists generated by the associated tools. We find it interesting, but if all you wanted to know was how to generate an SBOM from a prebuilt system, this may not be of interest to you.
If you are interested — we can then feed this SBOM back into cve-bin-tool:
$ cve-bin-tool --sbom spdx --sbom-file output.spdx ... ╭─────────────╮ │ CVE SUMMARY │ ╰─────────────╯ ┏━━━━━━━━━━┳━━━━━━━┓ ┃ Severity ┃ Count ┃ ┡━━━━━━━━━━╇━━━━━━━┩ │ CRITICAL │ 8 │ │ HIGH │ 148 │ │ MEDIUM │ 307 │ │ LOW │ 11 │ │ UNKNOWN │ 0 │ └──────────┴───────┘
These CVEs are spread across 7 packages:
| Package/Source Tree | Version | CVE Count |
|---|---|---|
| busybox | 1.35.0 | 2 |
| linux | 5.10.184 | 452 |
| glibc | 2.35 | 6 |
| gcc | 11.3.0 | 1 |
| ncurses | 6.3 | 2 |
| zlib | 1.2.11 | 4 |
| u-boot | 2020.01 | 7 |
However, Vigiles does a more accurate job, so let’s pass it the same SBOM and see what happens:
$ git clone https://github.com/TimesysGit/vigiles-cli.git $ cd vigiles-cli $ pip3 install . $ vigiles -k /path/to/linuxlink_key manifest upload output.spdx
Note: key is generated through the Preferences menu in LinuxLink: https://linuxlink.timesys.com/user/prefs. See here if you need more help.
After running this command, you should see a JSON list of identified CVEs being returned. The Vigiles web dashboard will also have the associated workspace:
These CVEs are also spread across 7 packages:
| Package/Source Tree | Version | CVE Count |
|---|---|---|
| busybox | 1.35.0 | 2 |
| linux | 5.10.184-sp0 | 173 |
| glibc | 2.35 | 5 |
| bash | 5.1.16 | 1 |
| ncurses | 6.3 | 2 |
| zlib | 1.2.11 | 3 |
| u-boot | 2020.01 | 7 |
Understanding the Differences: cve-bin-tool vs. Vigiles
We can see that cve-bin-tool gave 474 vulnerabilities and Vigiles gave 193. Why is Vigiles giving fewer results? It’s complicated, but it boils down to a combination of the curated CVE database Timesys uses and maintains, coupled with CVE filtering techniques.
For example, Vigiles is reporting a CVE for bash which is not reported by cve-bin-tool (CVE-2022-3715). Looking at the NVD page for this, we see:
So, cve-bin-tool did not select it as a possible CVE because the version is outside of that specific range (5.1.16 > 5.1.8).
However, this is where our curated database does better. Looking at the originating bug tracker entry on Redhat, we can see that they thought it was fixed in 5.1.8, but later found another heap overflow in 5.1.16. The NVD has not been updated to acknowledge this. So we curate this and keep track of it ourselves:
SBOM Generation directly from Yocto
It turns out linux_rootfs.tar.gz in the previous section was actually generated by me using Yocto. For fun, what happens if we instead used Vigiles from Yocto directly via meta-timesys?
We get far fewer vulnerabilities detected (only 90 unfixed!):
These CVEs are spread across 5 packages:
| Package/Source Tree | Version | CVE Count |
|---|---|---|
| u-boot | 2020.01 | 5 |
| linux | 5.10.184-sp0 | 78 |
| glibc | 2.35 | 5 |
| ncurses | 6.3.20220423 | 1 |
| bash | 5.1.16 | 1 |
Why is the Yocto-based result even more accurate, with far fewer CVEs being shown? This is because of the filtering Vigiles is capable of doing when it has sources available.
Vigiles can track patches that fix CVEs and mark them as fixed. Additionally, Vigiles can extract the kernel and u-boot configuration and filter out vulnerabilities in code that has not been compiled in and is therefore not present.
Unlock Your Security Potential with The Vigiles Advantage
Why use Vigiles when there are other tools available?
-
- It’s a workflow tool which your company can use to manage CVEs from end to end.
-
- Manage multiple SBOMs
- Manage multiple products and releases
- Create, share, and compare reports
- Add custom filters
- Add JIRA Integration
- Receive notifications
- … and more!
-
- We do more filtering to save our customers more time:
-
- Package option filtering
- Kernel config filtering (usually cuts CVEs down by > 50%)
- U-Boot config filtering
-
- Fewer false positives. Timesys has put a great amount of time and effort into reducing false positives during our scanning.
-
- For LTS Linux kernels, we also track backported fixes to reduce false positives
-
- Our curated database pulls information from multiple sources, not just the NVD.
- It’s a workflow tool which your company can use to manage CVEs from end to end.
Conclusion
I hope this post was a helpful tool for understanding the importance of utilizing security scanning tools via SBOM generation. SBOMs give us a great way to easily convey which source packages are being used in our projects. In turn, this enables security scanning tools, like Vigiles, to interpret the same data and provide us with source and version based security analyses (like CVE lists), management strategies, and management workflows.
Get Expert Help with Your Security Needs
As always, we offer professional engineering services to help you with your project. Whether you wish for us to integrate our security feature implementation, called Vigishield, into your project, scan your project for CVEs using Vigiles, or just need another set of hands to help with general embedded software engineering and security, we’re available to help!
