其他分享
首页 > 其他分享> > Notes | A large-Scale Empirical Study of Security Patches

Notes | A large-Scale Empirical Study of Security Patches

作者:互联网

A large-Scale Empirical Study of Security Patches

此文为笔者简单的论文笔记,仅供浏览学习,请不要置以其余任何用途

Introduction

Data Resource

   Why NVD?

   (1) public, free, and easily accessible in XML format, allowing for reproducibility and follow-on studies
   (2) expansive, as the NVD aims to catalog all publicly disclosed vulnerabilities across numerous software packages
   (3) manually vetted and curated, which in theory provides more accurate data
   (4) detailed, containing extensive documentation of vulnerabilities (notably external references).

   About NVD: CVE process

    1. 发现漏洞,请求CVE ID(此时漏洞的相关信息尚未公开)
    2. 公开漏洞信息,CVE ID与其详细信息加入CVE list
    3. NVD进一步调查,增加相关信息:链接到外部应用,列举受影响的软件,CWE分类,CVSS评估严重性程度

   Why open-source projects?

Related work

Data collection methodology

另,贯穿以上全部过程的验证方法:抽取大约100个样本手工检查

1. Finding Public vulnerabilities

使用 2016/12/25 NVD XML dataset snapshot —— 80,741 CVE vulnerabilities 作为数据集。
在这里插入图片描述

数据收集方法:

  1. 从 NVD 中 有链接到 Git 提交链接的 CVE 中提取漏洞特征
  2. 爬取其他 references ,并获取页面的公布日期来评估公开披露日期
  3. 爬取 Git 提交链接 来识别并克隆Git的源代码库,并获取 security fixes(collected security fixes using the commit hashes in the links)
  4. 用 Git 仓库获取 non-security fixes

2. Identifying software repositories & security patches

Why Git URL?

怎么找到Git仓库及security patches?

4,080 commits across 682 unique Git repositories, tied to 3,094 CVEs in total

3. Identifying Non-Security Bug Fixes

需要对比security patches & non-security patches ⇒ 大规模实现 ⇒ 实现自动识别 non-security patches ⇒ 逻辑回归 使用Git提交信息实现n-grams模型,手动选取提交进行训练分类器,使用分类器随机选择每个存储库最多10个提交来收集bug fixes数据集。

4. Processing Commits

对于收集到的每个提交,提取该commit提交前后所受影响的文件的历史版本:

⇒ 需要过滤非源代码文件、删除注释

怎样过滤非源代码文件、删除注释?

为什么仅选用前30个文件扩展名而非更少或更多的文件扩展?

5. Estimating Vulnerability Public Disclosure Dates

NVD中的 CVE 发布日期为漏洞在数据库中发布的日期,而实际发布的日期可能更早 ⇒ 需要获取更准确的公开披露时间

怎样获取更准确的公开披露时间?分析CVE references:通常包含与漏洞有关的发布信息,可能包含公开日期

13,600 active external references in total,从94%的页面中均提取出公开日期(at least one date extracted from an external reference for 93% of CVEs, with multiple dates extracted for 73% of CVEs)

为什么仅确定20个网站而非更多或更少?

结果:8% 的漏洞没有提取到更早的发布时间,大多数集中在27天左右,最长的有几年的差异。

limitations

Data characterization

1. Vulnerability publication timeline

对于所收集CVE数据集的漏洞公开时间绘图如下:

在这里插入图片描述

2. Affected software products

对NVD中列出的受漏洞影响的产品进行统计,列举受影响最多的产品数量:

在这里插入图片描述

⇒ 还需要对存储库进行分析

3. Vulnerability severity

CVSS标准划分严重性:

在这里插入图片描述

0-3.9低严重性,4.0-7.9被标记为中等,8.0-10.0被认为是高度严重。所收集的跨越所有严重性分数的漏洞。

4. Vulnerability categories

CWE标准进行分类,结果如下:

在这里插入图片描述

5. Vulnerability distribution over repositories

所选择的CVE漏洞不均匀地分布在 682 个项目上 ⇒ 需考虑按存储库划分

在这里插入图片描述

6. Repository size

通过文件数量或文件中的行数描述存储库大小,包括原始存储库与清理后的存储库:

在这里插入图片描述

Analysis results

已收集:

1. Patch Development Life Cycle

Vulnerability Life Spans in Code Bases

漏洞代码库生存周期(the vulnerability’s code base life span):从漏洞第一次被发现到被修正的时间,反映了攻击者的机会窗口
⇒难以自动确定⇒通过确定受安全修复影响的源代码上次修改的时间来近似下限:

How long do vulnerabilities live in code bases?

方法:

结果:

Do more severe vulnerabilities have shorter lives?

方法:

将CVSS评分与生命周期联系起来,计算Spearman相关系数 ρ

结果:

Do different types of vulnerabilities have varying life spans?

方法:

总结了CWE分类中不同类型的cve的漏洞寿命

结果:

top 10 :
在这里插入图片描述
观察到:

结论:

不同漏洞类型的生命周期取决于:漏洞本身与受影响的软件类型

Security Fix Timeliness

方法:

在这里插入图片描述

How frequently are vulnerabilities unpatched when disclosed?

由公开披露日期与补丁日期之间时间间隔的CDF可得如下结论:

How frequently are vulnerabilities fixed by disclosure time?

由公开披露日期与补丁日期之间时间间隔的CDF可得如下结论:

Are vulnerability patches publicly visible long before disclosure?

由公开披露日期与补丁日期之间时间间隔的CDF可得如下结论:

Are higher severity vulnerabilities patched quicker?

方法:

将CVE按严重程度划分 (low, medium, and high)

结果:

Patch Reliability

方法:为同一个CVE识别多个提交,并对原因进行分类

How frequently are security patches broken (e.g., incomplete or regressive)?

方法:

结论:

How long do problematic patches remain unresolved?

在这里插入图片描述
结论:

2. Patch Characteristics

对比 security fixes &non-security fixes

Non-Source Code Changes

方法:

对比commit data及其清理源代码注释与非源代码文件后的版本

结论:

后续分析仅限修改源代码的提交。

Patch Complexity

How complex are security patches compared to other non-security bug fixes?

选用代码行(LOC)。

Are security patches smaller than non-security bug fixes?

方法:

绘制了所有安全和非安全补丁、每个存储库中安全修复的全部LOC的CDFs

在这里插入图片描述

结论:

Do security patches make fewer “logical” changes than non- security bug fixes?

方法:

在这里插入图片描述

结论:

Do security patches change code base sizes less than non- security bug fixes?

结论:

Commit Locality

考虑两个指标:受影响的文件数量、受影响的函数数量

Do security patches affect fewer source code files than non- security bug fixes?

方法:

描述补丁涉及的文件数量的CDFs

在这里插入图片描述

结论:

Do security patches affect fewer functions than non- security bug fixes?

方法:

在这里插入图片描述

结论:

总之,安全补丁在其更改中的本地化程度更高。

Discussion

Conclusion

标签:non,Scale,Patches,Notes,fixes,漏洞,提交,security,patches
来源: https://blog.csdn.net/weixin_43894553/article/details/112801034