Publish once-off grype-db with hardware (:h:) and platform (:o:) CPEs included

[tgagneret-embedded]

What happened:

I'm trying to use grype to search for vulnerability for an embedded project using a SBOM file (using cycloneDX specification).I add an embedded components like freeRTOS, STM32L4 firmware, ... with an associated "cpe" field since "purl" is not adapted here. Then I run grype, but it is not matching any CVE (but there are).

What you expected to happen:
Grype shoud find CVE for FreeRTOS and STM32L4.

How to reproduce it (as minimally and precisely as possible):
You can use the following SBOM file and run grype -vv sbom:file.json.
{ "bomFormat": "CycloneDX", "specVersion": "1.4", "serialNumber": "urn:uuid:8454585a-e0ad-4c8c-8721-114fd54605c6", "version": 1, "components": [ { "type": "device", "name": "stm32l4", "scope": "required", "cpe": "cpe:2.3:o:st:stm32l4_firmware:-:*:*:*:*:*:*:*" }, { "type": "firmware", "name": "stm32l4_firmware", "scope": "required", "cpe": "cpe:2.3:o:st:stm32cubel4_firmware:-:*:*:*:*:*:*:*" }, { "type": "framework", "name": "github.com/FreeRTOS/FreeRTOS-Kernel", "scope": "required", "cpe": "cpe:2.3:o:amazon:freertos:*:*:*:*:-:*:*:*" } ] }

Anything else we need to know?:
Depending on "type" field, it seems that grype doesn't search for any vulnerablity, but that's not the only issue.

Environment:

• Output of grype version:

• [0000] INFO grype version: 0.46.0
  [0000] DEBUG ├── buildDate: 2022-08-04T14:48:21Z
  [0000] DEBUG ├── compiler: gc
  [0000] DEBUG ├── gitCommit: c755c73
  [0000] DEBUG ├── gitDescription: v0.46.0
  [0000] DEBUG ├── goVersion: go1.18.4
  [0000] DEBUG ├── platform: linux/amd64
  [0000] DEBUG ├── syftVersion: v0.53.4
  [0000] DEBUG └── version: 0.46.0
  [0000] DEBUG No new grype update available

• OS (e.g: cat /etc/os-release or similar):
  ArchLinux

Thanks for the help.

[westonsteimel]

Thanks for the report @tgagneret-embedded . This happens because we currently only load application type CPEs into the published grype databases (since we know syft and grype can't yet discover them), so there is currently no data available for it to match on. We might be able to investigate letting these flow through although I suspect it might greatly inflate the db size

Cc: @wagoodman @spiffcs @joshbressers

[joshbressers]

This is probably part of a larger discussion around supporting IoT and embedded

We know we want to do this, but we also don't have a ton of data or examples to start the journey

[tgagneret-embedded]

I'm not sure what you mean by 'data', but If you need some components that are widely used in embedded (MCU), I can provide you a short list for your tests ?

[joshbressers]

@tgagneret-embedded Yeah, that's what I mean. If you have some examples we can look at it would be extremely helpful!

[tgagneret-embedded]

You can find some components used in embedded system in the following SBOM:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:8454585a-e0ad-4c8c-8721-114fd54605c6",
  "version": 1,
  "components": [
    {
      "type": "device",
      "name": "stm32l4",
      "scope": "required",
      "cpe": "cpe:2.3:o:st:stm32l4_firmware:-:*:*:*:*:*:*:*"
    },
    {
      "type": "device",
      "name": "nrf52840",
      "scope": "required",
      "cpe": "cpe:2.3:h:nordicsemi:nrf52840:-:*:*:*:*:*:*:*"
    },
    {
      "type": "firmware",
      "name": "stm32l4_firmware",
      "scope": "required",
      "cpe": "cpe:2.3:o:st:stm32cubel4_firmware:-:*:*:*:*:*:*:*"
    },
    {
      "type": "framework",
      "name": "github.com/FreeRTOS/FreeRTOS-Kernel",
      "scope": "required",
      "cpe": "cpe:2.3:o:amazon:freertos:*:*:*:*:-:*:*:*"
    },
    {
      "type": "framework",
      "name": "github.com/zephyrproject-rtos/zephyr",
      "version": "2.0.0",
      "scope": "required",
      "cpe": "cpe:2.3:o:zephyrproject:zephyr:-:*:*:*:*:*:*:*"
    },
    {
      "type": "framework",
      "name": "azure_rtos",
      "scope": "required",
      "cpe": " cpe:2.3:o:microsoft:azure_rtos:*:*:*:*:*:*:*:*"
    },
    {
      "type": "library",
      "name": "github.com/Mbed-TLS/mbedtls",
      "version": "2.17.0",
      "scope": "required",
      "cpe": "cpe:2.3:a:arm:mbed_tls:*:*:*:*:*:*:*:*"
    },
    {
      "type": "library",
      "name": "lwip",
      "scope": "required",
      "cpe": "cpe:2.3:a:lwip_project:lwip:-:*:*:*:*:*:*:*"
    }
  ]
}

I hope it helps :)

Thanks

[tgagneret-embedded]

Hi,

Is it possible to have a status on this feature ?

Thanks :)

[tgerla]

Hi @tgagneret-embedded, sorry, we do not have a status update for you at this point. We will leave this issue open for tracking. In the meantime, if you are interested in working on this please feel free to join our Slack channel and we would be happy to get you pointed in the right direction. Thanks!

[willmurphyscode]

Discussion notes: Last time we had a request to include CPEs beyond the :a: type CPEs, we said no because it would make the download size of Grype's database a lot bigger. However, schema v6 compresses better, and schema v7 will (eventually) allow parts of the database to be downloaded only if needed, which both might mitigate that drawback.

I've add the needs-discussion label so we can kick off a discussion of how future grype db schemas might include the data to do this, and maybe even how Syft and Grype might detect the packages. (But even if we can't detect the packages, Grype being able to match against the packages in the embedded software ecosystem might be valuable, in case someone brings their own SBOM supplied by their build tooling.)

[willmurphyscode]

Hi @tgagneret-embedded, we just discussed this issue on our livestream, and we have a couple updates:

1. Grype-DB, the tool that builds Grype databases, now has a config switch to include h and o CPEs: Add config for CPE part filtering grype-db#410
2. We plan to build a once-off grype DB that includes both h and o CPEs, host it in our infrastructure, and post a link here. We'd be very interested in how Grype performs today against your SBOMs when the DB includes these CPEs.

Thanks!

[jurassicLizard]

@willmurphyscode As we had discussed I have had with #2365 a similar conundrum. Is it possible to use the grype-db tool you mentioned to cache the database locally including o and h parts and thus circumvent the issue ? or will that new option just accept the cpe's without resolving them against the vulnerability database. Thank you for your support