张源-开源软件供应链视角下的漏洞威胁评估

复旦大学张源老师

两个方面：软件供应链与威胁评估

软件供应的例子

 

 集成过程中，上游会传播到下游中，上游开发商发现软件漏洞，进行更新，下游需要很长时间才能完成补丁

 

 下游可能也弄不清楚，哪些漏洞修了，那些没修。

 

 公开的代码，可能也是很老之前的版本，第三方的研究人员也很难知道，继承到的漏洞是否已经修复？

 

 1.当一个漏洞披露，需要知道当前的版本受不受影响？

  2.如果是受影响的，进一步想知道有没有修这个漏洞(修漏洞的叫安全补丁)

 

 

 

 我们的工作围绕这三个工作展开：

 1. 受不受影响，需要回答三个问题：

    (1) 影响哪些版本

  （2）如果修复了，定位补丁在哪里

    (3) 评估镜像是否部署了这个补丁

  作者实际工作是倒序实现的-补丁存在检测

 

 两个工作，针对两种情况开发两种工具

 

 由于第一个比较复杂一些，对第一个进行讲解

 

 下游厂商部署补丁时，可能会对补丁进行一定的修改

 

 针对上述挑战，我们的工作并不是利用相似度评估存在或不存在，将补丁内核...（没听懂）

第二，采用语义级别的检测，从下述三个角度抽取语义，

 

 第三，去掉无关的代码，计算相似度的比较。

 

 对比现有的工作，

 

补丁前、补丁后以及目标，通过比较，检测目标是否打了补丁。 

 

 实现

 

 工作量大在于需要标记很多数据

 

 

 

 没打补丁但是我们说它打了补丁的原因

 

 下游厂商是否积极在部署这些上游公布的补丁，2506个镜像进行评估，发现厂商的部署存在一定的延迟，

 

 

 

接下来回归第二个和第一个问题

 

 开源软件的漏洞其实是很多的，但是对于漏洞的补丁在哪里，缺乏补丁的管理

 

 如何搜索漏洞的补丁？

  去代码仓库中找   (2)见下图黄线  (3)

 

 这些补丁表现怎么样？

这三种方法可以在多少CV上返回，

 

 

 

 

 由此，提出了新的方法。漏洞补丁与漏洞具有千丝万缕的联系。类似于搜索引擎。

 

 

 

 

 如何实现系统的

 提取补丁六个维度的信息

 

 

 

 

 

 评估指标有两个

 

 

 

 同keyword相比较，我们可以以更少的efforts找到更多的补丁

 

 回归问题一，漏洞影响哪些版本？能不能去发现更多的影响版本，这些版本并没有被披露

 

 

 

 问题为什么会存在？

 

 

 

 

 

 POC Migration实现机制，如果这个漏洞在这个版本上受影响，他们的出发路径是比较相似的。拿参照版本POC一下，拿target版本...选最接近的Ttarget

 

 

 

 

 

 

 提出，基于Tree来表示Trace的方法