JR_T0291-2024金融业开源软件应用评估规范.docx

《JR_T0291-2024金融业开源软件应用评估规范.docx》由会员分享，可在线阅读，更多相关《JR_T0291-2024金融业开源软件应用评估规范.docx（20页珍藏版）》请在优知文库上搜索。

1、ICS35.240.40CCSA11JR中华人民共和国金融行业标准JR/T02912024金融业开源软件应用评估规范2024 - 01 - 15 发布OpensourcesoftwareapplicationsinfinancialindustrySpecificationforevaluation2024-01-15实施中国人民银行目次前言11引言III1范围12规范性引用文件13术语和定义14缩略语15概述16开源软件引入评估27开源软件维护评估118开源软件退出评估139证实方法14参考文献15本文件按照GB/T1.1-2020标准化工作导则第1部分：标准化文件的结构和起草规则的规定起草

2、。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由北京金融科技产业联盟提出。本文件由全国金融标准化技术委员会（SAC/TC180）归口。本文件起草单位：中国人民银行科技司、北京金融科技产业联盟、网联清算有限公司、中国工商银行股份有限公司、中国农业银行股份有限公司、中国银行股份有限公司、中国建设银行股份有限公司、上海浦东发展银行股份有限公司、平安银行股份有限公司、中国光大银行股份有限公司、北京国家金融标准化研窕院有限责任公司、中信百信银行股份有限公司、深圳前海微众银行股份有限公司、浙江网商银行股份有限公司、中国平安保险（集团）股份有限公司、华为技术有限公司、腾讯

3、云计算（北京）有限责任公司、浪潮集团有限公司、北京百度网讯科技有限公司、阿里云计算有限公司。本文件主要起草人：李伟、陈立吾、周祥昆、詹志建、刘帅、潘润红、聂丽琴、胡达川、李寻、强群力、郑仕辉、刘超千、张群、郭林、张文凌、赵彤、薛松源、吴涛、包仕翔、孙刚、罗致力、刘阳、蔡仕志、闫晓林、刘建珍、王丽静、黄凯、金磐石、李鑫、杨欣捷、弓豪怡、杜胜、贾凯、刘玉花、周夕崇、谢彦丽、张晋任、李佳凝、薄舜添、周欢、辛子英、钟燕清、丛洋、陆碧波、谭翔、赵峰、龙凯、苏威硕、白阳、邱成锋、胡正策、耿航、董宾、姜江、陈明、杜守志、刘牧、黄云、胡伟琪、王品昱。在金融业信息系统建设过程中，开源软件得到了广泛应用，在促进金

4、融机构科技创新和数字化转型等方面发挥了积极作用，但也带来安全、合规等方面的风险与挑战。因此，有必要对开源软件的引入、维护、退出阶段进行规范，提出相应的评估指标。本文件旨在针对开源软件使用过程中的风险与难点，提出一套完整的开源软件生命周期管理各阶段评估项与评估方法，降低金融机构开源软件评估过程的复杂度和时间成本，提升金融机构开源治理能力。Ill金融业开源软件应用评估规范1范围本文件规定了金融机构在应用开源软件时的评估要求，对开源软件的引入、维护和退出提出了实现要求、评估方法和判定准则。本文件适用于金融机构对应用的开源软件进行评估。2规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必

5、不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。JR/T02892024金融业开源技术术语3术语和定义JR/T02892024界定的以及下列术语和定义适用于本文件。信息系统informationsystem由计算机系统、网络系统软件硬件及其相关设备、设施、应用软件等构成的，按照一定的应用目标和规则对信息进行采集、加工、存储、传输、检索等处理的人机系统。来源：JR/T01402017,3.24缩略语下列缩略语适用于本文件。CPU：中央处理单元(CentraIProcessingUnit)CVE：公共漏洞与曝光(

6、ComnIonVulnerabiIitiesandExposures)HTTP：超文本传输协议(HyPerteXtTransferProtocol)1/0：输入/输出(Input/Output)QPS：每秒请求查询次数(QUeryPerSecond)TCP：传输控制协议(TranSmiSSiOnControlProtocol)TPS：每秒事务处理次数(TransactionPerSecond)5总体要求在金融业信息系统的建设过程中，引入的开源软件按照实际应用情况，可分为开源基础软件、开源组件和开源工具3类，各阶段应用评估要求主要包括以下内容。a）引入时，不同开源软件的功能特性、性能效率存在差异

7、，且可靠性、安全性、兼容性、可扩展性等方面也应全面考察，因此开源软件引入评估应包含引入流程和较为全面的引入指标。b）维护时，规范阐述如何确保开源软件运行过程的自主可控，对简单使用类、深度使用类与定制开发类的开源软件分别提出不同的维护要求。c）退出时，应根据业务需求或软件迭代进展，有序完成版本更新或软件更换。6开源软件引入评估6.1 开源软件引入流程开源软件引入流程共分为3个阶段，如下图所示。一.需求确定二.初步筛选三.修选评估图开源软件引入流程图开源软件的引入流程具体内容如下。a）需求确定阶段应明确软件功能需求与非功能需求。b）初步筛选阶段应根据需求展开调研，依照初选评估要求（见6.2）,对开

8、源软件进行评估，建立若干可进入终选评估的开源软件名单。c）终选评估阶段应根据初选阶段建立的开源软件名单，依照终选评估要求（见6.3）进行评估，并确定最终引入的开源软件。对于开源组件类，若对应的应用程序通过了各项测试，可认为该程序中所有组件均满足了相关要求。对于开源工具类，可在引入、维护、退出阶段适配对应指标。6.2 初选评估要求6.2.1开源许可证金融机构在选用开源软件时，应遵守该开源许可证对使用、修改等行为的规定，开源许可证评估内容见表1。表1开源许可证评估内容表序号评估项评估方法小例适用对象1使用者在修改源码后宜允许对修改部分进行闭源。查看文档。核查开源许可证文档，对于修改后的代码无开源要

9、求。开源基础软件、开源组件。表1开源许可证评估内容表（续）序号评估项评估方法示例适用对象2宜对变更进行声明。查看文档。核查开源许可证文档，条款要求开源软件发生变更时需向用户进行声明。开源基础软件、开源组件。3宜选择宽松型或弱著佐权开源许可证。查看文档。核查开源许可证文档，有对应免责条款，无特定IP段限制、无特定设备限制、无企业资本限制、无工作模式限制等限制性条款。开源基础软件、开源组件。4应评估开源许可证兼容性。查看文档。a）若开源软件中存在多个开源许可证，确保多个开源许可证之间不存在冲突。b）比对开源软件和依赖软件之间许可证兼容性，确保开源许可证之间不存在冲突。开源基础软件、开源组件。注：L

10、对于独立于开源许可证的专利授权场景，在引入阶段着重评估此专利授权条款。2.本文件中的查看文档指查阅代码托管平台记录、设计文档、开发文档、源码、管理文档、漏洞平台、审计报告、自查报告、社区公示信息等相关材料。6.2.2产品认可度产品认可度反映了开源软件在行业生产实践中的应用情况，产品认可度评估内容见表2。表2产品认可度评估内容表序号评估项评估方法示例适用对象1应评估使用者数量与行业分布。查看文档。开源软件在多个行业中广泛使用或在同行业中至少1家机构已使用。开源基础软件、开源组件。6.2.3产品活跃度产品活跃度反映了开源软件的可持续性和可进化能力，主要从开源软件的版本发布情况、开源社区情况、软件关

11、注情况等方面进行评估。产品活跃度评估内容见表3。表3产品活跃度评估内容表序号评估项评估方法示例适用对象1应评估开源软件的版本发布周期，周期间隔越短则优先考虑，例如最后一次更新时间在3个月内。查看文档。核查开源软件最近3个版本的发布问隔，间隔不超过3个月。开源基础软件、开源组件。2应评估参与者的代码贡献量。查看文档。核查最近1年中每季度的代码贡献量情况，该数值越高表示社区越活跃，更可能获得长期支持，并优先考虑。开源基础软件、开源组件。表3产品活跃度评估内容表（续）序号评估项评估方法示例适用对象3应评估开源社区活跃度。查看文档。核查项目支持度、项目关注数、项目复刻数、提问回复情况，社区活跃度高则优

12、先考虑。开源基础软件、开源组件。4应评估项目代码提交情况。查看文档。核查开源软件的提交总次数、项目代码合并请求次数，提交次数越多表示开发者活跃程度越高。开源基础软件、开源组件。5应评估贡献者数量。查看文档。核查开源软件近3年每季度贡献者数量变化情况，贡献者数量呈上升趋势则优先考虑。开源基础软件、开源组件。6应评估前10位贡献者所属组织。查看文档。核查前10位贡献者来源是否集中于某1个公司，贡献者来源多则优先考虑。开源基础软件、开源组件。7应评估前3位贡献者代码量占比。查看文档。核杳并统计前3位贡献者的代码量占据前10名总量的比例，比例小则优先考虑。开源基础软件、开源组件。8应评估前10位贡献者

13、国别差异。查看文档。核查并统计前10位贡献者的国别集中度，国别差异大则优先考虑。开源基础软件、开源组件。6.2.4行业支持情况行业支持情况反映开源软件在业界提供专业化服务的情况，行业支持情况评估内容见表4。表4行业支持情况评估内容表序号评估项评估方法示例适用对象1应评估商业支持情况。查看文档。a）核查服务商提供协助运维或托管运维等方面的支持情况，商业支持种类越多则优先考虑。b）服务提供商数量越多则优先考虑。开源基础软件、开源组件。2应评估组织、机构对开源软件的贡献情况。查看文档。除了个人代码贡献者，以组织、机构为责任主体的代码贡献者越多则优先考虑。开源基础软件、开源组件。3应评估说明文档的数量

14、、质量等支持情况。查看文档。a）文档的数量宜多不宜少。b）官方网站中的说明文档、帮助文档文字的数量宜多不宜少。c）文档含有图例、代码示例，简单易懂，与开源软件关联度越强则优先考虑。开源基础软件、开源组件。4应评估文档覆赧范围。查看文档。核查官方网站中的文档覆盖范围，文档覆盖范园越全则优先考虑。开源基础软件、开源组件。5应评估开源软件技术发展路线是否清晰。查看文档。在社区、官方网站等渠道有开发规划等信息公示，开源软件的技术发展路线越清晰则优先考虑。开源基础软件、开源组件。表4行业支持情况评估内容表（续）序号评估项评估方法示例适用对象6应评估是否有中文支持。查看文档。具有中文版本的说明文档且及时更新，相关的开发工具、管理工具和运维工具的中文支持情况越多则优先考虑。开源基础软件、开源组件。6.2.5功能特性不同软件用于解决不同场景的特定问题，其功能特性也不相同，对于功能的评测应结合具体场景进行，功能特性评估内容见表5。表5功能特性评估内容表序号评估项评估方法示例适用对象1应评估该开源软件的核心功能。查看文档。核心功能满足评测场景的功能需求。开源基础软件、开源组件。2应评估该开源软件功能覆前是否全面。查看文档。开源软件的扩展功能丰富，可满足应用需求。开源基础软件、开源组件。6.2.6安全性初步筛选阶段安全性重点考查已暴露的漏洞情况，安全性评估内