1）金融行业的自研及外采软件大量引入开源软件，受到严重的开源软件安全漏洞威胁

2）金融行业开展开源软件供应链安全治理时普遍会遇到的六大关键挑战

3）10月13日，金融行业软件供应链安全治理闭门研讨沙龙，分享如何应对六大挑战

金融行业的自研及外采软件大量引入开源软件，受到严重的开源软件安全漏洞威胁

当前金融行业软件开发大量采用开源软件，2023 ossra report [1] 显示在金融行业98%的代码库中包含开源代码，而平均每个代码项目中开源代码的占比接近75%，在国内国有行及头部股份行存在不少自主研发的软件项目中大量依赖开源代码，当然这些国有行和头部股份行也有大量的软件项目来自于外部采购或者外包开发。其他股份行、城商行、证券、保险及基金中大部分的软件项目来自外包开发及外部采购的商业软件，这些外部采购或者外包开发的软件中开源软件占比依然是大头。

金融业面对这样的现状：

• 国有行及头部股份行存在不少自主研发的软件项目中大量依赖开源软件

• 其他股份行、城商行、证券、保险及基金中大部分的软件项目来自外包开发及外部采购的商业软件，这些软件依然大量依赖了开源软件

2023 ossra report 显示，这些自主研发和外部引入的软件中87%存在安全或许可证合规风险，而且平均每天还有超过100个新增的开源组件安全漏洞和开源组件投毒风险被爆出，这些安全漏洞都有可能对当前的代码项目造成安全威胁，除此之外，这些金融行业企业每天仍然会新增开发或者外购引入大量软件项目，从而带来新的安全威胁。

金融行业开展开源软件供应链安全治理时普遍会遇到的六大关键挑战

过去我和数十家金融行业企业的安全专家有过深入的探讨，大家在开展开源及软件供应链安全治理时，普遍会遇到的六大关键问题，这六个问题将直接影响到治理落地的效果，并且其中大部分的问题可能导致治理项目失败。反之，如果企业能够很好的解决这六个关键问题，那么将取得非常好的治理效果，项目成功的概率将大幅提升，那么接下来我将详细剖析这六个关键问题；

关键挑战一：软件供应链资产台帐

不管是自研软件项目还是外采的软件项目都通过直接或间接的方式引入大量开源组件或开源代码，我们要开展软件供应链安全治理工作的前提是首先要盘点清楚企业到底有多少软件项目，他们又依赖了多少开源软件及代码，包括这里面明确的依赖路径是否可解释，这是我们开展这项治理工作的前提。为什么这么说呢，原因有三：

1）如果我们没有一个完整（或职责范围内完整）的软件供应链安全资产台帐，那么我们没办法量化管理我们的工作进展及工作成果，一项工作如果无法量化管理，那么也就意味着它可能无法获取持续的资源投入，我们可能也无法及时获得成果反馈。

2）这项治理工作通常来说非常的复杂，如果我们无法盘点清楚完整的资产台帐，那么意味着我们无法为这项工作安排优先级，无法判断哪些资产是相对更加重要的，哪些资产的潜在安全隐患相对更大。

3）每天外部会曝出超过100起的软件安全漏洞，如果我们没有完整的软件供应链安全资产台帐，那么就无法准确的判断哪些资产受到影响，那么会让企业持续受到安全漏洞的影响。

通常资产台帐应该包含这几部分关键信息：

关键挑战二：二进制软件成分分析

前面有讲到，金融行业企业有很大一部分的软件都是来自于外部采购或者外包开发，那么这些软件通常在交付的时候不一定会交付源代码，甚至大多数是不会交付源代码的，那么作为甲方如何去管理这些软件依赖的开源组件呢，这个时候就得依赖软件的二进制成分分析，通常二进制的软件成分分析能力有几个关键点：

• 不同主流开发语言编译的二进制的支持：java、go、javascript、c/c++等

• 不同语言的不同编译方式和编译参数的支持

• 不同操作系统及不同处理器架构的编译产物支持

• 不同加壳及加固方式的编译产物支持

通常二进制的软件成分分析结果主要应用在以下几个场景：

• 外采及外包开发软件验证供应商交付的SBOM的完整性

• 甲方自己建立外采及外包开发软件的资产台帐

• 甲方企业自己开发的应用程序在对外发布时的安全性检测（漏洞及许可证合规）

关于二进制的软件成分分析，业界通常没有完美的技术方案，也就是说无法完整的识别出来所有二进制文件中依赖的开源组件成分，且通常大多数工具的识别会存在严重的误报情况，当企业在选择二进制的软件成分分析工具时应该重点关注其识别的准确率及覆盖率。

关键挑战三：组件分级

当我们初步建立开源及软件供应链安全资产台帐后，我们将会发现实际上治理落地工作的挑战非常大，非常大的原因有三点：

• 企业直接或间接依赖的开源软件数量规模巨大

• 这些开源软件的安全漏洞和许可证合规风险数量巨大

• 这些安全风险的解决成本非常高

通常，出现这种情况，但是我们的治理工作仍然需要开展，那么我们会需要对治理的对象进行分类分级，然后根据分类分级的结果来科学的判断安全风险治理工作的优先级，那么通常我们的组件分级工作需要从哪些维度的指标来具体衡量，通常有以下五个维度：

• 组件关联的内部资产覆盖数（关联覆盖业务越多越重要）

• 组件关联的内部资产的重要性（业务的重要性、内外网）

• 组件历史安全漏洞（历史漏洞数、漏洞严重程度、修复及时度）

• 组件许可证合规（许可证合规风险解读）

• 组件维护健康度（维护人、更新频度、社区活跃等）

根据以上五个维度，可将依赖的开源组件进行分级，可分黑/白/灰，也可以单纯的定义级别，该级别的确定最好需要通过公司级的安全组织来审核确定，通常包括安全、研发、测试、运维等技术角色共同审核确定。

由于开源组件的以上五个维度的信息每天实时都是更新的，所以建议至少每周或者最好每天都要更新这个数据，以确保在安全治理流程中参考的数据的严谨性。

关于组件分级的应用场景，通常主要包括：

• 开源组件选型准入的时候，需要根据不同的级别的组件确定不一样的准入及准出管理流程

• 应急响应或出现安全事件/安全工单时，需要根据这个资产台帐信息来确定评级信息，根据不同评级信息启动不同级别的应急响应流程

• 当确定阶段性的工作规划的时候，需要圈定最高优先级的治理范围，此时这个数据就显得尤为重要

关键挑战四：真实影响评估

因为每一个代码项目依赖的开源组件数量非常多，且这些主流的开源组件的漏洞数量也非常多，这就导致每一个代码项目通常有很多个安全漏洞，据统计平均每一个java项目就有超过50个安全漏洞，且这些漏洞的修复成本通常是很高的，对于很多企业来说是没办法修复这所有的漏洞，如果没办法通过判断漏洞的真实影响来评估修复的优先级的话，通常就会导致这项工作无法开展，但是很多严重的开源组件漏洞的攻击方法（poc/exp）通常又是公开的，所以我们必须要搞清楚这些开源组件漏洞对企业的业务会造成的真实影响，通常对于真实影响的评估主要通过以下三个方面：

• 漏洞可达性分析：该漏洞缺陷是否会在线上运行的代码逻辑中被触发，且触发条件是外部攻击者可控的

• 漏洞危害评估：该漏洞有无poc/exp、漏洞严重级别、漏洞攻击成本、漏洞影响范围等

• 漏洞所影响的业务评级：漏洞所影响的业务是否为公司重要业务

通过漏洞可达性分析，我们通常可以过滤掉95%不可达的漏洞，使得每个项目真正需要修复的漏洞数量降低到个位数甚至更低，但是通常来说也并不是说不可达的漏洞就一定不需要修复，它仍然是非常大的潜在隐患，所以通常我们建议降低它的修复优先级，但是仍然需要去修复它。

关于漏洞危害评估及漏洞所影响的业务评级，通常都是用来进一步判断漏洞处置优先级的，通过更科学的漏洞优先级评估，我们可以更加高效的处理掉真正对企业有严重风险的安全问题。这里需要特别说明的是通常cve官方的漏洞评级（CVSS评分）是非常不可靠的，它并不能准确的描述一个漏洞的真实危害，大量cvss评分很高的漏洞实际影响并没有那么大，当然也有一些cvss评分相对较低的漏洞反而影响是很大的。所以通常我们建议企业需要根据漏洞的真实影响、攻击成本、是否有exp/poc、漏洞影响范围等因素来综合判断漏洞的优先级。

关键挑战五：快速修复

开源组件的安全漏洞的修复是需要研发人员操作的，但是我们知道大多数研发人员通常是不懂安全的，而且他们的主要职责也不是修复安全漏洞，而是项目的研发工作，所以要想研发人员更好的配合完成安全的漏洞修复工作，就必须要把修复工作的成本降到足够低，越低越容易推进此项工作的落地，反之，修复的工作成本越高就越难推动落地，当漏洞修复的成本高于某一个边界时，研发及研发的负责人会选择放弃修复工作而接受安全所带来的潜在风险。

研发人员修复开源组件漏洞的成本主要来源于三部分：

• 研发人员理解该漏洞及该漏洞修复方案的成本

• 研发人员找到合适的修复方案的成本

• 研发人员操作修复及修复后调试解决兼容性问题的成本

那么我们如果想要更顺畅的推进漏洞修复工作，需要从以上三个维度来降低研发的漏洞修复成本，这就需要从不同漏洞的修复方式来分析，如何降低修复成本，开源组件漏洞的修复通常有三种方式：

1）直接依赖的升级修复

直接依赖的升级修复通常相对简单，但是也会因为升级带来不兼容的问题而导致升级之后代码产生bug，通常跨大版本的升级出现兼容性问题的概率更大，此外就是该开源组件在代码中的调用越多，升级修复的时候产生兼容性问题的概率也就越大，那么在升级修复的时候，需要能够评估出来兼容性问题最少的那个版本，且尽量不要跨大版本升级修复。此种修复方式最大的成本就是在于兼容性的评估，并选出兼容性问题最小的版本。

2）间接依赖的升级修复

间接依赖的修复通常来说非常的麻烦，最稳妥的修复方案肯定是选择修复引入它的那个直接依赖，但是通常来说很有可能引入它的那个直接依赖的最新版本依然没有修复这个漏洞，此时只能采取指定版本的方式，这可能会导致异常。此时也需要进行严格的兼容性评估和测试。通常间接依赖的组件我们更加需要通过漏洞可达性分析技术来判断该漏洞是否会真的被攻击利用，如果漏洞不可达的情况下，我们可以先采取短期不修复的方案，长期来看可通过升级引入它的直接依赖来修复。此种修复方式最大的成本也是在于兼容性的评估，并选出兼容性问题最小的版本。

3）非升级的修复方式

因为一旦涉及升级，就会带来不可控的兼容性问题，且避免兼容性问题的成本通常是很高的，所以当遇到项目要紧急发布上线的时候，我们可能需要一种非升级就能解决问题的方案，这种方案通常包括两种方式：一种就是打补丁或者开发者自行修改代码来修复漏洞；另外一种就是通过修改一些配置项，来解决安全问题。这种修复方式通常最大的成本是来自于面对数十万种漏洞，我们如何能够准确且高效的评估出来它的非升级的修复方式是什么？

综上，帮助研发人员如何低成本的快速修复漏洞，是决定开源及软件供应链安全治理是否能落地的关键所在。修复成本足够低，那么研发人员去操作修复它的意愿就更强，收益也更大，自然会非常愿意接受这件事情。

关键挑战六：持续运营

金融企业面临的安全风险是每天动态新增和变化的，主要原因来自于两个方面：

• 新的组件引入：每天都会新开发或者引入外采及外包开发的软件，这些软件都会依赖新的开源组件导致安全漏洞；

• 新的漏洞曝出：金融企业存量引入的开源组件每天都会被曝出上百个新的安全漏洞；

基于以上两点，我们需要通过持续运营来保障新增的风险可以得到有效的识别和控制，不然因为组件安全漏洞导致风险就没有办法得到及时的遏制，也就会使得治理工作无法取得预期的效果。那么通常持续运营有几个关键工作：

1）组件知识库及漏洞知识库的持续更新

每天都会有新的开源组件及新的开源组件版本的发布，所以需要持续收录这些新的开源组件及识别组件特征的数据，此外就是每天新增的漏洞数据的更新和维护。

2）开源组件的准入及准出管理

严格的控制高风险组件的引入，并且当一些组件版本过时了或者产生了更多的漏洞时，要及时的清退。

3）研发人员的持续技术培训

通过对研发人员的技术培训来确保他们能够更低成本的修复这些开源组件的安全漏洞，并且避免引入高风险的开源组件，尤其是新入职的研发人员的技术培训

4）软件生产及运行环境的持续集成

将安全检测和修复能力集成进软件生产和运行环境中，确保软件的生产和运行的过程中100%覆盖安全能力，以确保软件的持续安全。

5）安全漏洞的持续检测和修复

持续修复新发现的安全漏洞，保障线上应用的安全性

以上六大挑战企业应该如何应对？我将在10月13日的金融行业软件供应链安全治理的闭门沙龙会上与大家分享。

金融行业软件供应链安全治理闭门技术沙龙

论坛介绍

我们将举办第二届 OSCS 软件供应链安全技术论坛-金融专场闭门研讨会，本次论坛将邀请来自银行、证券、行业监管有丰富经验的技术专家围绕金融行业在软件供应链安全建设方面的实践展开，深入分享金融行业在软件供应链安全的需求痛点及建设实践经验，并在与会嘉宾之间展开深入的探讨交流，共同学习和进步。

主题方向

1、金融行业软件供应链安全体系建设；

2、金融行业的开源软件治理实践；

3、软件供应链安全防护在hw场景中的应用；

议程

会议时间

2023年10月13日

线下会议地点

北京市海淀区中关村创业大街no.12号楼5层

线上会议地点

腾讯会议邀请制

报名方式

此次论坛是金融行业的闭门研讨会，所有的报名都会经过严格的审核，且人员名额有限，目前已定向邀请数十家金融行业企业的安全专家来参加闭门研讨会，此次面向公众号读者开放少量名额（10个），欢迎大家报名，审核通过后会通知您参会。

报名链接：

https://murphysec.feishu.cn/share/base/form/shrcnNYcFzs4TU94bdvWEKxX7Pg

扫描二维码报名：

参考链接：

[1]https://www.synopsys.com/software-integrity/engage/ossra/rep-ossra-2023-pdf

关于我对软件供应链安全、职场的更多思考，点击关注【航行笔记】查看