源代码安全测试不再是新鲜话题，在很多的企业已经开展了相关工作，对于已经开展此项目工作的企业来说，我想问的问题则是“在你的源代码安全测试工作中所面临的最大阻力是什么?” 这个问题不同的企业可能有不同的答案，且各有各的道理。
其实，据我总结来看，很多的阻力表象最终都可以归结为“开发人员不配合”的问题。那为什么开发人员不配合源代码安全的相关工作呢?换句话说：如何让开发者爱上安全测试呢?
“源代码安全测试”——想说爱你不容易
对于开发者而言，源代码安全测试不是我们不想做，也不是我们不愿意配合工作，而是总有这样那样的问题，让我们实在爱不起来。原因归纳总结如下：
1. 测试的范围不清楚
对于安全，我们都知道一个道理，没有绝对的安全只有相对的安全。在很多企业中，源代码安全测试的范围和标准都是由安全部门一手“包办”的。确定哪些漏洞需要修复，哪些漏洞建议修复，哪些漏洞可以暂缓修复等范围和标准都是由安全部门人员说了算。这样一来，安全部门人员由于职责所在，同时加上现在的安全漏洞层出不穷，花样颇多的“压力”，安全范围和标准大都定的高一些，甚至一个项目一个标准，能改尽量要求改。而且由于“语言上的不通”(安全人员不懂开发，无法用编程的语言与开发者沟通)，这些范围和要求也很少与开发人员进行沟通。这样就导致开发人员总是感觉“安全人员老是挑刺，总是鸡蛋里挑骨头! 他们能查到什么就让我们改什么!”等等这样的感受。好像怎样做都无法满足安全上的要求。进而产生不愿意配合漏洞的测试和修复工作，甚至是 “对抗”的情绪。久而久之，源代码安全测试工作就很难再推动下去。
2. 测试的结果不准确
无论是安全性测试还是其他类型的测试，我想所有的测试人员都希望测试出来的问题即全面又准确。这也是我们所有从事测试工具研究人员的理想，而现实却总是有些“骨感”。面对目前市面上的所有源代码安全测试产品，没有任何一家可以说自己的产品即没有误报也没有漏报。由于在安全测试的概念中，漏报的后果比误报严重，所以大多数产品厂商会选择“宁可错报，不可漏报”的设计原则。这些原本作为辅助工具的测试产品在进入用户企业中后，却被不科学地当成了“裁判”，并且将其测试出来的原始结果在没有经过任何专业安全审计的情况下直接递交到开发人员手中。
即使有专人专岗的安全审计人员，他们在安全漏洞审计过程中由于缺乏有效的沟通方式，很少与开发人员进行技术沟通，审计出来的结果也会被当着“一面之词”。(这里我们且不讨论纯人工进行的源代码安全审计，因为到目前为止我也没有看到一家用户这么干，自己写点儿小工具或者脚本辅助人工审计的到是有一些，只是那些自己写的小工具或者脚本误漏报更是一堆。)开发人员在面对这些“漏洞信息”时，加之本身都不愿意相信自己的“作品”有问题的心理，便会对安全测试结果从相信到怀疑，再到完全的不信任，最后就会抱怨“全是误报!”，便再也没有配合修复漏洞的想法了。
3. 测试的时间不及时
做过软件开发的人都知道，即便是自己写的代码，如果隔上一两个月的时间，想再看明白为什么这么编写都比较困难。如果隔上一年半载，加之别人写的代码，那维护起来就难上加难了。这也是程序猿们所提倡的“敏捷开发”和“快速迭代”理念的原由。在源代码安全测试中，我们也应该提出“敏捷安全测试”的理念，要尽量在开发人员每一个小的迭代时，就要完成一个安全测试，修复起来也更加容易。
但现实中的源代码安全测试是什么样子呢?绝大多数的企业把源代码安全测试和安全渗透测试基本都放到了“验收测试”阶段中。项目只有在上线、发布或者交付之前才做一次安全测试。而这些开发周期少则半年多则几年的项目，到了验收阶段时，这些开发人员再对修改几个月几年前的代码，那是多么郁闷呀!另外，由于平时没有测试，漏洞量和代码一样会积少成多，这个阶段检测出来的漏洞往往会很多，很复杂。这怎么能让开发人员欣然接受、积极配合呢?恐怕只剩下“能推就推，能不承认就不承认”了吧!
4. 测试的成本太高昂
这个原因，我们可以接上一个原因往下讲。当聪明的开发人员发现项目最终总是会被动地被“安全验收测试”，那时再修复起来会手忙脚乱，不如功在平时，在开发过程中主动地、自主地先对源代码安全测试一下，将漏洞化整为零，及时测试，及时修复。这样的想法是非常好的，可以在实施的时候就会发现有这样那样的问题，要么由于安全测试工具License的限制，只能由专门的安全人员或者测试人员才能使用，而他们本身忙于对企业内众多项目的“安全验收”测试，没有时间和精力来为您“开小灶”。要么安全测试工具使用起来较麻烦，没有受过专业的产品使用培训还真不太能玩得转，且要准备这样那样的测试环境等等。要么就是安全测试工具很消耗系统的资源，不能实现较大的吞吐量，无法满足每一个项目在开发过程的多轮次的源代码安全测试。这就使得开发人员自主主动地源代码安全测试变得很难，甚至是不可能进行下去。
5. 修复的方法不明确
在生活中我们通常都明的一个道理：“己所不欲，忽施于人”，自己做不到的事情，也不能要求别人要做到。在源代码安全测试或者说安全编程这件事上，恰恰违背了这一点。在大多数的情况下，安全漏洞从发现到确认都是由安全人员来完成的，开发人员都是在为修复安全漏洞而努力。目前，开发人员缺乏安全漏洞的修复经验和相关的安全编程知识，这是普遍存在的现状，即使有十几年开发经验的“老司机”在一些安全漏洞面前，也都还是“小学生”。所以，开发人员势必要询问安全人员如何对这些漏洞进行修复，如何避免这些安全上的“坑”。
但是，这些安全人员虽可以对这些漏洞如数家珍，安全渗透玩得有模有样，可在代码开发和安全编码方面着实是个“门外汉”。站在有着十几年开发经验的老手面前，若只是根据测试工具给出的那些“标准答案”，可能也不好交差。最后会让开发人员感觉到很无奈，想配合进行安全修复都没有一个具体明确的方法，还要一点点地自行研究和尝试。还有一点，即便是开发人员经过一段时间的积累和总结，有了一些安全开发和修复的经验，也都因为没有一个经验共享和传承的平台，这些宝贵的经验只能散落在各个项目中，个别开发人员手上，没有形成统一的修复方法，是非常可惜的事情。最终因项目的不断交替，人员的频繁流动。新的开发人员不断地抱怨着，且不断地重复地走在研究各个漏洞修复方法的路上。
(注意: 以上原因皆为笔者自己在工作中归纳总结出来的，请勿对号入座!)
如何让开发者爱上“源代码安全测试”?
既然我们已经了解了开发人员不是很配合源代码安全测试这件事的原因，我们要想顺利地开展此项目工作就应该尽量避免这些问题。以我这些年为用户服务的经验，我总结了一些基本方法，或许可以帮助大家将这些问题一一克服，让开发人员能够接受源代码安全测试，甚至是爱上安全测试。基本方法如下：
1. 建立明确的安全测试范围和标准。明确地让开发人员知道要检测的内容和标准，当然这个安全测试标准，一定是要安全部门和开发部门一起进行讨论和协商而来的，让大家都能够明白这些漏洞的危害，造成的影响等。
2. 建立安全审计团队，总结安全漏洞审计指南。安全测试本身可以尽量地自动化实现，但测试工具测试出来的漏洞，仍然需要大量的人员安全审计才行。因此要培养相关人员，建立有效的安全审计团队，确保测试结果的相对准确性，来减少开发人的员的不必要的修复工作。同时，可以在工作中总结一些安全审计的方法，编写出审计指南，方便分享和传递。
3. 建立企业安全测试私云，形成敏捷源代码安全测试模式。企业在选择测试工具时，一定要尽可能地考虑一些有企业级测试私有云的测试解决方案，这样可以在企业内部建立一个统一的私有测试云平台，扩大使用范围，最好让开发人员在开发过程中实现迭代测试，当然，这还有一个前提就是把源代码安全测试做得一定要方便，简单，易操作，成本小。
4. 建立企业安全知识交流和分享平台，形成企业自有的安全编码库。这一个方面是开发人员最为关心，做好了也是最为喜欢的部分，就是可以在企业内部建立一个安全知识交流，学习，分享的平台。大家可以共同研究和学习漏洞知识以及修复方案。最终可以形式企业自有的安全编码没库。这是最理想的。
5. 定期组织软件安全知识培训和讲座，提高整体人员安全水平。我常常听到开发人员给安全测试人员说:”我们不怕测出安全漏洞多，只要告诉我们准确的修复方法，我们来改就行;你们最好给我们一个安全的编程方法，以后我们能就尽量避免漏洞”。”修复方法”、”安全编程”。就是软件安全开发知识中的基本内容了。所以，企业应该定期或者不定期地给相关技术人员，特别是开发人员进行安全知识培训，针对安全漏洞进行集中式安全编程培训，这样就可以从开发意识和开发习惯上杜绝安全漏洞。另一方面，技术人员能够在工作中不断地学习和成长，也是企业应尽的义务。
结语
“让开发者爱上安全测试”，这是一个统筹的理念，它包括诸多的意义。尤如前文所说的，在通常的安全测试过程中，问题表象好像是“开发人员的不配合和不支持”，但实质则是整体软件安全体系建设的不全面和不完整所导致的。只能通过疏通每一个环节上的问题，建立一个整体的软件安全开发管理体系才能让各个部门，各个角色的人员都能积极配合起来，才能“让大家爱上安全测试”。
【编辑推荐】
- 路由器安全测试工具Router Scan v2.53发布(含下载)
- IBM加密工具平台Identity Mixer近日向开发者开放
- Web安全测试中常见逻辑漏洞解析（实战篇）
- 如何“组合拳”渗透开发者的本地数据库
- 安全测试与漏洞管理领域各大发展趋势概述
原文地址：https://www.cnblogs.com/zgq123456/p/10035934.html