On Fri, Nov 29, 2024 at 9:05 AM Marta Rybczynska <[email protected]> wrote:
> On Fri, Nov 29, 2024 at 3:02 PM Colin <[email protected]> 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#208034): https://lists.openembedded.org/g/openembedded-core/message/208034 Mute This Topic: https://lists.openembedded.org/mt/109805499/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
