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