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

tgagneret-embedded · 2022-08-10T08:59:24Z

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.

The text was updated successfully, but these errors were encountered:

westonsteimel · 2022-08-10T11:32:15Z

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 · 2022-08-10T12:51:24Z

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 · 2022-08-11T07:24:03Z

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 · 2022-08-11T12:45:28Z

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

tgagneret-embedded · 2022-08-12T09:18:32Z

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 · 2022-09-08T09:29:31Z

Hi,

Is it possible to have a status on this feature ?

Thanks :)

tgerla · 2022-10-06T20:14:42Z

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 · 2024-09-30T14:53:15Z

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 · 2024-10-17T20:05:43Z

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

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
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 · 2025-01-15T09:05:35Z

@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

kzantow · 2025-05-12T19:30:07Z

Is this one working as expected now that we are publishing the h and o CPEs? This is output from the latest grype:

$ grype 'cpe:2.3:o:linux:linux_kernel:6.6.16:*:*:*:*:*:*:*'
 ✔ Scanned for vulnerabilities     [2084 vulnerability matches]  
   ├── by severity: 10 critical, 607 high, 1450 medium, 17 low, 0 negligible
   └── by status:   1985 fixed, 99 not-fixed, 0 ignored 
NAME          INSTALLED  FIXED-IN                                                                                                    TYPE  VULNERABILITY     SEVERITY 
linux_kernel  6.6.16     5.4.273, 5.10.214, 5.15.153, 6.1.83, 6.6.23, 6.7.11, 6.8.2                                                        CVE-2024-27053    Critical  
linux_kernel  6.6.16     5.10.214, 5.15.153, 6.1.83, 6.6.23, 6.7.11, 6.8.2                                                                 CVE-2024-35845    Critical  
...

jurassicLizard · 2025-05-13T08:10:01Z

Is this one working as expected now that we are publishing the h and o CPEs? This is output from the latest grype:

$ grype 'cpe:2.3:o:linux:linux_kernel:6.6.16:*:*:*:*:*:*:*'
 ✔ Scanned for vulnerabilities     [2084 vulnerability matches]  
   ├── by severity: 10 critical, 607 high, 1450 medium, 17 low, 0 negligible
   └── by status:   1985 fixed, 99 not-fixed, 0 ignored 
NAME          INSTALLED  FIXED-IN                                                                                                    TYPE  VULNERABILITY     SEVERITY 
linux_kernel  6.6.16     5.4.273, 5.10.214, 5.15.153, 6.1.83, 6.6.23, 6.7.11, 6.8.2                                                        CVE-2024-27053    Critical  
linux_kernel  6.6.16     5.10.214, 5.15.153, 6.1.83, 6.6.23, 6.7.11, 6.8.2                                                                 CVE-2024-35845    Critical  
...

It is except there is some peculiar behaviour when feeding a bom as cyclonedx

this doesnot work

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "components": [
    {
      "type": "operating-system",
      "name": "Linux Kernel",
      "version": "5.15.0",
      "cpe": "cpe:2.3:o:linux:linux_kernel:5.15.0:*:*:*:*:*:*:*"
    }
  ]
}

and this works

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "components": [
    {
      "type": "framework",
      "name": "Linux Kernel",
      "version": "5.15.0",
      "cpe": "cpe:2.3:o:linux:linux_kernel:5.15.0:*:*:*:*:*:*:*"
    }
  ]
}

so basically when the type is set to "framework" instead of "operating-system" it gets detected and parsed which is very peculiar. The official CycloneDX standard specifies any operating system or partial OS-Level components (like kernels) to be of the operating-system type. So there is something going on the 8000 re that is probably an implementation detail in grype . Any Insights why this is so ?

kzantow · 2025-05-13T14:57:47Z

@jurassicLizard -- it looks like you've opened a new issue, much appreciated! I'm going to close this one, as I think it is resolved -- please let me know if it should be reopened!

tgagneret-embedded added the bug Something isn't working label Aug 10, 2022

spiffcs added this to OSS Aug 24, 2022

spiffcs moved this to Parking Lot (Comments or Progress) in OSS Oct 6, 2022

spiffcs assigned tgerla Oct 6, 2022

wagoodman removed the status in OSS Feb 7, 2024

spiffcs added the needs-investigation label May 16, 2024

willmurphyscode added the needs-discussion label Sep 30, 2024

willmurphyscode assigned willmurphyscode and unassigned tgerla Oct 17, 2024

willmurphyscode moved this to Ready in OSS Oct 17, 2024

willmurphyscode changed the title ~~Issue with embedded components when scanning SBOM for vulnerabilities.~~ Publish once-off grype-db with hardware (:h:) and platform (:o:) CPEs included Dec 3, 2024

willmurphyscode removed the needs-discussion label Dec 3, 2024

willmurphyscode removed their assignment Dec 3, 2024

This was referenced Jan 14, 2025

false negative for cpe:2.3:o:linux:linux_kernel:6.6.16:*:*:*:*:*:*:* #2365

Open

Fails to find open kernel CVEs via CPE #1560

Closed

jurassicLizard mentioned this issue May 13, 2025

linux kernel ignored if type is set to operating-system in cyclonedx sbom #2656

Open

kzantow closed this as completed May 13, 2025

github-project-automation bot moved this from Ready to Done in OSS May 13, 2025

kzantow added the changelog-ignore Don't include this issue in the release changelog label May 13, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

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

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

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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

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

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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

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