软件开发安全应用实践中的十个误区

admin 2022年12月9日18:51:48评论63 views字数 4165阅读13分53秒阅读模式

软件开发安全应用实践中的十个误区


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


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


在近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.提出安全问题和解决问题都是安全团队的事


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


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


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


软件开发安全应用实践中的十个误区


误区5.开发团队负责架构设计,安全团队负责安全设计


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


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


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


软件开发安全应用实践中的十个误区


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


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


相关阅读

你还在忽视供应链安全?安全厂商开发的软件被植入后门

安全软件开发的三大错误


软件开发安全应用实践中的十个误区

合作电话:18311333376
合作微信:aqniu001
投稿邮箱:[email protected]


软件开发安全应用实践中的十个误区

原文始发于微信公众号(安全牛):软件开发安全应用实践中的十个误区

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年12月9日18:51:48
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  软件开发安全应用实践中的十个误区 http://cn-sec.com/archives/1454110.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: