“头痛医头，脚痛医脚”式的源码扫描工具何时休止

2018-04-13 15:56 10142只看楼主

近日某研发兄弟对我说，他们回溯CSEC源码问题想改进办法，最后开发了一个XXX源码扫描工具。。。我说怎么又开发工具，他说想基于KORA作定制，结果联系作者得不到任何支持，想基于coverity做定制，定制一条规则要一个月，并且仅仅定制规则又不能全搞定。。。。研发同事也是实属无奈

 

研发的同事对PCLINT、coverity和fortify等应该都无比熟悉，记得公司从2010前后开始大力推广敏捷开发的时候，这些源码检查工具一开始作为提升代码质量的工具，到现在的作为消除安全编码问题的有效手段，一直被使用。

 

针对C/C++，covertity功能最强，误报率最低，问题种类覆盖最广，一直是世界上技术领先的工具，包括符号执行、污点分析、数值分析等等先进技术，应用效果最好。但是任何一款通用的工具，都不能完全满足个体用户的需求，交付的源码最终还是会被安全审计部门发现问题。因此很多开发部门都自研工具，比如2011年开始U2000就比较火的EBCC、2017年比较火的kora，这也只是我个人知道的，相信应该还有很多不知名的以及还正在开发中的工具，以前每年的各种获奖改进建议和各种获取QCC圈都少不了这些工具的身影。

 

自研工具有什么特点？

1、功能简单

功能简单并不是坏事，坏就坏在做完一个1.0稍有成绩，就想要2.0版本推广搞大成绩。工具的初衷就是拿来弥补coverity“本地化”的不足的，定位就应该是一个改进建议那么大，拼命包装也掩饰不了功能单一的事实。

2、重复造轮子严重

我司研发聚焦的是业务，研发不懂代码分析技术非常正常，因此多数工具从专业角度看都非常粗浅，无非是词法语法分析、正则式匹配这些，然后再基于此定义匹配规则。所有工具语法分析部分的代码、报告生成等等大同小异的功能都不是重用，必定自己重新写一遍。

3、后续没人维护

通常这些工具都是个人开发，部门内没有专门设置项目组，如果作者工作重心有变动、岗位有变动工具就没人维护了。使用中遇到各式各样的BUG，比如扫描卡死，规则定义问题，提新需求等等，可能就没人理了。

4、误报率超高

由于技术落后，匹配规则几乎玩得都是人海战术，错杀一千不放过一个，导致效率低下

 

自研工具是因为coverity会漏报，那么它为什么会漏报？根据个人经验分析及汇总他人分析结果，从工具自身角度出发，原因无外乎就两点：

1、攻击模式已知，但是没匹配成功。

也就是说整数溢出、内存越界、死锁等等这些攻击模式工具都能够很好的识别，但是存在一个匹配度的问题。工具为了提升准确性，默认匹配度可能是80%，但是我们期望的可能是50%甚至更低，这就会导致人工认为是问题工具认为不是问题的现象。具体一点，比如某个漏洞分支需要整数n在(5,20)才会触发，工具在计算时认为它可能为(20,25)并不会触发问题，所以不报；再比如污点分析场景，某些CORBA、thrift、WEBAPI等服务接口并没有被识别为数据入口，也就没法设置污染源，从而不会报出数据传播路径上的问题。这些通过定制coverity规则很明显是无法解决的。

2、攻击模式未知

也就是说人已知的攻击模式，但是工具不知道。比如DOPRA平台的内存申请函数vos_memAlloc、vos_memFree函数，如果一个指针使用了vos_memAlloc申请后没有释放，人工自然知道它是内存泄露问题，但是vos_memAlloc不是标准的内存申请函数，工具不知道，也自然无法报出问题。

 

上面的具体例子提到的是整个华为研发的共性问题，仅仅对coverity规则进行定制并不能解决。但如果能对coverity厂商提定制需求，应该都能够轻松解决，其他没提到的问题也应该会有解决方案。华为作为coverity的超级大客户，我觉得需求是能够得到厂商的重视和满足的，他们也应该乐于我们反馈需求意见。所以希望2012安全能力中心和工具部能够收集各研发部门需求，与厂商提出定制需求，评估一下定制的成本与无穷尽的自研工具哪个成本低。

 

以上个人愚见，欢迎讨论