一、项目背景

项目立项的原因和背景：

随着金融行业数字化转型的深入推进，开源技术已成为银行信息系统建设的重要技术底座。开源软件在降低研发成本、加速业务创新的同时，也带来了安全漏洞、许可证合规、供应链来源不可控、版本停止维护等一系列风险。中国人民银行发布的《金融业开源软件应用管理指南》（JR/T 0290—2024）明确提出，金融机构应通过构建内部管理平台及自动化扫描工具，对开源软件实施工具化、全生命周期管理。国家信创战略和网络安全、数据安全相关法规也对金融机构技术自主可控和软件供应链安全提出了更高要求。

北京农商银行作为立足首都、服务三农与城乡的农村金融机构，信息系统体量大、研发团队多、开源组件使用广泛。在行内原有管理模式下，开源资产以人工台账和线下审批为主，存在台账更新滞后、风险识别不及时、使用范围不清晰、整改成本高等问题。为满足监管合规要求、保障信息系统安全稳定运行，我行于2025年9月启动全行统一开源治理平台建设，并于2026年4月正式投产上线。

二、项目方案

1.总体架构设计

平台采用分层架构，划分为接入层、负载层、网关层、服务层、基础设施层和物理层。接入层提供统一Web访问入口，支持行内研发人员、安全合规人员、架构管理人员按角色访问；负载层与网关层承担请求分发、权限校验和路由控制；服务层提供纳管清单、技术名单、资产台账、风险预警、流程审批、公共知识库及系统管理等功能；基础设施层提供数据库、缓存、消息队列和对象存储能力；物理层基于信创X86服务器和麒麟操作系统构建。平台通过标准接口与行内GitLab代码仓库、SCA扫描工具、Nexus制品库及DevOps平台协同，形成贯穿研发过程的开源治理体系。

（图1：开源治理平台总体架构图）

2.业务功能设计

分类分级纳管机制。区分开源组件、开源基础软件和开源工具三类对象，根据使用范围、重要程度及风险情况实施差异化管理策略。

线上审批流程。将开源引入、例外使用、分级调整、停用退出等管理事项纳入线上审批，按照业务类型配置架构、安全、法务及相关处室等审批角色，实现审批留痕、责任到人。

（3）统一开源资产台账。通过SCA扫描结果、制品使用记录、批量导入和人工补录等方式归集资产，关联软件名称、版本、依赖关系、使用系统、所属部门及责任人，支持自动盘点与人工补充相结合的台账维护方式。

（4）风险预警与名单管控。持续识别安全漏洞、许可证合规及版本停止维护等风险，结合黑名单、限制级名单、停用名单等实施分级管控；当组件出现新增漏洞或风险状态变化时，可依据资产关联关系快速定位影响范围。

（5）公共知识库。集中管理制度文件、申请模板、操作手册、开源使用知识及典型案例，为全行研发人员提供统一的知识检索和学习入口。

（图2：业务功能架构图）

3.技术集成设计

平台以软件成分分析（SCA）工具为扫描引擎，对源码、制品及软件物料清单（SBOM）进行组件识别，获取组件构成、漏洞及许可证信息。与GitLab代码仓库对接，按授权获取源码并支持增量扫描；与Nexus制品库对接，同步组件审批及名单结论，在组件下载环节执行准入校验，并回收下载、使用记录更新资产台账；与DevOps平台对接，在构建、提测和发布环节调用治理结论，对不符合规则的组件实施拦截，对符合例外申请条件的使用需求按流程审批。通过制品库代理衔接金融业开源技术服务平台可信中心仓与行内组件库，将来源管理、入库审批和使用管控相互衔接。

（图3：技术集成架构图）

4.部署与实施设计

项目采用成熟商用产品本地化部署与行内系统集成的建设方式。服务端适配信创X86服务器和麒麟操作系统，采用OceanBase存储结构化业务数据，使用BCS提供缓存服务，使用RustFS对象存储管理软件安装包、扫描报告及知识库文件。业务应用、台账及扫描等服务采用Docker和Docker Compose进行容器化部署，便于统一运行环境、快速扩缩容和版本回退。实施过程中，先完成制度匹配、存量资产盘点、权限规划和接口规范制定，再开展平台配置、集成联调及测试验证，按照“先试点3个开发处室、再逐步向全行推广”的路径推进应用。

四、创新点

项目在建设或推广应用等方面的创新点：

1.开源软件台账电子化，实现开源软件台账在引入、使用、持续评估和退出环节的自动更新。

2.在开源软件全生命周期管理过程中，实现各环节的风险管控。引入环节设置基本门槛：开源治理平台自动判断拟引入的开源软件是否满足以下要求：无高危及以上安全漏洞、不涉及开源软件黑名单、不涉及许可证黑名单中全场景禁用许可证、不涉及停用退出清单。

使用环节严格风险管控：除基本门槛条件需满足外，互联网和重要系统不可新增中危及以上安全漏洞的开源组件；不可新增使用行内许可证黑名单中许可证所有许可证、以及版本风险的开源组件。

说明：

（1）开源软件黑名单：收录监管通报中涉及的有严重影响的开源软件。

（2）许可证黑名单：收录行内禁用许可证（分为全场景禁用和限定场景禁用）涉及的开源软件。

（3）停用退出清单：涉及全场景禁用许可证、版本风险以及根据持续评估或存量治理评估结果计划退出的开源软件。

3.内网连接制品库，外网连接可信仓，形成标准化安全链路。

首先开源治理平台对行内使用到的软件全面纳管，按照风险级别进行标记；其次开源治理平台连接行内统一内网制品库，在开发人员在拉取未纳管组件时进行管控；外网连接金融业开源技术服务平台可信中心仓，形成标准化安全链路

五、技术实现特点及优势

1.制度规则与研发流程协同，实现治理要求自动执行。平台将分类分级、引入审批、风险限制及退出管理等制度要求转化为可配置规则，并将治理结论嵌入组件下载和研发流水线。开发人员获取组件、提交构建或发起提测时，即可执行相应的合规校验，减少对人工检查和线下沟通的依赖。

2.扫描识别与资产台账联动，提高资产信息完整性和可追溯性。平台结合SCA扫描结果和制品库使用记录，归集组件名称、版本、依赖关系、漏洞及许可证等信息，并与信息系统、部门及责任人关联。当组件出现新增漏洞或风险状态变化时，可依据资产关联关系定位相关使用范围，为风险排查和后续处置提供依据。

3.分类分级与例外审批结合，兼顾风险控制和研发需求。平台围绕开源组件、基础软件和工具设置差异化管理流程，通过黑名单、限制级名单、停用名单及许可证规则控制使用边界。对符合制度规定的特殊使用场景，通过例外申请、多角色审批和操作留痕明确使用条件与责任。

4.分层设计与接口集成，提高系统维护和扩展能力。平台将用户交互、业务处理、基础服务和数据存储分层组织，各业务模块通过接口协同，便于独立维护和功能扩展。通过标准接口复用行内GitLab、Nexus、SCA和DevOps等既有能力，减少重复建设。

5.异步处理与资源隔离，改善集中扫描场景下的服务稳定性。针对扫描任务耗时较长、研发高峰任务集中的特点，平台设计采用异步任务队列、并发控制和排队机制，将扫描执行与日常查询、审批操作分开处理。结合独立扫描资源、热点数据缓存、接口超时控制及失败重试等措施，降低批量扫描和外部接口异常对核心管理功能的影响。

6.信创环境适配与内网部署，满足行内运行管理需求。平台适配麒麟操作系统、OceanBase数据库及信创终端环境，支持在行内既有基础设施上部署运行。治理平台及扫描引擎部署于行内网络，通过授权访问、角色权限控制和审计留痕管理源码读取、资产查询及审批操作，支持开源治理数据的集中管理与使用追溯。

7.自主研发与知识沉淀并重。平台以成熟商用产品为基础，我行结合自身管理制度、组织架构和研发流程，自主完成了治理规则模型、审批流程、名单管理体系、资产台账模型、公共知识库及与行内系统的集成适配等核心设计工作；同步沉淀开源治理制度规范、操作手册和典型案例，为后续自主运营和持续优化奠定基础。

六、项目过程管理

项目于2025年9月明确建设需求，投产节点为2026年4月，从需求明确至投产上线总体跨度约7个月。项目按照需求分析、方案设计、部署集成、测试验证及投产推广等阶段组织实施。

1.需求分析与立项准备阶段（2025年9月）。围绕行内开源管理制度，开展需求调研、制度匹配分析、产品原型设计和技术可行性论证，明确开发、测试、运维、安全合规及架构管理等角色的使用需求。

2.方案设计与实施准备阶段（2025年9月至10月）。开展总体架构、业务功能、数据结构、权限体系和系统接口设计，明确分类分级、引入审批、风险预警、台账维护及退出管理规则。同步开展存量开源资产初步盘点，落实基础软硬件资源和网络访问条件。

3.平台部署与集成联调阶段（2025年11月至2026年1月）。依据设计方案完成运行环境搭建、产品部署、业务规则配置及审批流程配置，开展SCA、Nexus、GitLab和DevOps等系统的接口集成与联调，重点验证扫描任务下发、扫描结果回写、名单同步及研发准入校验等关键链路。

4.测试验证与投产准备阶段（2026年2月至3月）。投产前围绕开源资产全生命周期开展功能测试，优先验证核心流程和高风险场景，覆盖引入审批、黑名单及许可证拦截、例外申请、状态变更和组件退出等功能。针对批量导入导出、组合查询、流程流转及连续操作开展基础性能和稳定性校验，并完成问题修复与回归验证，落实投产部署及程序备份等准备工作。

5.投产上线与推广阶段（2026年4月）。部署上线开源资产纳管、生命周期审批、风险预警、台账管理及工具集成等核心功能。按照先试点3个开发处室、再向全行推广的安排分步推进，结合试点反馈完善流程配置和操作指引，逐步扩大项目接入与资产纳管范围。

七、运营情况

1.推广应用

平台于2026年2月3日启动试运行，覆盖3个试点开发处室，运行情况良好；2026年4月15日正式运行并逐步向全行研发部门推广。截至目前，平台用户量达794人，已纳入全行开源治理常态化管理流程，成为研发人员引入、使用开源软件的统一入口。

2.系统运行情况

（1）性能表现：平台日均处理构建任务272次，系统并发处理能力为10个并发构建任务；核心管理功能响应时间满足日常使用需求，批量导入、导出及组合查询等操作运行稳定。

（2）稳定性与可靠性：系统稳定运行率达99.90%，试运行及正式运行期间未发生重大故障或数据异常。通过异步任务队列、资源隔离、失败重试及热点缓存等机制，有效保障了研发高峰期的服务可用性。

（3）安全合规：平台按照信息安全等级保护2.0要求进行安全设计与测评，依托CMMI 3级项目管理能力规范研发过程，关键操作均留痕审计，满足银行内控与合规要求。

（4）治理成效数据：截至目前，平台已实现开源组件统一纳管【待补充：已纳管开源组件数量】个，覆盖信息系统【待补充：覆盖信息系统数量】套；累计识别高危漏洞【待补充：累计识别高危漏洞数量】个、许可证合规风险【待补充：许可证合规风险数量】项，拦截不符合规则的引入申请【待补充：拦截次数】次。

八、项目成效

经济效益或社会效益

1.经济效益

（1）提升管理效率，降低人工成本。开源资产台账由传统人工统计、月度/季度更新转变为随研发流程实时更新，显著减少人工盘点和线下沟通成本；审批流程线上化后，引入申请、例外申请等审批周期明显缩短。

（2）前置风险拦截，降低整改成本。在引入环节自动执行黑名单、许可证黑名单、高危漏洞等准入校验，避免“先使用、后整改”带来的高额返工成本；漏洞、许可证等风险一旦识别，可快速定位受影响系统和责任人，缩短风险处置时间。

（3）复用现有研发能力，减少重复建设。平台通过标准接口复用行内GitLab、Nexus、SCA、DevOps等既有系统和工具，避免单独建设代码仓库、制品库和流水线，降低整体建设和维护投入。

（4）量化成本节约，提升投入产出比。以2026年运行数据测算，平台上线后预计每年可节约人工盘点、线下审批及风险整改成本约【待补充：预计节约金额（万元）】万元；通过前置风险拦截，可减少因开源组件问题导致的系统返工和停机损失。

2.社会效益

（1）提升金融服务安全性和稳定性。通过对开源软件供应链风险的识别与管控，降低因开源组件漏洞、许可证纠纷或版本停维导致的系统安全风险，保障客户信息安全和业务连续性。

（2）形成农村金融机构开源治理可复制范式。平台基于信创环境本地化部署，沉淀了制度规范、分类分级规则、审批流程、技术集成方案和运营经验，可为规模相近、技术基础相似的农村金融机构提供参考。

（3）助力国家信创战略和金融科技安全发展。平台在麒麟操作系统、OceanBase数据库等信创环境中稳定运行，推动开源治理与自主可控技术体系的深度融合，为银行业开源软件安全应用贡献实践案例。

九、经验总结

项目建设、推广经验总结

1.制度先行、流程配套、工具落地。开源治理不能只靠工具，必须先将管理制度、职责分工、审批规则梳理清楚，再通过平台将制度要求嵌入研发流程，才能实现“治理要求可执行、执行结果可审计”。

2.存量治理与增量管控并重。由于开源组件使用历史长、情况复杂，历史台账梳理难度大。建议对存量组件先全盘纳管、统一打标，再逐步开展风险治理；对新增组件则严格执行准入校验，确保“增量干净”。

3.工具集成比功能堆砌更重要。开源治理平台的价值在于与代码仓库、制品库、DevOps平台等研发工具链形成数据与流程联动，避免成为孤立的信息系统。

4.持续运营与迭代优化。开源组件和漏洞信息持续变化，平台上线后需建立常态化运营机制，定期更新漏洞库、许可证库和名单库，根据监管要求和行内实践持续优化规则配置。

5.形成可推广的建设路径。本项目按照“制度匹配—资产盘点—平台部署—集成联调—试点推广—全面推广”的路径推进，步骤清晰、风险可控，可为同业机构提供借鉴。