目前，软件开发安全的概念十分流行，各行各业都已经认识到保证应用系统开发安全的重要性。 然而，到了实际执行的时候，结果却并不那么理想。 安全纵深发展难、落地难已成为常态。
很多时候，尽管你很努力，但就是无法取得进步。 主要原因不是任务艰巨，而是有一些根深蒂固的错误观念一直在阻碍、限制你。 目前，软件开发安全技术领域还存在很多这样的根深蒂固的误解。 我们需要共同努力找出这些概念并加以纠正，这样安全应用的开发才会更加稳健。
八年来，笔者亲自参与了数十家企业组织的开发和安全应用实践，也走过了很多弯路，走过了很多深坑。 本文简单总结了作者在应用实践中发现的关于开发安全的常见认知误区，希望能够帮助读者在今后进行开发安全实践时少走弯路。
误区一、开发安全不就是应用上线前的安全测试吗？
开发安全工作的实现不仅仅依靠上线前的安全测试。 正如质量界的一句名言所说，“质量是建立起来的，而不是管理的”。 发展质量保障也是如此。 良好的发展保障要在三个方面下功夫，如下所示：
忽视“规则”——管理体系的建立，不考虑“能力”的建设，只强调上线前的测试，无法从根本上解决问题。
误区二、开发安全就是做好源代码审计
源代码审计确实是开发安全非常重要的一部分。 毕竟，软件开发项目的基本可交付成果是源代码，但开发安全涵盖的内容远不止源代码审核。
开发安全与我们常规的信息安全工作的区别有两个关键点：
(1)发展安全是威胁驱动而非评估驱动。
传统的信息安全通常是评估驱动的：安全团队进行风险评估，发现系统漏洞，然后进行后续的安全整改、重新测试等。而安全开发是在系统构建之前，甚至构建之前就开始的。 只能从系统建成后会面临哪些风险开始，然后还有后续的安全工作，比如减少攻击面、安全编码、安全验证等。
（2）在安全开发中，安全是需求而不是bug。
传统的信息安全工作中，当发现漏洞时，基本上都是通过Bug流程进行处理。 Bug处理一般没有预算（包括资源预算和时间预算）。 这当然会引起开发团队和安全团队之间的对抗。 真正的安全开发需要的资源并不多。 只有能够保证合理的资源用于需求处理，才能保证开发安全活动的顺利进行。
显然，在开发安全中，安全需求分析远比源代码审计重要。 依赖源代码审计只是安全评估的一部分。 而且，目前的源代码审计工具存在各种缺陷，无法通过单一方法来满足。 发展安全要求。
误区三：应用SDL可以实现开发安全
SDL是微软提出的一种管理模型，旨在从安全角度规范和指导软件系统开发过程。 在国内开发安全应用领域具有较大影响力。 一些机构和企业甚至将SDL误认为是发展保障。 但事实上，很多企业实际使用的安全开发管理流程并不是SDL，而是SDL、BSI（Building Security IN）、SAMM（软件保障成熟度模式）、CLASP（综合、轻量级应用安全流程）等的组合. 全面开发安全模型。 在笔者的个人实践中，我发现SDL管理理念实施起来并不容易。 根据微软SDL的说法软件安全实现，首先进行威胁建模，然后使用STRIDE模型来分析安全需求。 虽然这种做法看似并不复杂，但实际实施起来却面临不少挑战。 开发人员必须找到所有数据交互才能进行完整的威胁建模。 对于应用系统开发来说，有些数据交互是完全意想不到的。 例如，当Java反序列化漏洞发生时，威胁发生时的数据流是客户端浏览器向WEB中间件发送请求，应用程序尚未干预。 对于应用程序开发，如何对威胁进行建模，STRIDE如何消除这种风险？ 因此，这种方法的成本极高，需要大量的人员支持。 这也是国内实际软件开发工作中很少使用SDL模型的原因。
在实践中，笔者一直提倡安全需求库方法，即根据经验和合规需求建立基础安全需求库，分析具体项目，建立具体的安全需求。 采用这种方法，虽然理论上无法保证安全需求的完整性，但在操作层面，实际应用成本将会得到极大优化。
误区 4：提出安全问题并解决它们是安全团队的责任
这种误解的本质是软件开发安全的分工与合作。 安全团队在开发过程中的能力在于其丰富的安全知识，但其权限有限，对开发过程的参与较少，因此无法解决所有存在的安全问题。
如果采用不合理的分工原则，最终的结果将难以落实。 目前正常的软件开发流程中，业务团队确定功能，开发团队确定代码，运维团队可以负责服务器。 但安全团队的职责是什么？
因此，在项目开发的动力链上，业务>开发>运维>安全。 考虑到能力和权力，建议更合理的分工如下：
误区五、开发团队负责架构设计，安全团队负责安全设计。
如果一个组织把安全设计交给安全团队，那么该组织就很难真正落实开发安全工作，因为安全团队不可能做好安全设计。 因为设计本身就是功能与性能、用户体验、安全等因素综合影响下的平衡考虑，所以开发团队必须进行综合权衡，统一设计。
明明设计工作不适合安全团队，为什么还要由安全团队负责安全设计呢？ 这里可能存在假的“安全设计”。 这种“安全设计”实际上是一种安全要求。 例如，参考三级防护的“安全设计”，提出了一些满足三级防护要求的安全要求。
您可以简要比较这两种安全设计。
通过比较，大家就能明白什么是真正的安全设计。 它是安全性在设计中的体现，是对设计的安全性描述。 因此，安全团队不适合负责安全设计。 充其量，它可以协助安全设计。 那要求安全团队做一个假的“安全设计”不就可以了吗？ 如果把这种“安全设计”贴上安全设计的标签，那么真正的安全设计就缺失了，安全设计的控制就更无从谈起。
误区六、开发安全应用太徒劳，无法在实践中落地
软件开发安全是开发项目管理的一部分。 就像发展一样，它不可能是完美的。 因此，开发管理包括CMMI和成熟度模型。 开发安全也有一个开发安全成熟度模型。 实施开发安全管理将极大改变开发团队的安全行为和安全习惯。 毫无疑问，安全意识的提高将对项目的成功起到很大的作用。
但客观地说，制定安全行动有一个形式主义的部分，就像开发管理多年来一直在编码和设计审查一样。 如果没有100%达到，既不能说是空的，也不能说是理想的。
从最终的效果来看，即使你开发了一个安全的项目，也不能保证100%的安全。 安全应用效果最终是靠投资来保证的。 如今的安全发展追求以有限的投入得到最好的结果，从来不追求100%的安全，因此无法根据这个结果来评估其价值。
如果一方面用很高的标准来要求开发过程中的安全工作，但另一方面又不认可开发安全投入的价值，那么这种观点显然是不准确的，也不利于安全的发展。应用安全的长远发展。
误区七：源代码审计没什么用
当前的源代码审计工具确实存在一些不尽如人意的地方。 一方面，审计报告中上报的漏洞数量会很大，另一方面，存在大量无法直接利用的漏洞，被上报为高危/严重漏洞，导致源代码审计产品的实用性。 价值受到挑战。 另外，还有一些非常常见且重要的逻辑漏洞，例如：A可以检查B的交易记录（横向未授权访问/数据未授权访问漏洞）等，一般的源代码审计工具也很难发挥其作用。
尽管存在缺陷，但源代码审计的价值不可否认。 一方面，源代码审计可以发现许多重要的代码缺陷； 另一方面，源代码审计也可以大大增强开发团队的安全意识，具有很大的价值。
同时，随着团队对源代码工具的熟悉，源代码工具的缺陷可以随着时间的推移而得到控制。 一些组织拥有源代码审计工具的高级操作能力，可以通过不断调整规则来减少源代码审计工具报告的漏洞数量。 、建立黑白名单机制，减少必须修复的漏洞数量，大幅提高源代码审计工具的可用性。
简而言之，源代码审计工具有缺点，但它们仍然是重要的开发安全辅助工具。
误区八、开发安全必须依赖工具
软件工程从来都不是完全依赖工具来进行开发的。 即使CMMI软件成熟度等级为5级，对工具的依赖也是有限的，开发安全不能仅仅依赖于工具。 “开发安全必须依赖工具”的说法有两个原因：一是不愿意在开发安全上投入资源，只能依赖工具；二是不愿意在开发安全上投入资源，只能依靠工具。 第二，误解开发安全，或者误解开发安全对于漏洞管理来说，手动检测漏洞的成本太高，所以只能依靠工具。
误区9.IAST可以有效避免误报
交互式应用安全测试（IAST）的核心技术是插桩，利用WEB中间件访问运行代码、审计运行代码、向运行代码插入采集数据流。 实现运行数据流检测的代码。 IAST 可以从内部持续监控应用程序中的代码和数据流，并发现应用程序中的漏洞。
显然，IAST比DAST获得更多的信息，并且有可能报告更准确的漏洞。 然而，检测工具是否存在误报取决于检测策略。 如果所采用的检测策略宁少不宜多，准确率自然会高软件安全实现，但漏报率也会高。 准确率自然就低了。
早期，IAST产品只需要检测较少的漏洞，因此误报率很高，准确率很高； 但现在国内IAST产品的发展方向是检测漏洞类型越来越多，漏洞也越来越复杂。 很多类型的漏洞并不是IAST所擅长的。 ，导致目前IAST误报率较高，实用性变差。
误区 10：软件供应链安全就是 SCA
供应链安全是国家和行业必须彻底解决的大问题。 一个组织能做的事情是非常有限的。 软件供应链甚至比硬件更复杂。 各种开源软件的应用是软件供应链复杂化的重要原因之一。 但目前很多厂商在提到软件供应链安全时都推荐软件构成分析（SCA软件构成分析），导致部分用户将软件供应链安全误认为是SCA。
SCA工具功能分为三部分：
显然，SCA系统只解决软件供应链中的一个问题，就是在上线前对软件中包含的开源软件组件进行检测，并根据组件信息分析漏洞和许可协议风险。 对比软件供应链面临的主要威胁：恶意篡改、假冒、供应中断、信息泄露、非法操作等威胁，能够解决的问题确实有限。
