张源-开源软件供应链视角下的漏洞威胁评估
作者：互联网
复旦大学张源老师
两个方面：软件供应链与威胁评估
软件供应的例子
集成过程中，上游会传播到下游中，上游开发商发现软件漏洞，进行更新，下游需要很长时间才能完成补丁
下游可能也弄不清楚，哪些漏洞修了，那些没修。
公开的代码，可能也是很老之前的版本，第三方的研究人员也很难知道，继承到的漏洞是否已经修复？
1.当一个漏洞披露，需要知道当前的版本受不受影响？
2.如果是受影响的，进一步想知道有没有修这个漏洞(修漏洞的叫安全补丁)
我们的工作围绕这三个工作展开：
1. 受不受影响，需要回答三个问题：
(1) 影响哪些版本
（2）如果修复了，定位补丁在哪里
(3) 评估镜像是否部署了这个补丁
作者实际工作是倒序实现的-补丁存在检测
两个工作，针对两种情况开发两种工具
由于第一个比较复杂一些，对第一个进行讲解
下游厂商部署补丁时，可能会对补丁进行一定的修改
针对上述挑战，我们的工作并不是利用相似度评估存在或不存在，将补丁内核...（没听懂）
第二，采用语义级别的检测，从下述三个角度抽取语义，
第三，去掉无关的代码，计算相似度的比较。
对比现有的工作，
补丁前、补丁后以及目标，通过比较，检测目标是否打了补丁。
实现
工作量大在于需要标记很多数据
没打补丁但是我们说它打了补丁的原因
下游厂商是否积极在部署这些上游公布的补丁，2506个镜像进行评估，发现厂商的部署存在一定的延迟，
接下来回归第二个和第一个问题
开源软件的漏洞其实是很多的，但是对于漏洞的补丁在哪里，缺乏补丁的管理
如何搜索漏洞的补丁？
去代码仓库中找 (2)见下图黄线 (3)
这些补丁表现怎么样？
这三种方法可以在多少CV上返回，
由此，提出了新的方法。漏洞补丁与漏洞具有千丝万缕的联系。类似于搜索引擎。
如何实现系统的
提取补丁六个维度的信息
评估指标有两个
同keyword相比较，我们可以以更少的efforts找到更多的补丁
回归问题一，漏洞影响哪些版本？能不能去发现更多的影响版本，这些版本并没有被披露
问题为什么会存在？
POC Migration实现机制，如果这个漏洞在这个版本上受影响，他们的出发路径是比较相似的。拿参照版本POC一下，拿target版本...选最接近的Ttarget
提出，基于Tree来表示Trace的方法
标签：补丁,供应链,漏洞,张源,评估,版本,软件,下游,开源 来源： https://www.cnblogs.com/lxwen/p/15095053.html