更新CNT3

所以阅读CNT3https://cve.mitre.org/cve/cna/CNA_Rules_v2.0.pdf:

共享代码库,库、协议:脆弱性影响共享代码库,库,或协议实现的问题?注意:与根CNA磋商时推荐脆弱性影响软件覆盖的其他区域

*共享代码库

o影响单一产品,分配一个CVE ID和继续INC1。

o影响相同的代码在多个产品,CVE ID分配给每个受影响的代码库和继续INC1。

o影响多个产品,但使用不同的代码,将CVE ID分配给每个产品,继续INC1 20

o不确定或未定义,CVE ID分配给每个产品,继续INC1。

•图书馆、协议或标准啊,如果有一种方法可以使用图书馆,协议,或标准不脆弱,然后CVE ID分配给每一个受影响的代码或产品和继续INC1。

o如果使用图书馆、协议或标准要求产品是脆弱的,分配一个CVE ID和继续INC1。

不确定啊,CVE ID分配给每个受影响的代码库和继续INC1。

所以在此之前我已经用一个开源世界CVE为嵌入式代码,代码,除非有重大偏离了原来的,它基本上是不同的代码。这是务实的,因为很多开源软件嵌入的东西(gzip的副本,libxml等等)。

最近我改变了我的定义,由于詹金斯插件。在詹金斯插件的情况下他们可能嵌入一些CVE的存在,而是因为插件的工作/安装/等,它不像你可以拿一个上游解决嵌在贵国詹金斯插件,使用它,你真的需要等待詹金斯船更新插件。

现在我有一个问题有关嵌入式代码中使用Clojure的生态系统,与类似的问题。这是越来越常见的构建系统一样神奇的嵌入,使他们的工作,在软件/库级别,二进制级别甚至容器。

我认为我们需要重新定义CNT3有点以更好地支持二进制文件,Maven构建系统、容器等,否则我们会有一个超级巨大的CVE爆炸。

对我来说它归结为独立解决一些= =代码改变足以引起CVE但是我意识到这不是足够清晰。

快乐的周末!

- - -

Kurt Seifried
kurt@seifried.org