当下 ，软件软件开发安全的安全理念很火 ，各行各业都已认识到保障应用系统开发安全的应用重要性 ，但是实践要真正实现起来
，结果却不是个误那么理想
。开发安全难深入、软件难落地已成为常态。安全

很多时候，应用尽管你工作很努力
，实践但就是个误难以进步，主要原因并不是软件任务多困难，建站模板而是安全有一些根深蒂固的错误观念一直在阻碍
、限制你
 。应用目前软件开发安全技术领域中，实践这样根深蒂固的个误错误观点还不少，需要大家共同努力 ，把这些观念找出来，纠正过来，开发安全的应用发展才会更加稳健。

在近8年时间里 ，笔者亲身参与了几十家企业组织的开发安全应用实践，其中也走了很多弯路，香港云服务器踩过很多深坑。在本文中
，简单总结了笔者在应用实践中发现的开发安全常见认知误区，希望能够帮助读者在未来开展开发安全实践时少走弯路 。

开发安全工作的实现不仅仅依赖于上线前安全测试，正如质量界的一句名言
，“质量是建设出来，不是管理出来的”，模板下载开发安全的质量同样如此，建设好的开发安全，应该在三方面下功夫 ，如下图：

不考虑“规矩”——管理体系的建立 ，不考虑“能力”的建设，只强调上线前的检测，不能从根本上解决问题 。

源代码审计确实是开发安全中很重要的一环，源码库毕竟软件开发项目的本质交付物就是源代码，但开发安全涵盖的内容远远大于源代码审计。

开发安全区别于我们常规信息安全工作有两个关键点：

（1）开发安全是威胁驱动而不是评估驱动。

传统信息安全通常都是评估驱动：安全团队去做一个风险评估
 ，发现系统的脆弱性
，然后有后续的安全整改、复测等等。但开发安全是免费模板在系统还没有建好 ，甚至还没有建开始的，它只能从系统建成后将面临什么风险开始 ，然后才有后续的安全工作，如降低攻击面、安全编码、安全验证等 。

（2）开发安全中，安全是需求而非BUG

传统信息安全工作中，发现漏洞基本都是当bug流程来处理
 ，bug处理一般是没有预算（包括资源预算和时间预算）的亿华云，这当然会造成开发团队和安全团队的对立，真实安全开发需要的资源并不少，只有当需求处理能保证合理的资源，才能保证开发安全活动的顺利进行 。

显然，开发安全中，安全需求分析的重要性就远远大于源代码审计 ，依赖源代码审计只是安全评估的一环，更何况当下的源代码审计工具还有种种不足 ，是不能单一方式来满足开发安全要求的。

SDL是由微软公司提出的从安全角度规范、指导软件系统开发流程的管理模式 ，在国内开发安全应用领域有较大的影响力，甚至一些机构和企业会将SDL错误理解成开发安全  。但实际上，很多企业实际应用的安全开发管理流程并不是SDL，而是融合SDL、BSI（Building Security IN）、SAMM（Software Assurance Maturity Mode）、CLASP（Comprehensive, Lightweight Application Security Process）等在内的综合开发安全模式。在笔者的亲身实践中发现 ，SDL管理理念不太容易落地，按照微软SDL，先进行威胁建模 ，然后用STRIDE模型分析安全需求 。采用这种方式，尽管看起来不复杂 ，但实际执行时却有很多挑战 ，开发人员要找到所有的数据交互 ，才能进行完整的威胁建模
。而对于应用系统开发
 ，一些数据交互是完全想不到的 。比如java反序列化漏洞 ，发生威胁时的数据流是客户端浏览器发请求给WEB中间件，应用程序还没介入，对于应用开发来说，要怎么威胁建模，怎么STRIDE才能排除这个风险
？所以这种方式的成本高得离谱
，需要大量人员进行支撑。这也是SDL模型在国内实际软件开发工作中较少应用的原因。

在实践中
，笔者一直倡议安全需求库法 ，就是按照经验、合规要求，建立起基础的安全需求库，针对具体项目具体分析 ，建立具体安全需求 。采用这种方法，虽然理论上无法保证安全需求的完备性，但在可操作层面，实际应用成本会得到很大优化
。

这个误区的本质是软件开发安全的分工与合作问题，安全团队在开发过程中的能力在于安全知识丰富，但职权有限，对开发过程介入的环节少，因此无法解决所有存在的安全问题。

如果使用一个不合理的分工原则，最终导致的结果就是难以落地的。在当下通常的软件开发过程中，业务团队决定功能
，开发团队决定代码，运维团队可以负责服务器 ，而安全团队的职责呢？

所以
，在项目开发的权力链中，业务>开发>运维>安全。综合考虑能力和权力，比较合理的分工建议如下 ：

如果一个机构将安全设计交给安全团队，这个机构的开发安全工作一定很难真正落地 ，因为安全团队是不可能做好安全设计的 。因为设计本身就是要在功能与性能
、用户体验、安全等因素综合影响下的一个平衡考虑，必须由开发团队去进行综合的取舍，统一设计。

为什么明明设计工作不适合安全团队，还会出现由安全团队来负责安全设计呢？在这里可能出现了一个假的“安全设计”，这个“安全设计”其实是一个安全需求 ，比如参照等保三级的“安全设计”，就是提出满足等保三级要求的一些安全需求 
。

可以简单对比一下两种安全设计 。

通过对比
，大家能理解真正的安全设计是什么 ，它是设计在安全方面的体现 ，是针对一个设计的安全说明。所以，安全团队是不适合负责安全设计的，最多可以协助安全设计。那让安全团队做一个假的“安全设计”也不行吗
？这个“安全设计”顶着安全设计的帽子，真实的安全设计就会缺失，安全设计的管控就更不可能了 。

软件开发安全是开发项目管理的一个部分 ，跟开发一样是无法完美的
，所以开发的管理有CMMI，成熟度模型，开发安全也有开发安全的成熟度模型 。实施开发安全管理会很大层面改变开发团队的安全动作和安全习惯，安全意识的提高也毋庸置疑，肯定会对项目成功发挥极大作用。

但客观上，在开发安全动作中有形式主义的部分，就跟开发管理这么多年仍然是一边编码、一边设计评审一样，没有做到100%，既不能算虚，也不能算理想的落地。

从最终效果来说，做了开发安全的项目也不能保证100%的安全。安全的应用效果最终还是依靠投入来保证的，现在的开发安全都是追求有限投入下的最好结果 ，从来不追求100%的安全，所以也不能从这个结果来评估价值 。

如果一方面用一个极高的标准来要求开发过程中的安全工作，另一方面又不认可开发安全的投入价值，那么这种观点显然是不准确的，不利于应用安全的长期发展 。

当前源代码审计工具确实存在一些不如人意地方，一方面审计报告给出的漏洞数量会很多，另一方面存在大量无法直接利用的漏洞被当做高危/严重漏洞报出，导致源代码审计产品的实用价值面临挑战  。此外，还有一些非常常见且重要的逻辑类漏洞
，如
：甲可以查乙的交易记录（横向越权/数据越权漏洞）等，通用源代码审计工具也难以发挥作用。

虽然存在不足 ，但并不能否认源代码审计的价值 。一方面源代码审计能够发现很多重要的代码缺陷；另一方面，源代码审计也能大幅加强开发团队的安全意识，具备重要价值。

同时，源代码工具的不足，可以随着时间的深入，团队熟悉，得到相当的控制 ，有些机构具备源代码审计工具的高级运营能力，通过不断调优规则 ，减少源代码审计工具的报告漏洞数量 ，建立黑白名单机制，减少必须整改的漏洞数量
，大幅提升源代码审计工具的可用性
。

总之 ，源代码审计工具有不足
，但仍然是很重要的开发安全辅助工具 。

软件工程从来不是完全依靠工具发展的 ，现在CMMI软件成熟度即便是5级，里面对工具的依赖度也是有限的 ，开发安全更不能仅靠工具 。“开发安全必须靠工具”这一说法来源于两个原因 ：一、不愿意在开发安全方面投入资源，在这种情况下只能靠工具了；二、错误理解开发安全，还是把开发安全理解为漏洞管理
 ，而人工检测漏洞成本太高，就只能靠工具了。

交互式应用安全测试（Interactive application security testing IAST）的核心技术是插桩（Instrumented），就是利用WEB中间件，接触到运行代码
，可以对运行代码进行审计
，也可以在运行代码中插入收集数据流的代码 ，实现对运行的数据流检测。IAST可以持续地从内部监控你应用中的代码和数据流 ，发现应用中存在的漏洞 。

显然IAST对比DAST获得信息更多，具备漏洞报告更加精准的可能性。但一个检测工具有没有误报，取决于检测策略，如果应用的检测策略是宁缺勿滥，自然准确率高
，但漏报率也高；如果检测策略是宁滥勿缺，自然漏报率低
 ，但准确率自然也低 。

早期IAST产品只需要检测较少漏洞 ，因此漏报率高，准确率很高；但现在国内IAST产品发展的方向是检测漏洞种类越来越多 、越来越复杂，很多漏洞种类不是IAST擅长的 ，导致现在IAST误报率也比较高，实用性反而变差。

供应链安全是一个大课题 ，必须从国家、行业角度来彻底解决 ，一个机构能做的非常有限 。软件供应链复杂程度甚至超过硬件 ，各种开源软件的应用是导致软件供应链复杂的重要原因之一 。但目前很多厂商提到软件供应链安全就会推荐软件成分分析系统（SCA software composition analysis），让一些用户将软件供应链安全误解为SCA 。

SCA工具功能分成三个部分：

显然SCA系统只解决软件供应链环节中一个环节问题
，就是在上线前检测软件包含的开源软件组件，并根据组件信息分析漏洞和许可协议风险。对比软件供应链的主要威胁：恶意篡改 、假冒伪劣
、供应中断、信息泄露、违规操作以及其他威胁等 ，能解决的问题实在有限。