Update for CNT3

[Kurt Seifried <kurt@seifried.org>]

So reading CNT3 in https://cve.mitre.org/cve/cna/CNA_Rules_v2.0.pdf:

Shared Codebase, Library, Protocol: Does the vulnerability affect a shared codebase, library, or protocol implementation issue? Note: consultation with the Root CNA is recommended when the vulnerability affects software covered by other CNAs 

* For Shared Codebase 

o Affects a single product, assign one CVE ID and continue to INC1. 

o Affects the same code in multiple products, assign a CVE ID to each affected codebase and continue to INC1. 

o Affects multiple products but with different code, assign a CVE ID to each product and continue to INC1 20 

o Not sure or undefined, assign a CVE ID to each product and continue to INC1. 

• For Libraries, Protocols, or Standards o If there is a way to use the library, protocol, or standard without being vulnerable, then assign a CVE ID to each affected codebase or product and continue to INC1. 

o If the using the library, protocol, or standard requires the product to be vulnerable, assign a single CVE ID and continue to INC1. 

o Not sure, assign a CVE ID to each affected codebase and continue to INC1.

So prior to this in the OpenSource world I've gone with a single CVE for embedded code, UNLESS the code has so significant diverged from the original that it's basically different code. This is pragmatic because a LOT of OpenSource software embeds stuff (copies of gzip, libxml, etc.). 

Recently I've changed my definition a bit, prompted by Jenkins plugins. In the case of Jenkins plugins they may embed something for which a CVE exists, but because of how the plugins work/are installed/etc, it's not like you can really take an upstream fix for something embedded in your Jenkins plugin and use it, you need to really wait for Jenkins to ship the updated plugin. 

Now I have an issue related to embedded code used in the Clojure ecosystem, with similar problems. This is becoming more and more common as build systems do the magic to embed things and make them work, at the software/library level, the binary level and even the container level.

I think we need to redefine CNT3 a bit to better support things like Go binaries, Maven build systems, containers and so on otherwise we'll have a super huge CVE explosion. 

For me it sort of boils down to fixing something independently == code base change enough to warrant a CVE but I realize even this isn't clear enough.

Happy weekend all!

--

Kurt Seifried
kurt@seifried.org