Google在构建静态代码分析工具方面的经验教训 - FreeBuf专栏·李瑞的信息安全专栏
软件bug耗费开发者和软件公司大量的时间和金钱。 以2014年为例，被广泛使用的SSL协议实现中的一个（"goto fail"）bug导致可接受无效的SSL证书，另外一个与日期格式化相关的bug导致Twitter的大范围服务中断。此类错误通常可以被静态分析检测，其实事实上在阅读代码或文档阶段均可以快速识别，可以最终现实是情况仍然在生产环境实施发生。
之前的工作已经完善报道将bug检测工具应用于软件开发的经验。但虽然开发人员使用静态分析工具方面有如此多的成功案例，仍有以下原因导致工程师并不总情愿使用静态分析工具或主动忽略工具产生的告警信息：
-
未合理整合。工具未集成到开发人员的工作流程中或者是程序运行时间太长;
-
无效的告警。告警信息可行性性差;
-
不值得信赖。用户因为误报而不再信任结果;
-
缺陷实际利用场景不清晰。报告的bug在理论上是可行的，但缺陷在实际利用场景下并不清晰;
-
修复成本过高。修复已检测到的代码缺陷的成本太高或有其他方面的风险;
-
告警不易理解。使用者并不了解告警信息的的具体信息和原理。
接下来本文描述了我们如何吸取Google在先前使用FindBug进行java语言分析方面以及学术文献中的得到的经验和教训，最终在Google公司成功构建了软件工程师日常使用的静态分析基础设施架构。借助吸收于工程师的意见建议，Google的工具可以在有问题的代码被合入到公司级别的代码仓库之前检测到每天工程师所修复的数千个问题。
在工具作用范围方面，我们专注于将静态分析融入为Google核心开发流程的一部分，并服务于大部分Google开发人员。许多静态代码分析工具在部署于google的20亿行代码级别下将相形见绌，因此大规模场景下运行复杂分析的技术的优先级并不高。
当然必须要考量到Google外部开发人员在专业领域（例如航空航天和医学设备领域）工作的可能会使用特定的静态分析工具和工作流程。同样开发项目涉及特定类型（例如内核代码和设备驱动程序）的开发人员可能需要进行特定的分析方法。静态分析方面已经有很多卓越的工作成果，我们并不认为我们所反馈的经验和心得是独一无二的，但我们坚信整理和分享我们在提高google的代码质量和改善开发体验方面的工作是有所裨益的。
术语定义。我们使用以下术语定义：分析工具对源代码运行一个或多种"检查器"，并识别出可能呈现出软件故障的"缺陷"。如果开发人员在看到问题后没有采取积极行动，如果开发人员遇到识别出的缺陷并未采取适当的修复方式，我们将其视为"实际误报"。如果静态分析并未准确的识别报告到某项缺陷，但开发人员主动采取措施修改此处代码以提高可读性和可维护性，那么这就不算是有效的"误报"。如果一个分析报告了实际的代码错误，但是开发人员因未理解这处代码问题因而没有采取任何行动，就视为这是一个"实际误报"。我们使用这种概念区别强调了研发角度的重要性。开发人员而不是工具作者对感知并直接影响到工具的误报率。
Read full article from Google在构建静态代码分析工具方面的经验教训 - FreeBuf专栏·李瑞的信息安全专栏
No comments:
Post a Comment