近期，Veracode 公司发布《2018年软件安全报告（第9版）》，主要内容如下：

一、概述

报告数据来自真实存在的应用程序，对2万多亿行代码进行了70万次扫描。扫描时间为期一年（2017年4月1日至2018年3月31日）。

遵循行业最佳实践

  • 首次扫描的 OWASP Top 10 合规通过率连续三年下降，将至22.5%。

  • 超过85%的应用程序中至少存在1个漏洞；超过13%的应用程序中至少存在1个严重的安全缺陷。

  • 今年的漏洞修复率提升了12个百分点，客户修复了至少70%的已发现漏洞。

  • 软件中仍然充斥着易受攻击的组件。约87.5%的 Java 应用程序、92%的 C++ 应用程序和85.7%的 .NET 应用程序中包含至少一个易受攻击的组件。

  • 应用程序中出现的最常见的漏洞基本和之前一致。SQL 注入缺陷仍然在近三分之一的应用程序中存在；跨站点脚本漏洞 (XSS) 仍然在近50%的应用程序中存在。

漏洞修复行为

  • 超过70%的缺陷自发现之日起1个月内仍未被修复，近55%的缺陷自发现之日起3个月内仍未被修复。

  • 四分之一的高危和严重缺陷在发现之日起290天内仍未被修复。

  • 相比每年扫描次数为7到12次的应用程序，每年仅扫描1到3次的应用程序中漏洞存在的持久性比前者长3.5倍。

  • DevSecOps 独角兽在修复漏洞的速度方面遥遥领先；最活跃的 DevSecOps 计划修复缺陷的速度比一般组织机构快11.5倍。

  • 基础设施行业、制造业和金融业在完全修复已发现缺陷方面最艰难。

二、软件安全整体状况

这份报告或许能很好地解释为何很多安全专业人员在想到应用程序安全 (AppSec) 时会感到焦虑：缺陷的数量如此之多，而易受攻击的 app 所占比例之高让人咂舌。

从漏洞分类来看，缺陷的流行程度和之前相比基本一致。去年，前10大普遍存在的缺陷类型基本并没有什么变化。也就是说在开发组织内提高关于严重漏洞（如加密缺陷、SQL 注入和跨站脚本漏洞）意识方面，组织机构并未取得突破。这可能是因为组织机构正在忙于将安全最佳实践嵌入安全开发生命周期 (SDLC) 中，而不管这些标准从何而来。

从客户的修复速度来看，首次发现漏洞后第一周，组织机构仅修复约15%的漏洞问题；发现后第一个月，修复率仅为不到30%；到第三个月，修复率不到50%，仅稍高于45%。

组织机构修复缺陷的平均速度反映的不仅是 AppSec 计划性能，也是衡量应用程序风险的标杆。从漏洞持久性角度分析来看，漏洞发现21天后，75%的缺陷仍然存在；121天后，50%的缺陷仍然存在；472天后，25%的缺陷仍然存在。

三、修复状况

可以确定的一点是，多数组织机构中存在的漏洞数量就足以让他们必须在安全性、实践性和速度方面做出衡量。组织机构马上要解决的漏洞实在太多了，因此要求对这些漏洞进行智能优先排序，率先关闭最具风险的漏洞。

报告提出了“缺陷的持久性间隔 (Flaw Persistence Intervals)”的概念，即25%、50%和75%的漏洞在既定的应用程序中会停留多久。

从漏洞的严重程度来看，严重程度越高，修复速度越快。修复25%的最严重漏洞需14天，修复50%的最严重漏洞需64天，而修复75%的最严重漏洞需206天。组织机构修复严重和高危漏洞的速度要比修复其它漏洞的速度快57%。

从地域分布角度来看，亚太地区修复首次发现漏洞的速度最快，仅需8天就修复25%的漏洞；美洲（主要是美国）修复速度为平均数（22天）；EMEA 地区最慢，为28天。

如下是从国别角度统计的修复情况。

如下是从行业角度统计的漏洞修复情况。

除了修复速度以外，开发人员修复漏洞的方式也值得一提。在所发现的漏洞中，51.9%的漏洞被修复，43.9%的漏洞未被修复，4.3%的漏洞得到缓解。至于开发人员为何选择缓解而非以更改代码的方式解决漏洞问题，从开发人员采取的缓解措施方式可见一斑。开发人员缓解漏洞问题的方式主要包括通过设计缓解 (2.8%)、潜在的误报情况 (1.1%)、评审后决定不采取措施 (0.1%)、通过 OS 环境缓解 (0.1%) 、通过网络环境缓解（< 0.1%）等。而且潜在的误报情况并非开发人员选择采取缓解措施的第一原因。

组织机构如何确定漏洞修复的优先级？报告中所述的漏洞持久性间隔实际上并未深入研究策略对修复时机的影响。一般而言，每家组织机构策略的不同都会导致客户修复行为的不同。从分析来看，很多策略显然将漏洞严重性考虑在内，一些策略可能考虑到漏洞的利用性，其它一些策略可能强调的是某些漏洞类别，也有一些策略会基于应用程序对业务的重要程度决定修复方案的发布方式。开发人员可能会根据所在组织机构的策略来安排修复漏洞的计划，客户可能会基于上述因素决定修复方案或者会基于组织机构或行业独有的因素做出决定。值得思考的一点是，组织机构需要开始思考影响修复方案的首要因素是什么。

四、常见的漏洞类型

和去年相比，最常见的漏洞类型基本一样。前四大漏洞类型出现在超过一半的所测应用程序中，也就是说，多数应用程序中存在信息泄露、加密问题、不良的代码质量以及 CRLF 注入问题。

最常见的20大漏洞类型包括：信息泄露、加密问题、代码质量、CRLF 注入、XSS、目录遍历、输入验证不充分、凭证管理、SQL 注入、封装问题、时间和状态 (time and state) 问题、命令或参数注入、API 滥用、不受信任的初始化问题、会话固定问题、潜在后门、竞争条件、代码注入、出错处理、不受信任的搜索路径问题。

不过在动态分析安全测试 (DAST) 中，常见的漏洞问题类型有所不同。

常见漏洞的在修复速度方面（持久性）分析结果如下。

五、DevSecOps 效应

DevSecOps 实践席卷全球。越来越多的企业意识到由 DevOps 实践激发的软件交付的速度常常会在数字化转型和业务竞争力方面起着决定性作用。CA Technologies 发布的一项研究报告指出，执行DevOps 和敏捷进程的组织机构的收益和利润增长要比同行高60%，而且业务增长（超过20%）的速度要比同行高2.4倍。

报告数据分析显示，采用 DevSecOps 持续性软件交付实践的用户要比一般组织机构修复漏洞的速度更快。

六、不同行业面临的应用程序风险

不同行业面临的最常见的漏洞类型如下：

不可否认，所测试的数量最多的应用程序来自金融行业。虽然金融组织机构享有“拥有最成熟的网络安全实践”的名声，但数据分析显示，该行业和其它行业一样都在力保行业应用程序安全第一的地位。从漏洞持久性分析来看，该行业的应用程序漏洞停留的时间要长于其它行业。政府和教育行业修复漏洞的速度在加快。医疗行业修复app 风险的速度要快于其它行业。

七、总结

安全专业人员、开发人员和业务主管能够获得的启发包括：

修复速度至关重要。组织机构修复代码漏洞的速度直接反映了应用程序的风险情况。修复的速度越快，软件风险越低。

全面考虑风险情况。企业应用程序中未修复漏洞的庞大数量不可能立刻解决，因此必须排好优先顺序。

DevSecOps 作用显著。数据显示，组织机构每年扫描的次数越多，漏洞修复方案推出得越快。DevSecOps 所带来的高频率的新变化使其修复漏洞的速度相比传统 dev 团队而言简直是光速。

企业仍然备受软件中的开源组件问题的困扰。企业不仅应该考虑库和框架中的漏洞问题，而且还应考虑组件是如何被使用的问题。如能改变某些组件的使用方式，使缺陷免于被利用，那么也就存在缓解此缺陷的方式。

本文由360代码卫士翻译自Veracode

声明：本文来自代码卫士，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。