feat: Add locations in CycloneDX reports

[edhinard]

Description

The cycloneDX report could be enriched with the file location where the products are found.

Why?

I would like to use cve-bin-tool in cases where the syft or trivy metadata method doesn't work (embedded systems). I will continue to search for CVEs with grype. I would then need a standard format between cve-bin-tool and grype. CycloneDX seems to be a perennial solution. But the report made cve-bin-tool currently lacks the location information I need for further analysis. (By the way, having a SBOM only mode for cve-bin-tool would be great)

Suggestions

This could be done in two different ways:

1. under the "properties" key
2. under the "evidence" key

Solution 1 is the one chosen by syft. The "properties" key is intended for this kind of extension. It requires to register a namespace for cve-bin-tool. Here's an example of what it would look like:

...
  "components": [
...
    {
      "type": "library",
      "bom-ref": "17-linux_kernel",
      "name": "linux_kernel",
      "version": "2.6.14",
      "supplier": {
        "name": "linux"
      },
      "cpe": "cpe:/a:linux:linux_kernel:2.6.14",
      "properties": [
        {
            "name": "cve-bin-tool:location",
            "value": "/lib/modules/2.6.14.7-selinux1-WR1.5ag_cgl/kernel/drivers/ide/ide-generic.ko"
        },
        {
            "name": "cve-bin-tool:location",
            "value": "/lib/modules/2.6.14.7-selinux1-WR1.5ag_cgl/kernel/drivers/net/bonding/bonding.ko"
        }
      ]
    },
...

I prefer the second solution. Unless I'm mistaken, this is exactly what the designers of the cyclonedx format intended:

...
  "components": [
...
    {
      "type": "library",
      "bom-ref": "17-linux_kernel",
      "name": "linux_kernel",
      "version": "2.6.14",
      "supplier": {
        "name": "linux"
      },
      "cpe": "cpe:/a:linux:linux_kernel:2.6.14",
      "evidence": {
        "occurences": [
          {              
            "location": "/lib/modules/2.6.14.7-selinux1-WR1.5ag_cgl/kernel/drivers/ide/ide-generic.ko"
          },
          {
            "location": "/lib/modules/2.6.14.7-selinux1-WR1.5ag_cgl/kernel/drivers/net/bonding/bonding.ko"
          }
        ]
      }
    },
...

For files included in archives, the // separator could be used to concatenate container and content paths. For example the evidence file binary1.2.3.exe found in the archive /somewhere/zipfile.zip discovered in /a/certain/path/archive.tgz would be named: /a/certain/path/archive.tgz///somewhere/zipfile.zip//binary1.2.3.exe. This way, no information is lost and the path is still valid.

[terriko]

Thank you for this detailed feature request! We're already spitting out filenames that could be used as locations, so this should be very doable. Maybe even by one of the gsoc hopefuls who are looking for things to do while we wait for Google to open applications?

I'm also curious: What makes syft and trivy non-viable for your type of embedded systems? (Most of the embedded systems people I work with use Yocto which generates its own SBOMs.) If we're doing something special in this space I want to make sure we advertise it and lean in to doing it really well if we can!

[Mayankrai449]

@terriko @edhinard I would like to work on this. The second solution utilizing the "evidence" key seems better implementation. I would give it a try.

[ffontaine]

Hi @terriko, I'll answer concerning embedded systems, yocto or buildroot can indeed generate SBOMs. Ideally, those SBOMs shall be provided by the manufacturer to the client/customer. However, most of time, no SBOM is provided so the only thing that the "client/pentester" can do is run cve-bin-tool on the firmware.

Running syft on those firmwares will give no result because syft is using package metadata (such as debian dpkg files or OpenWRTopkg files) which are usually not available on embedded systems (with the exception of OpenWRT). For example, running syft /usr/sbin/dnsmasq will return nothing because syft is not extracting the version from the binary like cve-bin-tool. However, syft /usr/lib/opkg/info/dnsmasq.control will return the version contained in the text file. Unfortunately in the case of this OpenWRT file even if the version is correct, syft will generate an incorrect SBOM with a wrong CPE ID and an empty purl. With this incorrect SBOM, grype will fail to catch any CVEs.

[edhinard]

Hi @terriko, as explained by @ffontaine, when working with product from others we don't have he SBOM. Tools that can estimate the SBOM are of great help to evaluate the security risk. syft and trivy are very good for server and VM distros like redhat, suse, alpine... And cve-bin-tool seems very good for embedded systems.

[Mayankrai449]

@edhinard @terriko seems to me that cyclonedx sbom is generated using the sbom generation library lib4sbom. Since I cannot modify it directly, I added additional functionality in: https://github.com/intel/cve-bin-tool/blob/6a86564a518a68c306b872aeea9bef59568e4a4f/cve_bin_tool/output_engine/init.py#L897 It simply adds the required component parts manually. I guess there could be a better way to do this, but could not figure out how to utilize lib4sbom to add locations using evidence key. I did get the required result by adding locations in version_scanner.py and sbom_manager/init.py

Should I do a Draft Pull request for this modification?

[Mayankrai449]

@edhinard @terriko There is also a second doubt regarding locations of these products. For testing I used python modules and added locations using: Is there any place in codebase where I can directly get locations of all the products?