从代码静态分析度量安全性小析

业界对于代码安全性度量一直没有标准。Testbed没有该指标，testbed只有清晰性、可维护性、可测试性以及三者综合指标。

Sonarqube中的代码安全度量：

 原文：

根据结合上述以及相关资料对代码安全度量方法，我对通过静态分析结果度量代码安全性进行了简单设计如下：

1、NNV，Number of new vulnerabilities，每次提交后检测发现的漏洞数量

新提交漏洞数根据检测出的缺陷漏洞数据进行统计分析，该指标需要通过静态检测工具分析得到，该值越小越好。

2、CRF, Code risk factor,代码漏洞风险系数

各级别漏洞加权值:   致命/所有漏洞算术和*1+严重/所有漏洞算术和*0.8+一般/所有漏洞算术和*0.6+其它/所有漏洞算术和*0.2

通过该值在一定程度反映的代码中漏洞的风险大小。最大值为1，该值越小越好。

例如：总共50个漏洞，其中致命10  严重40，则计算代码风险系数为 10/50+40/50 *0.8=0.2+0.8*0.8=0.84

3、V/KLoc，千行代码平均漏洞数量/安全漏洞密度，  1000*各级别漏洞加权值/代码总行数

根据 上面公式计算出各级别加权值，通过每千行代码平均计算得到安全漏洞密度。例如，上面例子中，各级别漏洞加权值为

10+40*0.8=42，如果代码为2400行，则V/KLoc=42/2400 =0.0175   通过该指标可以评价开发人员、项目组人员的提交代码的质量。该值越小越好。

5、PPV，Percentage of public vulnerabilities，公开漏洞占比

即CWE top 25和OWASP top10漏洞占所有漏洞的比值。通过检测工具检测出的漏洞与CWE和OWASP中的安全漏洞的数量占比计算得到，该值越小越好。

6、SVLT，Security vulnerability lifetime安全漏洞生存周期

漏洞从检测确认后进入缺陷管理系统到被修复的时间，按照小时计算，一天24小时。该值越小越好。

银行可以通过规范限定一个范围，例如致命缺陷48小时修复、严重缺陷72小时修复等。对于超过该规范的数量进行统计，或者可以统计超过每类缺陷统计修复周期要求的漏洞进行统计，不超过，超过2倍、超过3倍以上

在上述指标中，选择4项，包括严重+致命漏洞数、V/KLoc安全漏洞密度、CRF风险系数和PPV公开漏洞占比，通过加权得到总的安全性评估值。其中严重+致命漏洞数权重最高，占7/10、其它三项各占1/10。

上述各指标范围定义如下：

评测项	低（系数）	中（系数）	高（系数）	权重
严重+致命漏洞数	0-2	3-6	>6	7/10
	0.1	0.6	1.0	7/10 * 权重
V/Kloc安全漏洞密度	<0.02	0.02-0.06	>0.06	1/10 * 权重*10
CRF风险系数	致命/所有漏洞算术和*1+严重/所有漏洞算术和*0.8+一般/所有漏洞算术和*0.6+其它/所有漏洞算术和*0.2			1/10 * CRF
PPV公开漏洞占比	CWE top 25或OWASP top10漏洞占所有漏洞的比值			1/10 * PPV

（完）