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

[jurassicLizard]

What happened:

expected to find vulnerabilities for given cpe : cpe:2.3:o:linux:linux_kernel:6.6.16:::::::* but none were found

What you expected to happen:

expected to receive a list of vulnerabilities that exceed a 1000 for the given cpe cpe:2.3:o:linux:linux_kernel:6.6.16:::::::*

https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Ao%3Alinux%3Alinux_kernel%3A6.6.16%3A*%3A*%3A*%3A*%3A*%3A*%3A*

How to reproduce it (as minimally and precisely as possible):

1. download used BOM :
   sbom-false-negatives.json
2. run grype sbom:sbom-false-negatives.json
3. receive no vulnerabilities

 ✔ Scanned for vulnerabilities     [0 vulnerability matches]  
   ├── by severity: 0 critical, 0 high, 0 medium, 0 low, 0 negligible
   └── by status:   0 fixed, 0 not-fixed, 0 ignored 
[0000]  WARN unable to determine linux distribution: unable to determine distro 
No vulnerabilities found

Please also include the grype command and any configuration used.
--> grype sbom:sbom-false-negatives.json
Anything else we need to know?:
I have run the software with hundreds of sboms in that particular format using cpes it always seemed to find vulnerabilities but in this case it didnot which i found peculiar given the quality of previous results

Environment:

• Output of grype version:

Application: grype
Version: 0.86.1
BuildDate: 2024-12-13T19:32:52Z
GitCommit: 5c4fee7
GitDescription: v0.86.1
Platform: linux/amd64
GoVersion: go1.23.4
Compiler: gc
Syft Version: v1.18.1
Supported DB Schema: 5

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

NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

Thank you for your support, bom was deliberately truncated from other irrelevant components and grype rerun on the truncated version

[jurassicLizard]

this appears related to : #1560

[willmurphyscode]

Hi @jurassicLizard, thanks for the issue!

Currently, Grype's database does not include type o or type h CPEs, only type a CPEs. There's a more detailed discussion at #872.

[jurassicLizard]

@willmurphyscode thank you for your answer . I have read through the discussion and will post my follow up question there to keep the discussion linear.

[willmurphyscode]

Adding needs-discussion so that we can discuss: Now that we have better compression and a more compressible schema, is it time to just include :h: and :o: CPEs in the database?

[joshbressers]

@willmurphyscode Do we know of any possible downsides other than a larger DB?

I can think of two easy ones

• We could see more false positive reports as I'm sure some of the CPEs are sort of broken
• We could also see false negative reports as there are a lot of kernel CVEs missing CPEs

[jurassicLizard]

@willmurphyscode how technically difficult it is to make :h: and : o : opt-in ? meaning have them in the database but need to be explicitly activated with a disclaimer information about possible extended false positives, it would help us in embedded use grype also in that setting and would not affect anyone else. maybe a separate repo that needs to be explicitly activated (opt-in) ? or just a command-line flag that allows em to be included with the default being o and h are masked ?

[wagoodman]

We touched on it briefly in the livestream on thursday, essentially with the new DB schema adding CPEs with H and O part values would be cheap and easy. I have a change inbound that updates the DB build command to add these in by default anchore/grype-db#544 .

[jurassicLizard]

well done thanks . In practical terms, this means we would need to build the db ourselves with the build command and cannot rely on the standard release. Or did I misunderstand ? Thank you