代码安全审计的四大误区.pdfVIP

代码安全审计的四大误区 思客云 王宏 前言： 随着代码安全审计被越来越多的软件开发企业和开发人员所了 解和认识，采用代码安全审计的方式来避免软件中安全漏洞的产生也正 在各个企业中积极地开展。作为这个行业的老兵，在与很多企业的管理 人员和安全技术人员交流过程中，我发现大家或多或少对代码安全审计 和代码安全审计工具还有一些理解上的误区，造成了工作上的困扰。下 面，我将就四个方面的个人理解分享给大家。 误区一.代码安全审计就是漏洞挖掘 一提到代码安全审计，大家首先想到的就是可以从代码中找到各种 各样的安全漏洞。所以很多软件开发人员或者管理人员都想用代码安全 审计工具这种“神器”，一下子就能挖掘出很多新的、未知的“漏洞”。 不得不说这是一个误区。代码安全审计工具虽然它可以发现程序中潜在 的安全漏洞，但并不能算作是漏洞挖掘工具，特别是对于没有较强安全 知识和渗透攻击知识的开发人员来说，代码安全审计工具就是安全编码 的辅助工具。从字面上就可以理解到“代码审计”——英文 “Code Review”，它只是对代码安全性的复查、审查，查看程序是编写是否 符合相关要求和编程规范，是程序员的一种自查方式。代码安全审计工 具也只是用自动化的工具去代替了人工审查而已。而对于那些有较强安 全知识和丰富渗透攻击经验的“黑客”们来说，代码安全审计工具又能 看作是他们 “攻击”的辅助工具。这是因为他们常常可以利用代码安全 审计工具查找出来的“蛛丝马迹”来找到那些深藏在代码深处的“0-day” 或“获root 级权限”的安全漏洞。所以我们可以看到有很多渗透攻击的 大牛们，也纷纷编写一些小的、很实用的代码审计工具来查找漏洞的原 因。但我还是要说，代码安全审计工具对于开发人员来说，不能作为漏 洞挖掘工具来用，不然你就会陷入第二个重大误区。 误区二. 代码安全审计工具都会很高的误报率 我常常听到很多用户或者开发人员讨论说代码安全审计工具的误 报率很高，因为检测出来的漏洞大部分都不能被直接利用或者被渗透验 证。这是一个很大的误区，这个误区就是上文的第一个误区的延伸，当 用户把代码安全审计工具作为漏洞挖掘工具时就会产生。原因是代码安 全审计工具是以静态的方式在程序中查找所有可能存在的安全漏洞特 征，这些特征表面上就是我们不安全的编码方式，或者说是不安全的编 程习惯，这些方式是产生安全漏洞的必要条件，但不是绝对条件，不能 用渗透的方式来验证和证明。打个形象的比喻就是：“人人都知道吸烟 有害健康，吸烟会导致呼吸道疾病或者肺癌；但我们不能证明某人吸烟 后就一定会得肺癌。”所以我总结：代码安全审计的主要宗旨就是在编 码环节，以（自我）审计的方式去尽量减少和消除这些不安全的编码方 式和编码习惯，确保不会有安全漏洞的产生。这个宗旨就告诉开发人员 在编码的时候，把所有不好的、不安全的编码方式规避掉，尽量以正确 的方式，来编写出安全的程序。当代码安全审计工具辅助开发人员发现 了这些不好的编码方式时，我们不必要去纠结它是否能够被利用或者被 渗透验证。而是用最简单、最直接、成本最低的方式把它消除掉就OK 了。这也是SDLC 开发模式所倡导的“在软件开发每一个环节中来避免 安全漏洞的产生”的安全开发理念。当我们以帮助开发人员在代码中查 找和消除所有不好的、不安全的编码方式为目标的时候，代码安全审计 工具的所谓误报率就变得很小、很小了。 误区三. 代码安全审计应该由专业的人员来干 关于代码安全审计工作到底应该由谁来负责，我之前曾写过一篇 文章，《“让开发者爱上安全测试”系列3 之（软件安全测试谁负责？）》 大家可以参阅。同样，代码安全审计工作在我看来不能仅仅交给 “专业 的人员”来干，这是个误区。这个误区主要是存在于管理人员对软件安 全开发理念上的误区。代码安全审计是软件安全开发的其中一个环节， 代码安全审计如果想要有很好的效果，就一定要开发人员从开发意识上 和编码习惯上有所改变。如果只是把代码安全审计交由安全测试人员， 甚至是外包的安全测试团队来干的话，效果一定是不好的。而往往管理 人员会受到“专业的事由专业的人员干”思想的影响，把代码安全审计 工作只交给安全人员来做，甚至以服务的方式将和外包给安全服务团队 来做，这样做就真的只是“代码安全审计”了（代码安全审计＝代码安 全测试+代码安全开发）。就把安全编码“最专业”的开发人员给排除 在外了，把安全漏洞审计，与安全开发相对孤立起来了，效果怎么会好 得了呢？为此，我们思客云