调研背景

如今的软件行业已经清晰地认识到，在整个软件开发生命周期（SDLC）中，只有将开发与运维工作紧密结合起来，才能按时交付软件产品和服务，以满足日益增长的数字化业务规模，这也就是我们熟悉的DevOps概念。

同时，有研究表明，在软件开发阶段发现缺陷的成本是测试阶段的1/4，是运行阶段的1/10，而开发阶段发现出现缺陷的数量是测试阶段3倍，是运行阶段的10倍。

因此，毫无疑问，在软件研发的更早阶段去发现漏洞与缺陷是一件低成本高回报的事情。这也就是为什么，现在许多公司致力于将IT安全防护更早地融入SDLC中，像是谷歌、微软[1]这样的世界互联网巨头甚至早就采取行动，开始着手建设自己完整的软件安全分析生态系统。

正是基于这样的理念，软件研发者们在DevOps的基础上又提出了DevSecOps框架。

不难理解，DevSecOps意味着在软件研发开始阶段就考虑应用和基础架构的安全性。

既要维持时间短、频率高的开发周期，又要采取安全措施，这无疑是对开发人员的一种挑战。因此，能否选择合适的工具来实现某些安全防护的自动化是这场变革成功与否的关键所在。这就是越来越多的企业开始使用代码安全分析工具实现安全左移的原因。

然而，开发者真正面临的局面是，目前市面上的大多数安全工具并不能完全适应他们的需求，在实际使用过程中更是存在各式各样的问题影响开发者的研发效率，例如不正确的提示信息，不直观的错误报告等等。

在这样的背景下，我们在多家一线城市的互联网及传统软件公司展开关于软件研发工作与安全检测工作的调研，发放了1000张调查问卷，并提前告知我们的调研目的，以增强参与者的积极性[2]。

最终，我们共收到了213份有效的反馈，在进行精确的数据统计后，我们对于目前软件研发行业开展安全工作的现状有了较为深入的了解，并试图从多个维度分析安全工作如何影响软件的研发效率，探究其解决方法。

下面我们将按照调查问卷的顺序展示我们的调研结果，并逐一展开分析。

调研分析

问题1：您使用哪些代码管理仓库？（多选）

根据统计，目前超过90%的开发者使用分布式版本控制系统，瀑布开发周期的时代已经一去不复返。与集中式孤立架构相比，分布式迭代集成架构为应用开发带来更多灵活性，这也是分布式开发现在受到开发人员青睐的原因。

问题2：您开发的应用多久发布一次？

可以看出，近80%的软件每个月都会发布新版本，超过18%的应用每天发布多个版本。与传统的瀑布式开发相比，新时代下的敏捷开发方法极大提升了软件的研发速度。软件的迅速迭代不仅考验开发人员的生产效率，也对安全检测提出了不小的挑战。

对于不断产出的海量代码，代码分析工具需要在尽可能短的时间完成安全扫描、漏洞检查。目前的国际高标准检测工具平均检测速率为100万/小时，值得一提的是，由国内鸿渐科技团队自主研发的检测工具平均检测速率已达170万/小时，对于Java等主流语言的检测甚至可达200万/小时。高速的检测利于提升DevOps的工作效率。

问题3：您期待代码分析工具检测出哪一类型的问题？（多选）

由统计结果可以看出，在众多代码问题中，代码的安全性尤其被开发者们所重视。不仅如此，在软件研发团队中，安全问题也被赋予了极高的优先权，受到团队的极大关注。

更有研究表示，对于开发者而言，其公司和团队的制度很大程度上影响他们对于代码分析工具的使用。同样地，团队对于安全问题重视，也提高了开发者对于代码安全性的要求，有40%的开发者将安全问题排在首位考虑。这也就不难理解，为什么开发人员使用代码分析工具时，最看重其对安全问题的检测。

问题4：您的公司在哪一阶段进行代码分析？（多选）

经统计可得，几乎所有的开发人员都在编写新代码和生产阶段时被要求对应用进行代码分析。而在这过程中，安全扫描结果误报、漏报率高势必会损害开发人员的工作效率。

事实的确如此，在应用安全的报告当中，93%的安全测试人员认为低质量的检测结果降低了开发人员的工作效率。

评判检测质量的两个重要指标是缺陷的误报率与漏报率。由于全部缺陷的数量无法确定，大多数代码安全工具厂商更关注误报而忽视漏报[3]。2017年软件工程的一篇顶会论文论述了100个真实CVE缓冲区溢出漏洞，用5个国际著名的静态工具检测加在一起仅报出论文其中20个，漏报率达80%。

由此可见，漏报率高，漏报量大是许多安全工具亟待解决的问题。在这方面，一款国内的软件源代码静态分析工具“鸿渐-SAST”有着较为优异的表现，能够将漏报率维持在较低的水平，提高安全检测的质量。

问题5：您在使用代码分析工具时，什么最影响开发效率？

我们可以看到，对于所有软件开发过程的安全问题，都至少有81%的开发人员认为这降低了他们的生产效率。这反映了一个所有安全工具必须要面对的事实——开发人员并不愿意使用软件安全检测工具。

其中，近90%的开发人员认为研发过程与检测的脱节是限制其生产力的最大因素。之所以会有这一结果，是因为在软件研发过程中，开发人员想要进行安全测试往往需要停止代码编写，运行检测工具，还要耗费大量时间等检测结果。这无疑会阻碍开发人员生产。

下面我们拿国产安全工具鸿渐-SAST支持的一种工作方式，分析安全工具如何尝试解决这一问题：

在不改变组织现有开发、测试流程的前提下，鸿渐-SAST与源代码管理系统Git（也是问题1中提到的，目前最广泛使用的代码管理仓库）、缺陷管理系统Bugzilla、持续集成工具Jenkins无缝对接。

开发人员结束一天工作后，将代码提交至Git，鸿渐-SAST通过Jenkins拉取代码，进行持续集成和持续部署（CI/CD），再采用基于深度学习的算法挖掘代码中漏洞，自动进行安全分析，形成可视化报告反馈给开发人员。开发人员获取代码检测报告后，第二天即可对漏洞进行修补，而无需中断生产等待检测结果。

鸿渐-SAST通过自动获取源代码进行检测，让开发、测试、安全人员集中精力关注检测结果，减少检测过程中繁琐的重复配置和等待时间，提高开发团队整体工作效率，尽力降低开发与安全检测脱节的影响。

问题6：您在使用代码分析工具时遇到了哪些问题？（多选）

可以看到，开发人员进行代码分析时，面临最多的问题是安全工具默认开启的检查规则并不完全符合实际需求。显而易见，几乎所有安全工具研发时，都会力求满足尽可能多类型项目检测的需要，这使得安全工具的检测规则有时较为冗杂，甚至包括强制开发人员采用特定规则命名变量，或是检测注释中的拼写错误等等。

在实际使用的过程中，开发人员往往只需要选择其中的一小部分检测项即可。然而，真实的情况是：许多开发者其实也并不清楚应该开启哪些检测项。而胡乱选择检测规则的后果可能是几千行代码经安全检测后出现了几万个错误，这样的检测结果无疑阻碍了软件的研发效率。

事实上，为了提高检测的质量和效率，研发人员可能不希望检测项目的所有代码，而是希望能够直接对特定代码进行分析。仅有10%的开发人员表示，他们现在所使用的代码分析工具能够进行片段代码分析，并且他们正在使用这一功能。另外还有49%的开发者表明，尽管他们目前所使用的工具不能进行部分代码分析，但是他们极为看重这一功能。

并且，在对开发者进行分类之后，我们发现，专业的研究人员以及更加在意代码安全的开发者会更多地使用部分代码分析功能。然而目前市面上多数代码检测工具都需要完整的程序构建环境，很难进行部分代码检测。

对于需要片段代码检测的开发人员，可以使用鸿渐-SAST进行代码分析，这款工具可以在非编译通过，也就是片段代码环境下，应用代码补全技术对代码自动进行分析，无需搭建运行环境即可进行检测。

此外，开发人员也期待安全工具对于错误分析有更加详细的解释，能够集成进他们的Workflow当中，能够形成更加直观的错误报告以及提供自动修复漏洞的功能等等[4]。

总结

通过此次调研，我们了解了在实际SDLC中，开发人员进行安全检测的实际情况以及对于安全工具的态度。我们期待未来有更多对开发人员更加友好的安全工具问世，真正解决开发人员的痛点，能够在采取安全措施的前提下最大限度地缩短运维中断时间，同时也要在开发团队中建立起负责任的团队氛围，让以往各自为阵的团队加强合作。只有这样，广大企业才能够紧跟数字化业务创新的步伐，适应数字化市场的竞争中占有一席之地。

参考文献

[1] Esfahani H , Fietz J , Qi K , et al. CloudBuild: Microsoft’s distributed and caching build service[C]// the 38th International Conference. IEEE, 2016.
[2] Smith E , Loftin R , Murphy-Hill E , et al. Improving developer participation rates in surveys[C]// International Workshop on Cooperative & Human Aspects of Software Engineering. IEEE, 2013.
[3] Christakis M , Bird C . What Developers Want and Need from Program Analysis: An Empirical Study[C]// 2016 31st IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2016.
[4 ] Jaspan C , Chen I C , Sharma A . Understanding the value of program analysis tools[C]// Companion to the Acm Sigplan Conference on Object-oriented Programming. ACM, 2007.

来源：freebuf.com 2021-07-27 14:45:01 by: whirl0112