当下，软件软件开发安全的安全理念很火 ，各行各业都已认识到保障应用系统开发安全的应用重要性 ，但是实践要真正实现起来 ，结果却不是个误那么理想 。开发安全难深入 、软件难落地已成为常态 。安全
很多时候 ，应用尽管你工作很努力 ，实践但就是个误难以进步 ，主要原因并不是软件任务多困难 ，服务器租用而是安全有一些根深蒂固的错误观念一直在阻碍 、限制你。应用目前软件开发安全技术领域中 ，实践这样根深蒂固的个误错误观点还不少 ，需要大家共同努力，把这些观念找出来 ，纠正过来 ，开发安全的应用发展才会更加稳健。
在近8年时间里，笔者亲身参与了几十家企业组织的开发安全应用实践，其中也走了很多弯路 ，建站模板踩过很多深坑 。在本文中 ，简单总结了笔者在应用实践中发现的开发安全常见认知误区 ，希望能够帮助读者在未来开展开发安全实践时少走弯路 。
误区1.开发安全不就是应用上线前的安全性测试吗 ？开发安全工作的实现不仅仅依赖于上线前安全测试 ，正如质量界的一句名言，“质量是建设出来 ，不是管理出来的” ，源码库开发安全的质量同样如此 ，建设好的开发安全 ，应该在三方面下功夫，如下图 ：
不考虑“规矩”——管理体系的建立 ，不考虑“能力”的建设 ，只强调上线前的检测，不能从根本上解决问题 。
误区2.开发安全就是做好源代码审计源代码审计确实是开发安全中很重要的一环 ，高防服务器毕竟软件开发项目的本质交付物就是源代码 ，但开发安全涵盖的内容远远大于源代码审计。
开发安全区别于我们常规信息安全工作有两个关键点 ：
（1）开发安全是威胁驱动而不是评估驱动 。
传统信息安全通常都是评估驱动：安全团队去做一个风险评估 ，发现系统的脆弱性 ，然后有后续的安全整改、复测等等 。但开发安全是云计算在系统还没有建好，甚至还没有建开始的 ，它只能从系统建成后将面临什么风险开始 ，然后才有后续的安全工作，如降低攻击面 、安全编码、安全验证等 。
（2）开发安全中 ，安全是需求而非BUG
传统信息安全工作中 ，发现漏洞基本都是当bug流程来处理 ，bug处理一般是没有预算（包括资源预算和时间预算）的免费模板 ，这当然会造成开发团队和安全团队的对立 ，真实安全开发需要的资源并不少 ，只有当需求处理能保证合理的资源 ，才能保证开发安全活动的顺利进行 。
显然 ，开发安全中 ，安全需求分析的重要性就远远大于源代码审计 ，依赖源代码审计只是安全评估的一环 ，更何况当下的源代码审计工具还有种种不足 ，是不能单一方式来满足开发安全要求的。
误区3、应用SDL就可以实现开发安全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模型在国内实际软件开发工作中较少应用的原因。
在实践中 ，笔者一直倡议安全需求库法 ，就是按照经验 、合规要求 ，建立起基础的安全需求库 ，针对具体项目具体分析 ，建立具体安全需求 。采用这种方法 ，虽然理论上无法保证安全需求的完备性 ，但在可操作层面，实际应用成本会得到很大优化。
误区4.提出安全问题和解决问题都是安全团队的事这个误区的本质是软件开发安全的分工与合作问题 ，安全团队在开发过程中的能力在于安全知识丰富 ，但职权有限 ，对开发过程介入的环节少 ，因此无法解决所有存在的安全问题 。
如果使用一个不合理的分工原则 ，最终导致的结果就是难以落地的 。在当下通常的软件开发过程中 ，业务团队决定功能 ，开发团队决定代码 ，运维团队可以负责服务器，而安全团队的职责呢 ？
所以 ，在项目开发的权力链中 ，业务>开发>运维>安全 。综合考虑能力和权力，比较合理的分工建议如下 ：
如果一个机构将安全设计交给安全团队，这个机构的开发安全工作一定很难真正落地 ，因为安全团队是不可能做好安全设计的。因为设计本身就是要在功能与性能 、用户体验、安全等因素综合影响下的一个平衡考虑 ，必须由开发团队去进行综合的取舍 ，统一设计 。
为什么明明设计工作不适合安全团队 ，还会出现由安全团队来负责安全设计呢 ？在这里可能出现了一个假的“安全设计”，这个“安全设计”其实是一个安全需求 ，比如参照等保三级的“安全设计” ，就是提出满足等保三级要求的一些安全需求 。
可以简单对比一下两种安全设计 。
通过对比 ，大家能理解真正的安全设计是什么，它是设计在安全方面的体现 ，是针对一个设计的安全说明 。所以，安全团队是不适合负责安全设计的 ，最多可以协助安全设计 。那让安全团队做一个假的“安全设计”也不行吗 ？这个“安全设计”顶着安全设计的帽子 ，真实的安全设计就会缺失 ，安全设计的管控就更不可能了 。
误区6.开发安全应用太虚 ，没法实际落地软件开发安全是开发项目管理的一个部分 ，跟开发一样是无法完美的 ，所以开发的管理有CMMI ，成熟度模型 ，开发安全也有开发安全的成熟度模型 。实施开发安全管理会很大层面改变开发团队的安全动作和安全习惯 ，安全意识的提高也毋庸置疑 ，肯定会对项目成功发挥极大作用 。
但客观上 ，在开发安全动作中有形式主义的部分 ，就跟开发管理这么多年仍然是一边编码 、一边设计评审一样，没有做到100% ，既不能算虚，也不能算理想的落地 。
从最终效果来说 ，做了开发安全的项目也不能保证100%的安全 。安全的应用效果最终还是依靠投入来保证的 ，现在的开发安全都是追求有限投入下的最好结果 ，从来不追求100%的安全，所以也不能从这个结果来评估价值 。
如果一方面用一个极高的标准来要求开发过程中的安全工作 ，另一方面又不认可开发安全的投入价值 ，那么这种观点显然是不准确的 ，不利于应用安全的长期发展。
误区7.源代码审计的用处不大当前源代码审计工具确实存在一些不如人意地方 ，一方面审计报告给出的漏洞数量会很多 ，另一方面存在大量无法直接利用的漏洞被当做高危/严重漏洞报出，导致源代码审计产品的实用价值面临挑战 。此外 ，还有一些非常常见且重要的逻辑类漏洞 ，如 ：甲可以查乙的交易记录（横向越权/数据越权漏洞）等，通用源代码审计工具也难以发挥作用。
虽然存在不足，但并不能否认源代码审计的价值 。一方面源代码审计能够发现很多重要的代码缺陷；另一方面 ，源代码审计也能大幅加强开发团队的安全意识，具备重要价值。
同时 ，源代码工具的不足，可以随着时间的深入 ，团队熟悉 ，得到相当的控制 ，有些机构具备源代码审计工具的高级运营能力 ，通过不断调优规则 ，减少源代码审计工具的报告漏洞数量 ，建立黑白名单机制，减少必须整改的漏洞数量，大幅提升源代码审计工具的可用性。
总之 ，源代码审计工具有不足 ，但仍然是很重要的开发安全辅助工具。
误区8.做好开发安全必须依靠工具软件工程从来不是完全依靠工具发展的 ，现在CMMI软件成熟度即便是5级 ，里面对工具的依赖度也是有限的 ，开发安全更不能仅靠工具。“开发安全必须靠工具”这一说法来源于两个原因 ：一、不愿意在开发安全方面投入资源 ，在这种情况下只能靠工具了；二 、错误理解开发安全 ，还是把开发安全理解为漏洞管理 ，而人工检测漏洞成本太高 ，就只能靠工具了 。
误区9.IAST可以有效避免误报交互式应用安全测试（Interactive application security testing IAST）的核心技术是插桩（Instrumented） ，就是利用WEB中间件，接触到运行代码 ，可以对运行代码进行审计 ，也可以在运行代码中插入收集数据流的代码 ，实现对运行的数据流检测 。IAST可以持续地从内部监控你应用中的代码和数据流 ，发现应用中存在的漏洞。
显然IAST对比DAST获得信息更多 ，具备漏洞报告更加精准的可能性 。但一个检测工具有没有误报 ，取决于检测策略 ，如果应用的检测策略是宁缺勿滥 ，自然准确率高 ，但漏报率也高；如果检测策略是宁滥勿缺，自然漏报率低 ，但准确率自然也低。
早期IAST产品只需要检测较少漏洞 ，因此漏报率高 ，准确率很高；但现在国内IAST产品发展的方向是检测漏洞种类越来越多 、越来越复杂 ，很多漏洞种类不是IAST擅长的 ，导致现在IAST误报率也比较高，实用性反而变差 。
误区10.软件供应链安全就是SCA供应链安全是一个大课题 ，必须从国家、行业角度来彻底解决 ，一个机构能做的非常有限 。软件供应链复杂程度甚至超过硬件 ，各种开源软件的应用是导致软件供应链复杂的重要原因之一 。但目前很多厂商提到软件供应链安全就会推荐软件成分分析系统（SCA software composition analysis），让一些用户将软件供应链安全误解为SCA 。
SCA工具功能分成三个部分：
分析软件结构 ，判断包含哪些开源组件，形成一份软件结构清单 ，列出软件包含的所有开源组件。根据开源组件清单 ，根据CVE、CNVD 、CNNVD等各种漏洞库，判断开源组件包含的漏洞情况 。根据开源组件清单 ，根据其许可协议，判断开源组件的许可协议方面的风险 。显然SCA系统只解决软件供应链环节中一个环节问题，就是在上线前检测软件包含的开源软件组件 ，并根据组件信息分析漏洞和许可协议风险 。对比软件供应链的主要威胁 ：恶意篡改 、假冒伪劣 、供应中断 、信息泄露 、违规操作以及其他威胁等 ，能解决的问题实在有限 。