源代码分析工具的关键及应避免的特征

一、源代码分析工具的关键特征

一个有用且成本效率好的源代码分析工具必须具备6种关键特征。

1．基于安全而设计。

软件安全可能是软件质量的一个子集，但是软件安全需要像坏人一样的思维能力。利用软件的弱点并不是常规QA中的一种练习。

在功能测试过程中揭示的软件缺点的处理方式可能仅仅解决了功能问题，但是安全缺点依然存在，并且通过某种出乎意料的执行路径时就会现问题，而在功能测试过程中根本不会考虑到这种执行路径。

不言而喻的是，软件安全风险倾向于比常规软件风险造成更巨大的商业影响。安全影响的代价是根据所造成商业数据损失、客户信任和品牌忠诚度损失、停工期和不能执行商业交易的损失，以及其他的无形损失来衡量的。

简单地说，对于健壮性而言，软件质量工具可能有些用处，但是软件安全工具中内置了更重要的安全知识。内置在工具内的知识库是一个基本的决定因素。

2．支持多层模型。

很少有现代软件应用程序是用一种编程语言编写，或者仅针对一个平台的。大多数企业关键应用程序都是高度分布式的，具有多层结构，每一层都用不同的编程语言编写，并且在不同的平台中执行。

自动化的安全分析软件必须支持所程序使用的每一种语言和平台，以及正确地在各层内和各层之间进行协商。只能分析仅仅一种或者两种语言的工具并不能满足现代软件的要求。

3．具有可扩展性。

与陆地上的物种一样，安全问题也不断进化、成长和成熟。没有任何一种技术或者规则集可以永远有效地检测所有的安全弱点。好的工具需要模块化体系结构，支持多种类型的分析技术。

这样，当开发出新的攻击和防御技术时，工具就能进行扩展以包含新的技术。类似地，用户也应该能够增加他们自己的安全规则。每一个机构都有自己的一套集团安全政策，因此，解决安全问题的一成不变的“通用”方法是注定要失败的。

4．对安全分析人员有用，也对开发人员有用。

安全分析是复杂和困难的。即使是最好的分析工具也不能自动地修改安全问题，就像调试器不能神奇地调试你的代码一样。最好的自动化工具使得分析人员可以将他们的注意力集中在最重要的问题上。

好的工具不但为分析人员提供支持，而且也为可怜的开发人员提供帮助，他们必须解决工具所揭示出来的问题。好的工具能够使用户尽可能有效率地找到并解决安全问题。如果使用正确，源代码分析工具是很好的教学工具。使用它们，（几乎是通过潜移默化）开发人员就能学到软件安全的许多知识。

5．支持现有的开发过程。

与建造过程和IDE的无缝集成是任何软件工具应该具备的基本特性。要使一种源代码分析工具被接受，成为应用程序开发团队的工具集的一部分，这个工具就必须与现有的用于不同平台的编译器适当地集成起来，并且支持make和ant之类的流行建造工具。

好的工具既应该集成到现有的建造过程中，也应该支持人们熟悉的开发工具，并与它们共存无碍。

6．对不同职位的人有意义。

软件都是为了某种理由而建造的——通常是某种商业理由。安全工具需要对商业有所帮助。对大多数机构来说，关注面向安全的开发都是一种新思维。

原注：当越来越多的普通质量工具不能用来查明安全问题时，老练的审核人员却可以用它们在代码模块的复杂、内聚、耦合和努力/数量关系中确定一些“迹象”——这是确定可能的安全弱点的很好的起点。在许多情形中，来自于脆弱的编码的安全错误在其他正确的代码中并不显眼。

它们经常是更大的、更普遍的疏忽所导致的结果，从更广义的角度，可以将它们看成一种质量错误。不要依赖质量衡量参数来确定安全问题，但是应该注意质量差的模块。缺点都倾向于结伴出现。

当然，软件安全并不是一种产品；而是一种正在进行的过程，这个过程需要整个机构的许多人的力量。但是好的自动化工具有助于将软件安全计划从所选择的几个部门扩展到整个开发公司中。

可以使用相关的衡量参数来比较发布经理、开发经理，甚至公司主管人员的看法，而且他们的观点能为软件发布决策提供支持，有助于控制修改软件的费用，以及提供对软件管理最需要的数据。

二、源代码分析工具应该避免的三种特征

源代码分析并不容易，而且早期的方法（包括ITS4）受到大量不利因素的困扰。一些这样的问题仍然存在于现在的源代码分析工具中。小心以下这些特征。

1．太多的假阳性。

早期的静态分析方法的一个常见问题是，它们的假阳性比例太高。实际工作人员似乎觉得提供的假阳性比例小于40%的工具就能用。有时ITS4产生的假阳性比例大于90%甚至更高，使得它很难使用。美化的grep机器就有极低的信噪比。包含数据流分析能力的现代方法极大地降低了假阳性，使得源代码分析更为有效。

2．在与IDE集成方面存在缺陷。

Emacs可能很棒，但是它并不适用于所有的人。开发人员已经有了他们喜欢的IDE，在进行安全分析时，不应该要求他们切换到其他的界面。在这方面已经进行了足够的讨论，不再赘述。

3．一根筋地只支持C语言。

典型的安全缺陷在C语言中很普遍。但是，现在的软件都是用多种语言来建造的，并且支持多种平台。如果你的系统不是仅仅用C语言建造的，当你审核代码时，应该确保没有忽略那些“非C语言”的代码。

【编辑推荐】

1. 开放源代码项目站点
2. deb 源代码包新格式
3. 源代码