下面，我将就代码安全审计的四个常见误区，把我个人的理解分享给大家。

 

误区一、代码安全审计就是漏洞挖掘

 

一提到代码安全审计，大家首先想到的就是可以从代码中找到各种各样的安全漏洞。所以很多软件开发人员或者管理人员都想用代码安全审计工具这种“神器”，一下子就能挖掘出很多新的、未知的“漏洞”。不得不说这是第一个误区。

 

代码安全审计工具虽然可以发现程序中潜在的安全漏洞，但并不能算作是漏洞挖掘工具，特别是对于没有较强安全知识和渗透攻击知识的开发人员来说。

 

代码安全审计工具就是安全编码的辅助工具。从字面上理解“代码审计”(Code Review)，它只是对代码安全性的复查、审查，查看程序是编写是否符合相关要求和编程规范，是程序员的一种自查方式。所以代码安全审计工具也只是用自动化的工具去代替了人工审查而已。而对于那些有较强安全知识和丰富渗透攻击经验的“黑客”们来说，代码安全审计工具又能看作是他们“攻击”的辅助工具。这是因为他们常常可以利用代码安全审计工具查找出来的“蛛丝马迹”，来找到那些深藏在代码深处的“0day” 或“获 root 级权限”的安全漏洞。

 

所以这就是我们可以看到有很多渗透攻击的大牛们，也纷纷编写一些小的、很实用的代码审计工具来查找漏洞的原因。但我还是要说，代码安全审计工具对于开发人员来说，不能作为漏洞挖掘工具来用，不然你就会陷入第二个重大误区。

 

误区二、代码安全审计工具都会很高的误报率

 

我常常听到很多用户或者开发人员讨论说代码安全审计工具的误报率很高，因为检测出来的漏洞大部分都不能被直接利用或者被渗透验证。这是一个很大的误区，这个误区就是上文的第一个误区的延伸，即当用户把代码安全审计工具作为漏洞挖掘工具时就会产生。

 

代码安全审计工具是以静态的方式在程序中查找所有可能存在的安全漏洞特征，这些特征表面上就是我们不安全的编码方式，或者说是不安全的编程习惯。但是这些方式是产生安全漏洞的必要条件，而不是绝对条件，也不能用渗透的方式来验证和证明。

 

打个形象的比喻：人人都知道吸烟有害健康，吸烟会导致呼吸道疾病或者肺癌，但我们不能证明某人吸烟后就一定会得肺癌。所以在我看来，代码安全审计的主要宗旨就是在编码环节，以自我审计的方式去尽量减少和消除这些不安全的编码方式和编码习惯，确保不会有安全漏洞的产生。

 

这个宗旨就告诉开发人员在编码的时候，把所有不好的、不安全的编码方式规避掉，并尽量以正确的方式，来编写出安全的程序。当代码安全审计工具辅助开发人员发现了这些不好的编码方式时，我们不必要去纠结它是否能够被利用或者被渗透验证。而是用最简单、最直接、成本最低的方式把它消除掉就 OK 了。这也是 SDLC 开发模式所倡导的“在软件开发每一个环节中来避免 安全漏洞的产生”的安全开发理念。当我们以帮助开发人员在代码中查 找和消除所有不好的、不安全的编码方式为目标的时候，代码安全审计 工具的所谓误报率就变得很小、很小了。

 

误区三、代码安全审计应该由专业的人员来干

 

关于代码安全审计工作到底应该由谁来负责，我之前曾写过一篇文章《“让开发者爱上安全测试”系列 3 之软件安全测试谁负责》 大家可以参阅。

 

代码安全审计工作在我看来不能仅仅交给“专业 的人员”来干，这也是一个误区。这个误区主要是存在于管理人员对软件安全开发理念上的误区。

 

代码安全审计是软件安全开发其中的一个环节， 代码安全审计如果想要有很好的效果，就一定要开发人员从开发意识上和编码习惯上有所改变。如果只是把代码安全审计交由安全测试人员，甚至是外包的安全测试团队来干的话，效果一定是不好的。

 

管理人员往往会受到“专业的事由专业的人员干”思想的影响，把代码安全审计 工作只交给安全人员来做，甚至以服务的方式外包给安全服务团队，这样就真的只是代码安全审计了。代码安全审计=代码安全测试+代码安全开发，把安全编码“最专业”的开发人员给排除在外，把安全漏洞审计和安全开发孤立起来了，这样做的效果怎么会好?

 

为此，思客云以找八哥产品为基础，提出了“让开发人员爱上安全测试”的测试理念，就是希望在这一点上能给让广大的用户避免这些理念上的问题。能够在企业内自建一个完整的安全开发(审计)团队，并给予全面的安全知识培训，使得安全漏洞审计和安全开发能够有效地结合起来，成为一个高效、相通的整体，让代码安全审计真正流利起来。