近期，应用安全测试 (AST) 领导厂商新思科技 (Synopsys) 的网络安全研究中心 (CyRC)，委托 Ponemon Institute 对金融服务行业 (FSI) 当前的软件安全实践现状进行独立调研 (The State of Software Security in the Financial Services Industry)。
金融服务行业对新技术的应用一向是走在前面的。无论是传统的柜台，还是在线和移动业务，随着业务模式的快速变化，为了给客户提供更加完善的体验，对软件开发、运维以及业务自动化的需求和挑战，都在不断增加。软件的安全性，是企业顺利开展金融服务最底层的保障。因此，金融服务行业对软件安全的重视，以及确保他们所用技术安全性的实践力度，都是非常大的。
这份报告最终由 414 份有效问卷反馈产生，覆盖银行、保险、抵押贷款/处理和经纪业务 (brokerage) 等行业。受访者的职务囊括开发、安装和实施金融应用，以及为金融服务行业提供服务的IT和IT安全从业者；受访者的职位，除了工程师和技术人员外（两者共占据受访者的 32%），还有大量的管理层人员（这其中还包括 3% 的高级行政和 5% 的企业 VP）。也就是说，这份调研报告，可以从技术和管理两种视角，提供相对完整、客观和具有针对性的洞见。
那么，从软件安全的角度，金融服务行业目前的实践现状如何？如何看待不同安全措施、工具间的差异？以及，现存的主要挑战和趋势有哪些？
渗透测试、安全补丁管理和动态应用安全测试是首选
首先，在网络攻击的预防、检测和控制三个方面，报告显示，受访者基于自身实践经验，对成功检测攻击最有信心 (56%)；其次是控制网络攻击的蔓延，仅有 3 个百分点的降低 (53%)；而在攻击的预防，却呈现有明显的下降，能够保持信心的受访者只有 31%。
对攻击预防能力的信心不足，可以看作金融服务行业在安全措施选择上的倾向性的一种体现。
报告详细询问了受访者关于安全措施、活动和工具，在以减少网络安全风险、保护金融软件和技术，以及寻求软件的高质量保证为目的下的选择倾向。有趣的是，无论是出于哪种目的，受访者前三个选择：渗透测试、安全补丁管理和动态应用安全测试 (DAST)，除了排序外，都没有变化。这也从侧面反映出，渗透测试的市场需求，为何在近两年快速增长，以及补丁管理这一 “古老方式” 的有效性和可延续性。
但是，如果我们倒序观察，可以发现这样一个现象，那就是诸如安全需求定义、软件组件分析、安全架构设计等，从软件立项开发阶段就要开始筹备，甚至贯穿整个开发生命周期的安全措施，却是大部分受访者目前较少会考虑的手段。例如，选择 “软件组件分析” 的倾向性，往往不到 “渗透测试” 的一半。这也部分回答了受访者对 “攻击预防能力信心不足” 的可能的原因。
之后，我们把关注点放到开发人员和流程上。
报告这部分内容的聚焦点，主要集中在开发人员是否接受过安全（开发）培训、开发流程是否遵循 SSDLC（安全软件开发生命周期）、以及如何确保第三方开发人员满足安全要求。
在培训方面，仅有 19% 的受访者表示会选择强制让开发人员参加一定程度的安全开发培训。但与之相对，有更多 (25%) 的受访者表示，“不，我们不提供任何安全开发培训”，则是一个更可悲的消息。
对于已公开发布的 SSDLC 流程，仅有 26% 的受访者表示，无论是企业内部还是外部的开发，都不会遵守；企业内部和外部都遵守的，也只是相对少数，仅占到 20%。但是，我们要看到的是，即使是最多的选项，仅要求外部开发遵循 SSDLC，也只有 31%，而金融机构选择对软件和技术在安全漏洞方面的测试的平均水平，就已经达到了 34%。
可以看到，尽管业界有诸多认可度较高的 SSDLC，在落地、执行层面的阻力也是较大的。能够较好执行（内外部兼具）的，仅有 2 成。对于此，新思科技在 2018 年发布的一篇关于 devsecops（注：开发、安全、运营缩写的组合词汇）的报告中，点明了部分原因：
在 CI/CD（持续集成/持续交付&部署）流中引入安全测试的挑战，最多数的选择是 “缺乏工程化能力强的安全测试工具”，占到了 61%。排名第二位的，不是我们常认为的拖慢开发进度或者安全测试的误报率高（虽然也分别有 48% 和 46%），而是企业自身在服务和自建能力中间举棋不定（占到了56%）。研发人员的抵触情绪，也是考虑因素，但只占到了 36%。
对于外部，也就是第三方的开发人员，43% 的受访者表示会要求验证第三方是否在参与金融软件和技术开发的过程中遵循了安全实践。但是在验证方式上，却有超过半数 (55%) 的选择是让第三方自我评估并提交验证结果，而没有审核程序。相对的，愿意直接由内部团队对第三方进行安全评估的，只有 23% 机构的选择。此外，没有正式流程，无法验证第三方开发安全实践情况的，也占到了 32%。
验证方式的有效性，可以说直接关乎第三方开发代码的安全性基线。如果因为第三方开发安全流程的缺失，而没有发现软件中存在的已知漏洞并被攻击者利用的话，无论是数据泄漏还是被勒索、恶意攻击，对企业而言都是不应该有的重大损失。
最后，对金融服务机构安全计划整体有效性的评估，我们可以看到和第三方安全验证一样的不足。
报告调研了受访者使用哪种工具来评估机构的安全性计划。不出意外，选择 “内部评估” 的占到了绝对优势的 64%，而选择 BSIMM 或 OpenSAMM 这两类业界认可度较高的软件安全成熟度模型的，分别仅有 30% 和 27%。后两者之和还不及 “内部评估”。
不难理解，内部评估和第三方自证的模式，虽然是目前以美国、欧洲为主（下图为此次调研对象所在组织的分布情况）金融服务业的普遍选择，但是其结果很难有足够的说服力和安全保障。
软件安全是一个旅程
安全能力前置，是近些年全球安全行业一直在倡导、呼吁的一个声音。到底要多 “前”？虽然目前仍没有具体、统一的合规要求，但是，将安全性的考量、验证嵌入整个开发周期，而不是只从上线前的测试阶段才开始，是业界共识。
从上述报告中的内容中不难看出，大量金融服务机构经常是在软件发布上线后，才考虑安全措施，对整体的安全计划、内外部开发代码的安全性，缺乏有效的验证手段，是不争的事实。
然而，这份窘境，不会只局限在金融服务业。
致力于软件质量与安全，特别是在应用安全测试领域有较深厚积累的新思科技，一直公开表示，软件安全是一个旅程。企业要充分借助 SDLC，也要将安全性测试融入 devops 体系。这需要在不同阶段，合理利用不同的工具。
对于一些实践经验，新思科技软件质量与安全部门高级安全架构师杨国梁介绍道，比如，在 pre-commit 阶段，可以选择静态应用安全测试 (SAST)，并调整为误报率较低规则；在之后的 commit 和 build 阶段，可以借助动态安全测试 (DAST) 和软件组件分析 (SCA) 工具，对特别是开源组件的许可证、已知安全漏洞等情况进行深度白盒检查；最后的 test 和 deploy 阶段，则可以考虑模糊测试、交互式应用安全测试 (IAST)、渗透测试等手段，进行后续的持续监控，以确保 SDLC 每个阶段的安全性。
当然，无论采取哪些方法或工具，都必须与业务保持一致，支持和保护业务发展。
杨国梁表示，新思科技通过收购黑鸭 (Black Duck) 而形成的针对开源组件的软件组成分析能力，目前在中国的银行和券商业有较多的应用案例。
全球金融服务行业软件应用的特点，都是对开源组件的依赖度比较高。中国也不例外。黑鸭有 70 人左右的团队，进行开源组件识别的优化、已知漏洞信息的收集和有效性的验证，以及处理建议，这个时效已经可以做到 1 小时。而且对于代码，只是做特征匹配，所有管理和监控都在本地，所以也基本不会有源码泄漏的担忧。而且，这份能力几乎是贯穿整个 SDLC 应用的。
此外，在应用安全测试方面，杨国梁还表示，目前金融服务机构对交互式应用安全测试 (IAST) 比较感兴趣。这种形式特别适合 Web 应用的测试场景，可以结合业务应用的功能性测试，不需要额外的投入，进行实时的安全性验证。
虽然目前来看，IAST 能进行的安全测试相对基础，但对人员压力的释放，缓解开发人员抵触这个角度，却有很大优势。而且中国也已经有部署案例。
安全牛评
不只是业务流程的严谨，金融安全已经在很大程度依赖于对技术、对软件安全性的保障。虽然金融服务机构也在紧追威胁态势，对新兴安全技术和工具的尝试相对其它行业也是更加积极主动，但是不断完善的攻击检测和控制能力，也逐渐暴露出预防的短板。这也是安全工作思路一个亟待补充的区域。对开源组件安全性的重视，更契合的安全测试和验证方式，更充分的融入面向业务的 SDLC 过程，相信会成为之后金融服务行业在软件安全和安全能力整体建设的重要方向。
报告下载：
相关阅读
