no information in "title" field for vuls scan on ubuntu vm about vuls HOT 6 OPEN

ubuntu_api uses ubuntu cve tracker as a data source, and that data source does not include title information.
https://git.launchpad.net/ubuntu-cve-tracker/tree/active/CVE-2012-6655

from vuls.

Hi, you use cve tracker since you have switched to the gost DB, making it mandatory for ubuntu (this DB did not exist in previous vuls version and vulnerabilities datas was all there). Are you aware that not having titles for the CVEs anymore is an unacceptable regression? What do you propose to improve this point quickly?
Best regards

from vuls.

Previously, the OVAL used by Vuls had a title like this. Even in the case of gost (ubuntu-cve-tracker), do you want to fill in a title like this?

$ goval-dictionary select --by-package ubuntu 23.10 curl | grep "Title:"
    Title:        "CVE-2023-28321 on Ubuntu 23.10 (mantic) - low.",
    Title:        "CVE-2023-28322 on Ubuntu 23.10 (mantic) - low.",
    Title:        "CVE-2023-38039 on Ubuntu 23.10 (mantic) - medium.",
    Title:        "CVE-2023-38545 on Ubuntu 23.10 (mantic) - high.",
    Title:        "CVE-2023-38546 on Ubuntu 23.10 (mantic) - low.",

from vuls.

Previously, the OVAL used by Vuls had a title like this. Even in the case of gost (ubuntu-cve-tracker), do you want to fill in a title like this?

$ goval-dictionary select --by-package ubuntu 23.10 curl | grep "Title:"
    Title:        "CVE-2023-28321 on Ubuntu 23.10 (mantic) - low.",
    Title:        "CVE-2023-28322 on Ubuntu 23.10 (mantic) - low.",
    Title:        "CVE-2023-38039 on Ubuntu 23.10 (mantic) - medium.",
    Title:        "CVE-2023-38545 on Ubuntu 23.10 (mantic) - high.",
    Title:        "CVE-2023-38546 on Ubuntu 23.10 (mantic) - low.",

Hi. If the title field has no information, the field should not be present in the json report, so the client app can react accordingly (it chooses what to do when there is no title field, for example, display part of the the summary field as a title). Or vuls itself must have a pattern like you mentionned to fill the title field with available CVE datas.

We use trivy separately in combination with vuls; trivy gives ubuntu CVE specific titles, for example for CVE-2022-2345, title is:
CVE-2022-2345 (os-pkgs / ubuntu):use-after-free in skipwhite() in charset.c

As you can understand, since the vuls update (with gost DB), our interface displays empty CVE titles, and we cannot keep it as is.

Best regards.

from vuls.

CVE-2022-2345 (os-pkgs / ubuntu):use-after-free in skipwhite() in charset.c

Reference the trivy data source.
CVE-2022-2345 does not have a title for ubuntu data sources.

• ubuntu: https://github.com/aquasecurity/vuln-list/blob/04fbc8912182d1fb7313d3db316337286a360c7e/ubuntu/2022/CVE-2022-2345.json
• nvd: https://github.com/aquasecurity/vuln-list/blob/04fbc8912182d1fb7313d3db316337286a360c7e/nvd/2022/CVE-2022-2345.json

Probably, but it seems that redhat bugzilla has this title information.

• redhat: https://github.com/aquasecurity/vuln-list-redhat/blob/e235751d3cb68756b4c4dd873170b694df8b1417/api/2022/CVE-2022-2345.json#L33

First, Trivy combines information from multiple data sources and outputs information on detected CVEs. Therefore, there is no need to think of a title for each data source. However, Vuls maintains information for each data source.
For something like Vuls, which has a data structure that preserves each piece of data source information as much as possible, I don't think it's a good idea to arbitrarily supplement title information that isn't in the data source.

from vuls.

Hi,
ok, if you follow a requirement which is to preserve each piece of your data sources, i understand you don't want to code any aggregation ou transformation processes from these sources.
So the root issue is from datasources themselves. We cannot trust the title field from vuls report, so we will eliminate it from our vuls json report parsing. However we need a title for GUI display, the CVE description ('summary') is too much long, so we have to create our own CVE titles with custom rules.
Thanks.

from vuls.