金融业开源软件应用 评估规范

序号

评估项

评估方法

示例

适用对象

1

使用者在修改源码后宜允许对修 改部分进行闭源。

查看文档。

核查开源许可证文档，对于修改后 的代码无开源要求。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

2

宜对变更进行声明。

查看文档。

核查开源许可证文档，条款要求开源 软件发生变更时需向用户进行声明。

开源基础软件、 开源组件。

3

宜选择宽松型或弱著佐权开源许 可证。

查看文档。

核查开源许可证文档，有对应免责条 款，无特定IP段限制、无特定设备限 制、无企业资本限制、无工作模式限 制等限制性条款。

开源基础软件、 开源组件。

4

应评估开源许可证兼容性。

查看文档。

a）若开源软件中存在多个开源许可  证，确保多个开源许可证之间不存 在冲突。

b）比对开源软件和依赖软件之间许可 证兼容性，确保开源许可证之间不 存在冲突。

开源基础软件、 开源组件。

注：1.对于独立于开源许可证的专利授权场景，在引入阶段着重评估此专利授权条款。

2.本文件中的查看文档指查阅代码托管平台记录、设计文档、开发文档、源码、管理文档、漏洞平台、审 计报告、 自查报告、社区公示信息等相关材料。

序号

评估项

评估方法

示例

适用对象

1

应评估使用者数量与行业分布。

查看文档。

开源软件在多个行业中广泛使用或在同 行业中至少1家机构已使用。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

1

应评估开源软件的版本发布周期， 周期间隔越短则优先考虑，例如最 后一次更新时间在3个月内。

查看文档。

核查开源软件最近3个版本的发布间 隔，间隔不超过3个月。

开源基础软件、 开源组件。

2

应评估参与者的代码贡献量。

查看文档。

核查最近1年中每季度的代码贡献量情 况，该数值越高表示社区越活跃，更可 能获得长期支持，并优先考虑。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

3

应评估开源社区活跃度。

查看文档。

核查项目支持度、项目关注数、项目复刻 数、提问回复情况，社区活跃度高则优先 考虑。

开源基础软件、 开源组件。

4

应评估项目代码提交情况。

查看文档。

核查开源软件的提交总次数、项目代码合 并请求次数，提交次数越多表示开发者活 跃程度越高。

开源基础软件、 开源组件。

5

应评估贡献者数量。

查看文档。

核查开源软件近3年每季度贡献者数量变 化情况，贡献者数量呈上升趋势则优先考 虑。

开源基础软件、 开源组件。

6

应评估前 10 位贡献者所属组 织。

查看文档。

核查前10位贡献者来源是否集中于某1个 公司，贡献者来源多则优先考虑。

开源基础软件、 开源组件。

7

应评估前 3 位贡献者代码量占 比。

查看文档。

核查并统计前3位贡献者的代码量占据前 10名总量的比例，比例小则优先考虑。

开源基础软件、 开源组件。

8

应评估前 10 位贡献者国别差 异。

查看文档。

核查并统计前10位贡献者的国别集中度， 国别差异大则优先考虑。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

1

应评估商业支持情况。

查看文档。

a）核查服务商提供协助运维或托管运维 等方面的支持情况，商业支持种类越 多则优先考虑。

b）服务提供商数量越多则优先考虑。

开源基础软件、 开源组件。

2

应评估组织、机构对开源软件的 贡献情况。

查看文档。

除了个人代码贡献者，以组织、机构为 责任主体的代码贡献者越多则优先考

虑。

开源基础软件、 开源组件。

3

应评估说明文档的数量、质量等 支持情况。

查看文档。

a）文档的数量宜多不宜少。

b）官方网站中的说明文档、帮助文档文 字的数量宜多不宜少。

c）文档含有图例、代码示例，简单易懂， 与开源软件关联度越强则优先考虑。

开源基础软件、 开源组件。

4

应评估文档覆盖范围。

查看文档。

核查官方网站中的文档覆盖范围，文档 覆盖范围越全则优先考虑。

开源基础软件、 开源组件。

5

应评估开源软件技术发展路线 是否清晰。

查看文档。

在社区、官方网站等渠道有开发规划等 信息公示，开源软件的技术发展路线越 清晰则优先考虑。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

6

应评估是否有中文支持。

查看文档。

具有中文版本的说明文档且及时更新， 相关的开发工具、管理工具和运维工具 的中文支持情况越多则优先考虑。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

1

应评估该开源软件的核心功能。

查看文档。

核心功能满足评测场景的功能需求。

开源基础软件、 开源组件。

2

应评估该开源软件功能覆盖是否 全面。

查看文档。

开源软件的扩展功能丰富，可满足应用 需求。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

1

应综合评估开源软件的安全漏 洞数及等级。

查看文档。

a）结合开源软件关注度、发行时间

（年数）对开源软件安全漏洞数进 行综合评估。可将已暴露的安全漏 洞数/（开源软件分支数×发行时 间）的值作为评判依据，宜低不宜 高。

b）已暴露的安全漏洞等级宜低不宜 高。

开源基础软

件、开源组件。

2

应评估开源软件已暴露安全漏 洞的修复情况。

查看文档。

核查已暴露的安全漏洞是否已修复，

或核查是否采取安全措施，保证重大  安全漏洞（例如CVE）已被修复或不会 触发。

开源基础软

件、开源组件。

3

应通过代码扫描评估该开源软

件安全情况，应保证代码扫描后 无严重安全漏洞或高危安全漏

洞。

a）查看文档。 b）测试系统。

核查是否有代码扫描记录，并进行代 码静态扫描，保证扫描后无严重安全 漏洞或高危安全漏洞。

开源基础软

件、开源组件。

序号

评估项

评估方法

示例

适用对象

4

应评估开源软件自身安全机制。

查看文档。

a）安全漏洞修复时效性高，可快 速修复。

b）安全漏洞反馈渠道清晰。

开源基础软件、 开源组件。

注：本文件中的测试系统指利用专业工具，通过对目标系统的扫描、探测等操作，使其产生特定的响应等活 动，通过分析响应结果，获取证据以证明开源软件的基本要求、性能、安全性是否得以有效实施。

序号

评估项

评估方法

示例

适用对象

1

应评估该开源软件故障处理能 力。

a）查看文档。 b）测试系统。

a）验证不同场景下，开源软件自 动切换的能力。

b）开源软件出现故障后具备可以 快速恢复的功能。

开源基础软件、 开源组件。

2

应评估该开源软件的容错能力。

a）查看文档。 b）测试系统。

在部分节点宕机后仍可提供服务。

开源基础软件、 开源组件。

3

应评估开源软件的故障修复时 间。

a）查看文档。 b）测试系统。

故障恢复时间宜短不宜长。

开源基础软件、 开源组件。

4

应评估开源软件自身的数据恢 复能力。

a）查看文档。 b）测试系统。

开源软件在故障下可保证数据一 致性和防止数据丢失。

开源基础软件、 开源组件。

5

应评估开源软件的运行状态监 控能力。

a）查看文档。 b）测试系统。

监控指标可覆盖系统运行状态。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

1

应评估是否具备鉴 权功能。

a）查看文档。 b）测试系统。

对外直接提供服务、接口调用服务的开源软 件，具备密码登录等访问控制功能。

开源基础软件。

2

应评估是否支持加 密通信。

a）查看文档。 b）测试系统。

a）在远程运维通信过程中采用校验技术或密 码技术保证数据的完整性。

b）采用密码技术对敏感通信内容或整个通信 报文进行加密，保证数据的保密性。

c）加密算法和密钥长度是否符合国家密码管 理部门及行业主管部门要求。

开源基础软件、 开源组件。

3

应评估是否支持集 成外部认证插件。

a）查看文档。 b）测试系统。

对外部插件具有认证功能则优先考虑。

开源基础软件。

序号

评估项

评估方法

示例

适用对象

1

应评估开源软件的稳定  性，评估其无故障运行的 能力。

测试系统。

根据系统的重要性设置差异化可靠性评估  指标。例如对于实时重要信息系统，测试系 统在极限情况下至少稳定运行24小时，核查 监控指标是否正常。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

1

应评估该开源软件的TPS 是否满足预估需求。

a）查看文档。 b）测试系统。

a）查看软件说明文档声明的测试场景下 TPS数值。

b）在业务需求场景下测试系统，在满足预 估需求的情况下，TPS数值越高则优先  考虑。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

2

应评估该开源软件的QPS 是否满足预估需求。

a）查看文档。 b）测试系统。

a）查看软件说明文档声明的测试场景下的QPS。

b）在业务需求场景下，系统并发查询交易信息，

交易信息查询吞吐率越大则优先考虑。

开源基础软件、 开源组件。

3

应评估该开源软件的平 均响应时间是否满足预 估需求。

a）查看文档。 b）测试系统。

a）查看软件说明文档声明的测试场景下的平均 响应时间。

b）在业务需求场景下，平均响应时间越短则优 先考虑。

开源基础软件、 开源组件。

4

应评估该开源软件的最 大响应时间是否满足预 估需求。

a）查看文档。 b）测试系统。

a）查看软件说明文档声明的测试场景下的最大 响应时间。

b）在业务需求场景下，最大响应时间越短则优 先考虑。

开源基础软件、 开源组件。

5

应评估该开源软件的最 大并发数是否满足预估 需求。

a）查看文档。 b）测试系统。

a）查看软件说明文档声明的测试场景下的最大 并发数。

b）在业务需求场景下，最大并发数越大则优先 考虑。

开源基础软件、 开源组件。

6

应评估服务调用成功率 是否满足预估需求。

a）查看文档。 b）测试系统。

a）查看软件说明文档声明的测试场景下的服务 调用成功率。

b）在业务需求场景下，服务调用成功率越高则 优先考虑。

开源基础软件、 开源组件。

7

应评估响应时间标准差 是否满足预估需求。

a）查看文档。 b）测试系统。

a）查看软件说明文档声明的测试场景下的响应 时间标准差。

b）在业务需求场景下，响应时间标准差越小则 优先考虑。

开源基础软件、 开源组件。

8

应评估主机CPU使用率是 否满足预估需求。

a）查看文档。 b）测试系统。

a）查看软件说明文档声明的测试场景下的主机 CPU使用率。

b）在业务需求场景下，主机CPU使用率越低则 优先考虑。

开源基础软件、 开源组件。

9

应评估内存占用率是否 满足预估需求。

a）查看文档。 b）测试系统。

a）查看软件说明文档声明的测试场景下的内存 占用率。

b）在业务需求场景下，内存占用率越低则优先 考虑。

开源基础软件、 开源组件。

10

应评估带宽占用是否满 足预估需求。

a）查看文档。 b）测试系统。

a）查看软件说明文档声明的测试场景下的带宽 占用。

b）在业务需求场景下，带宽占用率越低则优先 考虑。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

11

应评估I/O情况是否满足 预估需求。

a）查看文档。 b）测试系统。

a）查看软件说明文档声明的测试场景下的 I/O情况。

b）在业务需求场景下，I/O数值越小则优先 考虑。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

1

应评估硬件兼容性。

a）查看文档。 b）测试系统。

查看文档并进行系统测试，核查开 源软件的运行是否对硬件有特殊 要求，例如服务器型号的要求。

开源基础软件、 开源组件。

2

应评估操作系统的兼容性。

a）查看文档。 b）测试系统。

a）开源软件支持在多个操作系统 上兼容。

b）在不同的操作系统上无需重新 编译。

开源基础软件、 开源组件。

3

应评估数据库兼容性。

a）查看文档。 b）测试系统。

核查是否支持多种数据库，数据库 支持种类越多则优先考虑。

开源基础软件、 开源组件。

4

应评估开源软件版本之间的兼容 性。

a）查看文档。 b）测试系统。

升级后的版本与升级前版本在系 统间数据交互的参数、格式等方面 未发生变更。

开源基础软件、 开源组件。

5

应评估编程语言的兼容性。

a）查看文档。 b）测试系统。

兼容主流开发语言接口（例如 JAVA、C++等）。

开源基础软件、 开源组件。

6

应评估协议兼容性。

a）查看文档。 b）测试系统。

支持主流协议（例如TCP、HTTP等）。

开源基础软件、 开源组件。

7

应评估与同一运行环境的其他软 件的兼容情况。

a）查看文档。 b）测试系统。

同一运行环境下，可兼容存在依赖 关系的其他软件。

开源基础软件、 开源组件。

8

应评估开源软件与国产操作系统 的兼容性。

a）查看文档。 b）测试系统。

在国产操作系统上功能正常，运行 稳定。

开源基础软件、 开源组件。

注：1.JAVA是1种计算机编程语言，被广泛用于开发各种应用程序和网络应用程序，包括网站后端、客户端应用 程序等。

2.C++是1种计算机编程语言，被广泛用于开发系统软件、应用程序、驱动程序和游戏等，具有高性能、可移 植性、灵活性等优点。

序号

评估项

评估方法

示例

适用对象

1

应评估代码可读性，例如评估 是否使用模块划分、代码注释 使用情况等。

a）查看文档。 b）统计工具。

a）应使用模块化设计。

b）代码的注释量不低于5%。

开源基础软件、 开源组件。

2

应评估运维复杂性。

查看文档。

a）紧密耦合组件宜少不宜多。

b）应支持一般故障自动化处理，无需 人工介入。

c）开源软件的配置简单。

开源基础软件、 开源组件。

3

应评估在线变更能力。

a）查看文档。 b）测试系统。

关键配置参数支持在线变更。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

1

应评估水平扩展能力。

a）查看文档。

b）测试系统。

支持大规模集群和水平扩展。

开源基础软件、 开源组件。

2

应评估动态扩展能力。

a）查看文档。

b）测试系统。

支持动态扩容和动态缩容。

开源基础软件、 开源组件。

3

应评估代码扩展能力。

a）查看文档。

b）测试系统。

优先选择定制开发改动量小、代码 扩展性好的开源软件，例如微内核 加插件式设计思想的软件具有比 较好的代码扩展性。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

1

应评估使用开源软件的学习成 本。

查看文档。

应用案例充分且质量良好、重要场 景包含完整的示例代码，能够较快 熟练操作。

开源基础软件、 开源组件。

2

应评估安装和部署的难易程 度。

a）查看文档。

b）测试系统。

支持图形化安装部署、一键脚本安 装部署等方式，安装和部署简易。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

1

应评估开源软件是否正常 运行且满足需求。

a）查看文档。 b）测试系统。

搭建环境后开源软件正常运行，功能与说 明文档一致，核心功能支持业务需求。

开源基础软件、 开源组件。

2

应对开源软件进行漏洞修 复及补丁升级。

查看文档。

a）具备漏洞定期扫描和修复的记录。

b）生成漏洞扫描报告或现场进行漏洞扫 描。

c）根据漏洞等级及时修补。

开源基础软件、 开源组件。

3

应建立指标定期监控机 制。

查看文档。

a）对开源许可证、功能特性、安全性、可 靠性和性能效率、产品活跃度等方面建 立监控策略。

b）建立相应的监控机制，对上述指标内容 进行监控并形成监控记录。

c）对于产品活跃度监控指标发生变动，或 产品版本不活跃的开源软件进行进一  步评估。

开源基础软件、 开源组件。

4

应通过软件制品仓库对开 源软件进行管理。

查看文档。

开源软件源码以及升级（补丁）包应保存 在软件制品仓库，并提供统一访问地址。

开源基础软件、 开源组件。

5

应形成统一的开源软件目  录清单，并进行定期维护、 更新和发布。

查看文档。

核查文档，形成统一的开源软件目录清  单，进行定期维护、更新和发布，并有相 应的记录。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

1

应满足简单使用类开源软 件的维护要求。

参考7.2评估方 法。

参考7.2示例。

开源基础软件、 开源组件。

2

应评估开源软件服务高可 用能力。

a）查看文档。 b）测试系统。

a）掌握开源软件核心算法、高可用实 现方式，当部分节点故障时，确保 数据一致且不丢失。

b）形成部分节点故障时的恢复方案。

开源基础软件、 开源组件。

3

应评估开源软件所依赖的  服务出现版本更新或故障  （或部分故障）对开源软件 的影响。

查看文档。

形成开源软件的依赖服务清单，对该类 服务出现版本更新或故障（或部分故

障）所可能造成的影响进行分析，制定 对应的应急预案。

开源基础软件、 开源组件。

4

应评估开源软件出现故障 时对业务造成的影响。

查看文档。

形成开源软件故障时的应急预案并建 立相应的持续优化机制。

开源基础软件、 开源组件。

5

应评估开源软件重要指标 阈值设置与告警及处置机 制情况。

a）查看文档。 b）测试系统。

a）可使用监控工具对开源软件的主要 功能、性能、业务数据进行监控并 设置阈值，依据设定的阈值（或默 认阈值）实时告警。

b）可建立超出阈值的应急处置预案。

开源基础软件、 开源组件。

6

应评估开源软件的可监控 功能。

查看文档。

可通过搭建监控运维平台，以自动化脚 本方式实现对开源软件自身故障数据

监控与处理。

开源基础软件、 开源组件。

7

应评估开源软件故障解决 能力。

查看文档。

可通过源码分析等方式确定问题产生 的原因并形成解决办法。

开源基础软件、 开源组件。

8

应持续评估重要开源软件 出现版本更新等变化时对 现有系统的影响。

查看文档。

出现缺陷、安全漏洞及社区更新（例如 功能架构改变、开源许可证更新）时， 可及时完善应急处置方案。

开源基础软件、 开源组件。

注：重要开源软件指在核心链路中一旦出现故障影响较大的开源软件。

序号

评估项

评估方法

示例

适用对象

1

应满足深度使用类开源软件 的维护要求。

参考7.3评估 方法。

参考7.3示例。

开源基础软件、 开源组件。

序号

评估项

评估方法

示例

适用对象

2

应评估开源软件的核心技术掌控 程度。

a）人员访谈。

b）测试演练。

技术人员熟悉开源软件的实现  思路、容错容灾机制、底层数据 流向、存储方式、计算原理等核 心内容。

开源基础软件、 开源组件。

3

应评估开源软件的持续优化能 力。

a）查看文档。

b）人员访谈。

c）测试系统。

根据使用过程中开源软件出现  的问题与不足，分析、掌握每个 功能的缺点、性能瓶颈，梳理可 优化项，对开源软件持续优化。

开源基础软件、 开源组件。

4

应评估开源软件产品化能力。

查看文档。

持续完善定制开发的开源软件  功能、性能，梳理功能需求，将 其封装为产品，对外提供服务， 并不断提供技术支持和技术迭  代更新，探索产品化输出。

开源基础软件、 开源组件。

注：1.人员访谈指与被测系统或产品有关人员进行交流、讨论等活动，获取相关证据，了解有关信息。

2.测试演练指结合测试场景的搭建，通过模拟实际应用场景、灾难环境等，从基础知识、代码审查、性能测 试、安全测试到应急响应测试等层面，对处置方式、效率、有效性等进行综合评估的过程。

序号

评估项

评估方法

示例

适用对象

1

应评估开源软件退出机制。

查看文档。

开源软件的退出应经过评审并  制定退出计划，退出计划应至少 包含可行性分析、对现有业务及 系统的影响、升级或更换的软件 调研分析及其生效日期的提示。

开源基础软件、 开源组件。

2

应评估开源软件的升级具备兼容 性。

a）查看文档。

b）测试系统。

升级后版本与退出的版本在参 数、功能等方面均可兼容。

开源基础软件、 开源组件。

3

应评估开源软件在升级后开源许 可证的变化。

查看文档。

开源许可证如发生变化，应按照 6.2.1进行重新评估。

开源基础软件、 开源组件。

4

应评估更换的开源软件。

参考6评估方法。

应按照6进行重新评估。

开源基础软件、 开源组件。