[PATCH] cve-update-nvd2-native: Update vector logic

[PATCH] cve-update-nvd2-native: Update vector logic

[Colin McAllister]

The database used by cve-check currently stores the access vector and
vector string for the oldest CVSS version for each CVE. This should be
reversed, where the newest possible CVSS version is included instead.

Signed-off-by: Colin McAllister <colinmca242@gmail.com>
---
 meta/classes/cve-check.bbclass                   |  2 +-
 meta/recipes-core/meta/cve-update-nvd2-native.bb | 12 ++++++------
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 0c92b87f52..c4cbcdf8e3 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -31,7 +31,7 @@
 CVE_PRODUCT ??= "${BPN}"
 CVE_VERSION ??= "${PV}"
 
-CVE_CHECK_DB_FILENAME ?= "nvdcve_2-2.db"
+CVE_CHECK_DB_FILENAME ?= "nvdcve_2-3.db"
 CVE_CHECK_DB_DIR ?= "${STAGING_DIR}/CVE_CHECK"
 CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/${CVE_CHECK_DB_FILENAME}"
 CVE_CHECK_DB_FILE_LOCK ?= "${CVE_CHECK_DB_FILE}.lock"
diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb b/meta/recipes-core/meta/cve-update-nvd2-native.bb
index a68a8bb89f..e111709b22 100644
--- a/meta/recipes-core/meta/cve-update-nvd2-native.bb
+++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb
@@ -355,21 +355,21 @@ def update_db(conn, elt):
         cvssv2 = 0.0
     cvssv3 = None
     try:
-        accessVector = accessVector or elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['attackVector']
-        vectorString = vectorString or elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['vectorString']
+        accessVector = elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['attackVector']
+        vectorString = elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['vectorString']
         cvssv3 = elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['baseScore']
     except KeyError:
         pass
     try:
-        accessVector = accessVector or elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['attackVector']
-        vectorString = vectorString or elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['vectorString']
+        accessVector = elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['attackVector']
+        vectorString = elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['vectorString']
         cvssv3 = cvssv3 or elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['baseScore']
     except KeyError:
         pass
     cvssv3 = cvssv3 or 0.0
     try:
-        accessVector = accessVector or elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['attackVector']
-        vectorString = vectorString or elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['vectorString']
+        accessVector = elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['attackVector']
+        vectorString = elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['vectorString']
         cvssv4 = elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['baseScore']
     except KeyError:
         cvssv4 = 0.0
-- 
2.34.1

Re: [OE-core] [PATCH] cve-update-nvd2-native: Update vector logic

[Mathieu Dubois-Briand]

On Wed, Nov 27, 2024 at 12:59:45PM +0000, Colin McAllister via lists.openembedded.org wrote:
> The database used by cve-check currently stores the access vector and
> vector string for the oldest CVSS version for each CVE. This should be
> reversed, where the newest possible CVSS version is included instead.
> 
> Signed-off-by: Colin McAllister <colinmca242@gmail.com>

Hi,

I believe this patch breaks some selftests:

2024-11-28 13:29:06,536 - oe-selftest - INFO - cve_check.CVECheck.test_image_json (subunit.RemotedTestCase)
2024-11-28 13:29:06,539 - oe-selftest - INFO -  ... FAIL

https://valkyrie.yoctoproject.org/#/builders/48/builds/463/steps/14/logs/stdio

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH] cve-update-nvd2-native: Update vector logic

[Richard Purdie]

On Thu, 2024-11-28 at 12:56 +0100, Mathieu Dubois-Briand via
lists.openembedded.org wrote:
> On Wed, Nov 27, 2024 at 12:59:45PM +0000, Colin McAllister via
> lists.openembedded.org wrote:
> > The database used by cve-check currently stores the access vector
> > and
> > vector string for the oldest CVSS version for each CVE. This should
> > be
> > reversed, where the newest possible CVSS version is included
> > instead.
> > 
> > Signed-off-by: Colin McAllister <colinmca242@gmail.com>
> 
> Hi,
> 
> I believe this patch breaks some selftests:
> 
> 2024-11-28 13:29:06,536 - oe-selftest - INFO -
> cve_check.CVECheck.test_image_json (subunit.RemotedTestCase)
> 2024-11-28 13:29:06,539 - oe-selftest - INFO -  ... FAIL
> 
> https://valkyrie.yoctoproject.org/#/builders/48/builds/463/steps/14/logs/stdio
> 

Is that not from the ongoing NVD issues meaning we can't actually
obtain a new updated database? :/

Cheers,

Richard

Re: [OE-core] [PATCH] cve-update-nvd2-native: Update vector logic

[Mathieu Dubois-Briand]

On Thu, Nov 28, 2024 at 11:58:41AM +0000, Richard Purdie via lists.openembedded.org wrote:
> On Thu, 2024-11-28 at 12:56 +0100, Mathieu Dubois-Briand via
> lists.openembedded.org wrote:
> > On Wed, Nov 27, 2024 at 12:59:45PM +0000, Colin McAllister via
> > lists.openembedded.org wrote:
> > > The database used by cve-check currently stores the access vector
> > > and
> > > vector string for the oldest CVSS version for each CVE. This should
> > > be
> > > reversed, where the newest possible CVSS version is included
> > > instead.
> > > 
> > > Signed-off-by: Colin McAllister <colinmca242@gmail.com>
> > 
> > Hi,
> > 
> > I believe this patch breaks some selftests:
> > 
> > 2024-11-28 13:29:06,536 - oe-selftest - INFO -
> > cve_check.CVECheck.test_image_json (subunit.RemotedTestCase)
> > 2024-11-28 13:29:06,539 - oe-selftest - INFO -� ... FAIL
> > 
> > https://valkyrie.yoctoproject.org/#/builders/48/builds/463/steps/14/logs/stdio
> > 
> 
> Is that not from the ongoing NVD issues meaning we can't actually
> obtain a new updated database? :/
> 
> Cheers,
> 
> Richard
> 
> 

It might be. I don't see any issue with the patch itself, so it might be
an external factor.

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH] cve-update-nvd2-native: Update vector logic

[Marta Rybczynska]

[-- Attachment #1: Type: text/plain, Size: 3773 bytes --]

On Wed, Nov 27, 2024 at 1:59 PM Colin McAllister via lists.openembedded.org
<colinmca242=gmail.com@lists.openembedded.org> wrote:

> The database used by cve-check currently stores the access vector and
> vector string for the oldest CVSS version for each CVE. This should be
> reversed, where the newest possible CVSS version is included instead.
>
> Signed-off-by: Colin McAllister <colinmca242@gmail.com>
> ---
>  meta/classes/cve-check.bbclass                   |  2 +-
>  meta/recipes-core/meta/cve-update-nvd2-native.bb | 12 ++++++------
>  2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/meta/classes/cve-check.bbclass
> b/meta/classes/cve-check.bbclass
> index 0c92b87f52..c4cbcdf8e3 100644
> --- a/meta/classes/cve-check.bbclass
> +++ b/meta/classes/cve-check.bbclass
> @@ -31,7 +31,7 @@
>  CVE_PRODUCT ??= "${BPN}"
>  CVE_VERSION ??= "${PV}"
>
> -CVE_CHECK_DB_FILENAME ?= "nvdcve_2-2.db"
> +CVE_CHECK_DB_FILENAME ?= "nvdcve_2-3.db"
>  CVE_CHECK_DB_DIR ?= "${STAGING_DIR}/CVE_CHECK"
>  CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/${CVE_CHECK_DB_FILENAME}"
>  CVE_CHECK_DB_FILE_LOCK ?= "${CVE_CHECK_DB_FILE}.lock"
> diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb
> b/meta/recipes-core/meta/cve-update-nvd2-native.bb
> index a68a8bb89f..e111709b22 100644
> --- a/meta/recipes-core/meta/cve-update-nvd2-native.bb
> +++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb
> @@ -355,21 +355,21 @@ def update_db(conn, elt):
>          cvssv2 = 0.0
>      cvssv3 = None
>      try:
> -        accessVector = accessVector or
> elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['attackVector']
> -        vectorString = vectorString or
> elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['vectorString']
> +        accessVector =
> elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['attackVector']
> +        vectorString =
> elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['vectorString']
>          cvssv3 =
> elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['baseScore']
>      except KeyError:
>          pass
>      try:
> -        accessVector = accessVector or
> elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['attackVector']
> -        vectorString = vectorString or
> elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['vectorString']
> +        accessVector =
> elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['attackVector']
> +        vectorString =
> elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['vectorString']
>          cvssv3 = cvssv3 or
> elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['baseScore']
>      except KeyError:
>          pass
>      cvssv3 = cvssv3 or 0.0
>      try:
> -        accessVector = accessVector or
> elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['attackVector']
> -        vectorString = vectorString or
> elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['vectorString']
> +        accessVector =
> elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['attackVector']
> +        vectorString =
> elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['vectorString']
>          cvssv4 =
> elt['cve']['metrics']['cvssMetricV40'][0]['cvssData']['baseScore']
>      except KeyError:
>          cvssv4 = 0.0
> --
>

When we're at this patch... I'm wondering if anyone is actually using the
vectorString from our database for
any processing? In other terms, is someone extracting parts of the vector
(like network vulnerabilities)?
Or we can just remove it and people who want it, will have a look in other
places?

test_image_json is not checking for the vector string, most likely time
outs when downloading the database.

Kind regards,
Marta

[-- Attachment #2: Type: text/html, Size: 5560 bytes --]

Re: [OE-core] [PATCH] cve-update-nvd2-native: Update vector logic

[Colin]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

Hi,


I would like to use the vector string to do some analysis
and prioritization of CVEs and have
found that the vector string is better than using the CVSS score. I would
argue that in
embedded contexts, the environment that a device is used in will result in
a different scoring
of the vector. The most easy example is a standalone device that does not
have any network
connections will likely prioritize physical over network attacks, which I
believe is opposite to
how the CVSS score is determined.

I would like for the vector string to be included in the outputs so it is
also cached. Post-build
tooling could use the NIST API to pull down the vector string, but I would
like to avoid hitting
the API for what I imagine are the same reasons caching is already done for
cve-check.

As others have noted in this thread, the NIST API has been rather
unreliable lately. I agree
that the fetch is likely what is failing the build, since I had to bump the
database filename to
refresh the contents with the correct vector string. I didn't
test_image_json locally, but I did
run builds that included fetching the nvd database and everything seemed to
have been
working.

Thanks,
Colin

[-- Attachment #2: Type: text/html, Size: 1771 bytes --]

Re: [OE-core] [PATCH] cve-update-nvd2-native: Update vector logic

[Marta Rybczynska]

[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]

On Fri, Nov 29, 2024 at 3:02 PM Colin <colinmca242@gmail.com> wrote:

> Hi,
>
>
> I would like to use the vector string to do some analysis
> and prioritization of CVEs and have
> found that the vector string is better than using the CVSS score. I would
> argue that in
> embedded contexts, the environment that a device is used in will result in
> a different scoring
> of the vector. The most easy example is a standalone device that does not
> have any network
> connections will likely prioritize physical over network attacks, which I
> believe is opposite to
> how the CVSS score is determined.
>
> I would like for the vector string to be included in the outputs so it is
> also cached. Post-build
> tooling could use the NIST API to pull down the vector string, but I would
> like to avoid hitting
> the API for what I imagine are the same reasons caching is already done
> for cve-check.
>
> As others have noted in this thread, the NIST API has been rather
> unreliable lately. I agree
> that the fetch is likely what is failing the build, since I had to bump
> the database filename to
> refresh the contents with the correct vector string. I didn't
> test_image_json locally, but I did
> run builds that included fetching the nvd database and everything seemed
> to have been
> working.
>
>
Hello,
I'm not totally convinced by the fact that having the vector will avoid you
getting the complete entry.
What is the database if what is needed for the analysis. CVSS scores are a
little an exception here.
If we want to change the database format, I think it might make sense to
add ALL the vector strings
and not only the last one. That makes way more sense for interpretation
purposes and allows you
compare entries that have multiple vectors.

That being said, NVD entries often have multiple vectors - one from the
vendor issuing the CVE,
one from the NVD and so on. They often differ quite a bit, and those days
there might be other
assignments too. For such an analysis I would rather use the raw CVE
database instead.

Please note that we keep NVD for now because of the CPEs. Product names in
the CVE database
are not always set correctly (also, the vector is not always set). For all
more complete analysis I
use CVE that is available as a simple repository at
https://github.com/CVEProject/cvelistV5

Kind regards,
Marta

[-- Attachment #2: Type: text/html, Size: 3402 bytes --]

Re: [OE-core] [PATCH] cve-update-nvd2-native: Update vector logic

[Colin]

[-- Attachment #1: Type: text/plain, Size: 3058 bytes --]

On Fri, Nov 29, 2024 at 9:05 AM Marta Rybczynska <rybczynska@gmail.com>
wrote:

> On Fri, Nov 29, 2024 at 3:02 PM Colin <colinmca242@gmail.com> wrote:
>
>> Hi,
>>
>>
>> I would like to use the vector string to do some analysis
>> and prioritization of CVEs and have
>> found that the vector string is better than using the CVSS score. I would
>> argue that in
>> embedded contexts, the environment that a device is used in will result
>> in a different scoring
>> of the vector. The most easy example is a standalone device that does not
>> have any network
>> connections will likely prioritize physical over network attacks, which I
>> believe is opposite to
>> how the CVSS score is determined.
>>
>> I would like for the vector string to be included in the outputs so it is
>> also cached. Post-build
>> tooling could use the NIST API to pull down the vector string, but I
>> would like to avoid hitting
>> the API for what I imagine are the same reasons caching is already done
>> for cve-check.
>>
>> As others have noted in this thread, the NIST API has been rather
>> unreliable lately. I agree
>> that the fetch is likely what is failing the build, since I had to bump
>> the database filename to
>> refresh the contents with the correct vector string. I didn't
>> test_image_json locally, but I did
>> run builds that included fetching the nvd database and everything seemed
>> to have been
>> working.
>>
>>
> Hello,
> I'm not totally convinced by the fact that having the vector will avoid
> you getting the complete entry.
> What is the database if what is needed for the analysis. CVSS scores are a
> little an exception here.
> If we want to change the database format, I think it might make sense to
> add ALL the vector strings
> and not only the last one. That makes way more sense for interpretation
> purposes and allows you
> compare entries that have multiple vectors.
>
> That being said, NVD entries often have multiple vectors - one from the
> vendor issuing the CVE,
> one from the NVD and so on. They often differ quite a bit, and those days
> there might be other
> assignments too. For such an analysis I would rather use the raw CVE
> database instead.
>
> Please note that we keep NVD for now because of the CPEs. Product names in
> the CVE database
> are not always set correctly (also, the vector is not always set). For all
> more complete analysis I
> use CVE that is available as a simple repository at
> https://github.com/CVEProject/cvelistV5
>
> Kind regards,
> Marta
>
>

I don't disagree. I figured including all CVSS vector strings
would probably be best, but I also
figured that would also lead to a breaking API change in the cve-check
output. I was
concerned that a breaking change may not be able to be backported to
Kirkstone and
Scarthgap, which is what I wanted. However, if a patch that adds all CVSS
version vector
strings would be accepted over this patch, I would be happy to make that
change instead.

Thank you,
Colin

[-- Attachment #2: Type: text/html, Size: 4422 bytes --]