原文作者：Nikolaos Alexopoulos, Manuel Brack, Jan Philipp Wagner, Tim Grube and Max Mühlhäuser
原文标题：How Long Do Vulnerabilities Live in the Code? A Large-Scale EmpiricalMeasurement Study on FOSS Vulnerability Lifetimes
原文链接：https://www.usenix.org/system/files/sec22summer_alexopoulos.pdf
笔记作者：nerd@SecQuan
文章小编：cherry@SecQuan

简介

该文为发表于USENIX 2022的How Long Do Vulnerabilities Live in the Code? A Large-Scale EmpiricalMeasurement Study on FOSS Vulnerability Lifetimes。目前，软件社区论坛已经针对项目中的某个漏洞能存在多长时间这一问题进行过大量讨论。但是由于确定漏洞被引入的准确时间比较繁琐与困难，因此尚未存在对该问题深入且大规模的调查研究。在本文中，作者主要针对FOSS项目（免费开源项目）进行研究，提供了一种自动化的方法来准确估计漏洞在代码中的生命周期。由于该方法依赖于观察，所以很难确定一个漏洞的确切引入时间，但可以通过启发式方法准确估计大量漏洞样本的平均寿命。

方法

一般情况下，漏洞的生命周期如下图所示，依次经历漏洞引入、漏洞发现、漏洞公开、补丁公开和完全修复等阶段。以往的方法是通过找到引入漏洞的commit和修复漏洞的commit来确定漏洞存活的时间。但是，作者认为探究漏洞存活时间，不需要精确定位引入该漏洞的commit，只需要相对准确的估计引入时间点即可。作者借鉴了VCCFinder的算法并加以改进，使其返回代码易受攻击的时间的近似值。该算法通过对可能引入漏洞的多个可能日期进行加权平均得到，并根据每个单独的commit被blame命令标记的频率分配不同的权重。这里对Git blame命令稍加解释，Git blame命令能够针对项目中的某行代码进行回溯，找到最后一次修改了该行的commit。在当前问题的应用场景下，可以将命令结合修复漏洞的commit中代码的改动情况，帮助研究者找到漏洞可能的引入位置。在本篇论文中，作者在使用blame命令时主要遵循下列四个条件：

• 忽略对测试、注释、空行和非C/C++代码（作者选取的都是C/C++项目）的更改
• blame所有被移除的行
• 如果插入了一段代码块（超过1行代码），并且代码块不是一个函数定义时，blame代码块前后的行
• 如果插入了一行代码，并且代码中包含“if”、“break”、"goto"、“sizeof”等关键字或者是一个函数调用时，blame代码前后的行

上述规则基本属于研究员在手动调查漏洞VCC时总结下的一些经验，虽然不一定是最优的，但在实际使用中能取得不错的效果。

实验

作者首先在已有的CVE与其VCC之间的1,171个真实映射数据集上验证了他们的方法。然后对包含11个大型FOSS项目中的5914个CVE的大型数据集进行漏洞生命周期测量。针对前者数据集的试验结果如下所示，其中作者设计的启发式算法的性能相似，且误差对称分布在低平均值周围，相对比较稳定。此外，Li&Paxson的方法在不同项目之间差异较大的情况下可迁移性较差，不如作者提出的启发式方法泛化性更好。此外，如下图所示，作者的方法还可以用于研究漏洞生命周期随时间变化的趋势。下图中显示了从2011年到2020年中Linux内核15个漏洞的生命周期，真实情况和算法拟合结果相差不大。最后，作者针对包含11个项目的大型数据集应用其算法预测漏洞生命周期，结果如下表所示。一般来说，漏洞在代码中存在很长时间（平均超过 1,900 天）。