【开源治理·银行篇】03-银行级开源治理体系应该如何设计系列「金融开源治理实战」第一季 · 银行业以下场景根据多个银行项目中的共性问题脱敏合并不对应任何单一机构。某银行的开源治理平台上线后安全团队很快遇到了一个没有写进验收报告的问题。平台每天都能扫描出组件、漏洞和许可证风险也能自动生成处置工单。可工单流转到人工判断环节后队列开始积压安全团队能判断漏洞风险却不能决定核心系统是否立即升级。架构团队能判断替代方案却不能接受业务连续性风险。法务团队能解释许可证条款却不了解组件实际用于内部系统、对外分发还是网络服务。研发团队负责整改却认为组件来自统一技术栈不应由单个项目独自承担替换成本。为了推动问题项目组把争议事项全部提交到开源治理委员会。结果委员会的会议逐渐变成了“组件审批会”普通版本升级要讨论扫描误报要讨论已经有标准答案的许可证也要讨论。会议一度从每月一次增加到每周两次真正需要管理层权衡的高风险例外反而被淹没在日常工单里。平台没有失效流程图也没有画错。真正缺少的是一套能够回答下面三个问题的治理体系哪个角色有权作出什么决定哪类事项应该在日常流程中解决哪类事项必须升级规则上线以后谁负责持续维护、检查和改进项目走到这一步需要补的已经不是又一个平台功能而是组织、制度、流程、平台和运营之间的连接。动作卡写完以后谁来接上一篇提出了从金融行业标准到治理动作的五步映射提取要求、分配责任、定义流程、确定控制、设定证据。这种从“治理动作”到“组织承接”的延伸并非额外增加一套要求。2021 年五部门《意见》鼓励金融机构建立由科技、法务、采购等部门参与的协调机制并建立覆盖开源技术全生命周期的管理制度JR/T 0290-2024 则进一步给出了组织、制度、生命周期、风险、存量和工具化管理框架[1][2]。但动作卡写出来之后还要有人真正承接五步映射的输出本篇需要回答的问题责任由哪个部门执行谁承担最终责任谁提供专业意见流程日常事项在哪一层解决什么条件触发升级控制哪些规则由平台执行谁维护规则和数据质量证据谁验证证据完整谁能够独立检查控制是否有效复审谁发起定期复审谁推动存量风险按期闭环这些文件最终要解决两件具体的事跨部门协作需要明确的权责结构生命周期活动需要稳定的制度和运行机制。是否新设部门、是否采购系统应在这两件事之后考虑。先看全貌银行级治理体系的五个部分一套能够运行的银行级开源治理体系至少包括五个彼此咬合的部分组成部分解决的问题典型产出组织谁决策、谁统筹、谁执行、谁监督决策授权、工作组、RACI 矩阵制度哪些要求在本行内部具有约束力管理办法、专项规范、操作细则、策略基线流程治理动作在什么条件下被触发和流转准入、维护、风险处置、例外、退出流程平台哪些规则和记录可以被稳定执行与留存SCA、制品库、流水线门禁、台账、工单和证据关联运营规则和数据如何持续保持有效策略维护、风险跟踪、数据质量、指标和定期复盘我在项目中更关心的是这五部分之间有没有断点。常见的断法大致有三种只有组织和制度没有平台执行会依赖人工催办规模一大就容易走样。只有流程和平台没有清晰授权工具可以发工单却无法替银行作出风险决定。只有建设没有运营白名单、漏洞策略、许可证规则和责任人信息会逐渐失真。平台只是治理体系的一部分。它能让控制稳定执行但决定仍要由组织中的具体角色承担等项目进入运行期又需要运营机制持续校准规则和数据。组织怎么搭决策、统筹、执行三层分开银行不一定需要新设一个独立的“开源治理部”。做组织设计时我通常先追问三件事日常工单由谁关闭专业分歧由谁协调超出授权的风险由谁拍板。在现有科技治理和风险管理架构中这三类责任可以分成决策、统筹和执行三层。第一层决策层——只处理需要权衡和授权的事项决策层可以是现有科技管理委员会、科技风险委员会也可以是在其下设置的开源治理专题机制。名称不是关键关键是它拥有清晰、有限的决策权限。决策层主要负责审定开源治理总体策略、风险偏好和年度目标。批准制度明确允许例外的重大风险接受事项。决定跨部门无法协调的组件替换、退出和资源投入。审议重大风险事件、长期逾期问题和治理效果报告。它不应该负责逐条查看扫描报告也不应该审批所有组件。委员会的价值是处理规则无法自动回答的权衡不是代替工作组执行日常流程。第二层统筹层——让跨部门流程真正跑起来统筹层通常由科技管理部门牵头可以设常设工作组、治理办公室或虚拟协调机制。它承担的是“流程所有者”职责维护规则、检查积压、召集协同和推动改进日常事项不再增加一道审批。统筹层主要负责维护制度、流程、角色和授权边界。协调架构、安全、研发、运维、采购、法务和审计接口。组织策略评审、存量治理和跨系统风险跟踪。汇总运营指标向决策层报告重大问题。推动培训、抽查、整改和年度复盘。如果没有这一层跨部门事项往往只能依赖项目经理临时拉群协调人员一换流程也随之中断。第三层执行层——把职责嵌入原有岗位执行层分布在八类现有职能中实际上是一张角色网络科技管理负责体系统筹和流程所有权。架构负责技术选型、适配性、社区健康度和替代路线。安全负责成分识别、漏洞判断、安全基线和持续监测。研发及系统责任人负责如实申报、使用决策、整改和版本维护。运维负责生产版本映射、部署控制、监控和退出验证。采购负责把供应商要求写入准入、合同、交付和验收环节。法务/合规负责结合许可证条款和真实使用场景提供专业意见。审计负责独立评价设计是否合理、执行是否真实、证据是否完整。这里有一个容易混淆的边界安全、架构和法务对专业意见负责但系统责任人不能因此把使用决策完全转交给专业团队。专业团队回答“风险是什么”被授权的系统责任人回答“在什么条件下使用并承担什么责任”超出授权边界时再升级到决策层。是否需要成立开源治理委员会是否需要专门成立委员会要看现有治理结构能不能提供三种能力跨部门协调、风险授权和资源决策。三种可选模式模式适用情形组织方式主要风险现有委员会承接已有成熟的科技风险或架构治理机制将开源议题纳入现有议程由科技管理部门设置工作组开源事项可能被其他议题挤压需要固定报告机制专题委员会常设工作组系统多、供应链复杂、跨部门争议频繁委员会负责授权工作组负责日常统筹委员会容易越权处理日常审批虚拟协调机制规模较小、治理对象相对集中明确牵头人和各部门接口人重大事项进入现有决策机制依赖关键个人人员变动时容易失去连续性无论采用哪种模式都应先定义升级条件再决定会议机制。什么问题才需要升级建议把事项分成三层决策层级典型事项处理方式日常执行已准入组件的普通构建、规则明确的扫描结果、标准版本升级平台自动执行或专业团队按授权处理专业会签新组件引入、非标准技术栈、许可证场景判断、需补偿措施的风险安全、架构、法务等按流程形成意见由授权审批人决策升级决策高风险例外、核心系统长期无法整改、跨部门责任争议、重大退出或资源投入治理委员会或现有授权机构决策并留痕另外有两类事项不应混入例外审批制度明确不允许例外的红线事项。它们应直接阻断如果怀疑误报进入专业复核而不是风险接受。信息不完整的申请。缺少使用场景、组件版本、影响系统或补偿措施时应退回补充不应通过升级会议替申请人完成论证。一个实用判断是如果同一类问题每周都要提交委员会它大概率已经不是“例外”而是制度、授权或平台规则没有设计好。八部门 RACI每项活动只保留一个最终责任人RACI 用四类角色描述一项工作的权责RResponsible执行、AAccountable最终负责、CConsulted提供意见、IInformed知会。RACI 最常见的错误是一张表里到处都是“A”。如果多个部门都对同一件事“最终负责”实际发生问题时往往就没有人真正负责。建议每项关键活动只设置一个 AR 可以有多个C 和 I 根据需要设置。下面是一份银行级开源治理的基础矩阵。它不是固定答案但可以作为本行分工设计的起点关键活动A 最终负责R 执行C 提供意见I 知会治理策略、制度和年度目标科技管理科技管理工作组架构、安全、研发、运维、采购、法务、审计各系统责任人组件技术选型与推荐技术栈架构架构、研发安全、运维、法务科技管理、采购新组件引入与常规准入制度授权的系统责任人研发、架构、安全法务、运维、采购科技管理漏洞监测与安全风险定级安全安全架构、研发、运维科技管理、系统责任人漏洞整改与版本升级系统责任人研发、运维安全、架构、供应商科技管理许可证合规意见法务/合规法务/合规研发、架构、采购安全、科技管理供应商开源要求与 SBOM 交付采购采购、供应商管理角色安全、法务、架构、运维科技管理、系统责任人生产版本、制品与系统映射运维运维、研发安全、架构科技管理、系统责任人非红线高风险例外授权风险决策机构科技管理工作组、申请部门安全、架构、法务、运维、采购审计及相关责任人单一系统的组件限制、替换与退出系统责任人研发、运维架构、安全、采购、法务科技管理、审计重大跨系统替换或退出授权风险决策机构科技管理工作组、相关系统责任人架构、安全、运维、采购、法务审计及相关部门运营指标、策略维护和存量跟踪科技管理科技管理工作组、安全、平台运营角色架构、研发、运维、采购、法务决策层、审计独立审计与控制有效性评价审计审计科技管理及各专业团队决策层这张表还有三个使用前提“系统责任人”必须落实到具体岗位或具体人员不能只写“业务部门”或“项目组”。审计不参与日常准入审批和风险接受避免既设计控制、又执行控制、最后再评价自己。供应商可以执行合同约定的修复和交付义务但银行内部的风险判断与管理责任不能外包。在国内标准中GB/T 43698-2024 从供需双方视角提出软件供应链安全中的组织管理、供应活动和风险管理要求[3]。落实到 RACI 中就是供应商可以承担交付、通报和修复等合同责任银行仍需要保留供应商准入、交付验证、风险接受和持续监督的内部责任链。国际标准中也有类似要求。NIST SSDF 将“为安全开发相关人员定义并定期评审角色责任”和“提供基于角色的培训”列为组织准备的重要任务[4]。这说明 RACI 不是一次性项目文档组织调整、流程变化或重大事件复盘后都需要重新校准。制度怎么分层不要把所有要求塞进一份管理办法很多银行的第一版开源制度会走向两个极端要么只有几页原则执行团队找不到具体规则要么把角色、流程、阈值、表单和工具字段全部写进一份管理办法任何策略调整都要重新走制度修订流程。更稳妥的做法是把制度分成四层层级解决的问题建议文件主要责任部门更新触发器L1 管理办法为什么管、管什么、谁负责、基本原则是什么开源软件应用管理办法科技管理监管、标准、组织架构或风险偏好重大变化L2 专项规范各类治理活动必须满足什么要求组件准入规范、生命周期与风险处置规范、供应商开源要求、证据与审计规范科技管理牵头各专业部门共建管理范围、责任边界或核心流程变化L3 操作规程日常工作怎么流转、使用什么表单、在多长时间内完成引入评估规程、漏洞处置规程、例外审批规程、退出操作规程对应流程所有者流程、平台或岗位调整L4 策略基线当前机器和人工判断依据是什么组件状态清单、漏洞门槛、许可证策略、例外期限、系统分级与 SLA架构、安全、法务等专业团队风险情报、组件状态和运营效果变化四层制度的关键在于把稳定内容与高频变化内容分开管理文件数量反而是次要的。组织原则、适用范围和问责关系相对稳定放在管理办法中。流程时限、表单字段和系统操作会随平台调整放在操作规程中。白名单、漏洞阈值和许可证策略变化最频繁应以受控策略基线维护保留版本、审批和生效记录。一份最小制度体系清单银行启动第一轮建设时不需要一次写出十几份文件。可以先形成一个能运行的最小组合最小文件至少应包含的内容可验证证据开源软件应用管理办法适用范围、组织架构、基本职责、生命周期原则、例外与问责制度发布记录、职责授权组件准入与评估规范触发条件、评估维度、状态分类、审批权限、复审机制评估表、审批记录、准入状态风险处置与退出规范风险分级、处置方式、SLA、补偿措施、替换和退出条件风险工单、整改证据、退出记录供应商开源要求合同条款、SBOM、漏洞通报、升级支持、停止维护责任合同、SBOM、验收和通报记录例外管理规程适用范围、禁止例外项、审批层级、有效期、复审和到期处理例外申请、审批、补偿措施和到期记录运营与证据规程台账、策略维护、数据质量、指标、抽查、报告和证据保存运营报告、变更记录、抽查报告其中“组件准入规范”只在本篇界定其制度位置不展开五类准入状态和评分规则这些是下一篇的主题。这样可以避免组织设计和具体准入策略混在一起。平台怎么承接承接流程而不是重新发明流程平台建设最常见的倒置是先根据产品功能设计流程再让制度去解释为什么要这么做。正确顺序应该是制度确定责任和边界 → 流程定义触发条件与决策路径 → 平台固化可自动执行的控制 → 运营校验数据和规则是否持续有效平台至少需要承接五类对象平台对象需要解决的关键问题责任接口组件与版本组件是什么、来自哪里、当前是什么治理状态架构、安全制品与系统组件存在于哪个制品、环境、系统和业务中研发、运维风险与规则命中了什么规则、是否真实影响、应如何处置安全、法务、架构决策与责任谁申请、谁评估、谁批准、谁承诺整改系统责任人、授权审批人证据与状态扫描、审批、入库、发布、整改和复审能否关联科技管理、审计这意味着SCA、制品库、DevOps 流水线、IT 服务管理工单、CMDB 或应用资产台账不应各自形成孤岛。本文不要求它们必须由一个产品实现但至少要建立稳定的标识和数据关系让一个组件风险能够追溯到真实制品、生产系统、责任人和处置记录。同时平台不能替代三类人工责任不能替法务判断许可证在具体业务场景中的影响。不能替系统责任人接受稳定性和业务连续性风险。不能替授权机构决定重大例外和跨系统退出投入。平台可以证明谁在什么时候做了什么不能替这个人承担为什么这样决定。运营怎么接上验收完成只是体系开始运行银行级开源治理上线后至少要持续运行六类工作策略维护更新组件状态、漏洞门槛、许可证规则、系统分级和例外条件。数据质量检查扫描覆盖率、组件识别准确性、系统映射完整性和责任人有效性。存量跟踪跟踪高风险组件、停止维护组件、逾期例外和长期未整改事项。流程抽查验证准入、审批、入库、发布和整改记录是否真实一致。能力维护对不同角色开展场景化培训处理人员变动和职责交接。指标复盘分析风险暴露时间、闭环效率、绕过行为和审计准备成本。运营团队不一定是一个独立部门可以由科技管理工作组和平台运营、安全、架构等角色共同组成。但每一类运营工作都必须明确负责人、频率、输入、输出和升级条件。建议建立三个固定节奏节奏主要内容典型输出日常/每周新增风险、阻断、误报、到期例外和紧急问题工单、复核结论、升级事项每月/每季度存量风险、策略效果、数据质量、部门执行情况运营报告、策略调整、整改清单每年或重大变化后制度、授权、流程、工具和培训有效性年度评审、制度修订、能力提升计划哪些指标适合管理层、如何计算治理 ROI将在第 10 篇单独展开。本篇只强调一个原则没有固定运营节奏的治理体系本质上仍然是一次性项目。三种常见的失灵方式错误一把安全团队变成所有风险的最终责任人安全团队适合负责风险识别、技术判断和安全规则却无法独自决定核心系统是否升级、供应商是否更换、许可证场景是否可接受。把所有 A 都填给安全团队结果通常是安全团队不断催办真正拥有资源和业务决定权的责任人却退出了决策链。责任应当重新放回决策链专业团队对意见负责系统责任人对使用和整改负责重大例外由授权机构负责。错误二让委员会处理所有日常审批委员会一旦被普通组件申请占满就无法聚焦风险偏好、重大例外和跨部门资源冲突。常规事项应由准入状态、授权阈值和专业会签解决委员会只处理超出规则和授权边界的问题。错误三制度归科技管理规则归工具厂商平台上线初期银行可能直接沿用工具默认漏洞等级、许可证分类和阻断策略。工具厂商可以提供知识和实现能力但不能替银行决定风险偏好。每一条生产规则都要能对应本行制度依据、策略负责人、审批记录、生效范围和复审时间。厂商维护工具银行拥有规则。资源有限时先把这十件事跑通如果暂时没有条件建设完整体系可以先确保下面十项同时存在一个有正式授权的治理牵头部门。一个能够处理重大例外和资源冲突的决策机制。一张覆盖八类职能的 RACI 矩阵。一套管理办法与最小专项规范。一条能够跑通的组件准入流程。一条能够跑通的风险处置和到期升级流程。一套可机器执行、可版本追踪的策略基线。一个关联组件、制品、系统、责任人和工单的基础台账。一个固定的月度运营和季度复盘节奏。一套能够证明流程真实执行的最小证据包。它们共同构成的是一个闭环有人制定规则 → 有人执行和决策 → 平台稳定落实控制 → 运营发现偏差 → 决策层调整规则与资源这个闭环的规模可以逐步扩大但不能只交付其中一个环节。只有平台没有责任工单不会自动变成决定只有制度没有运营规则不会自动保持正确。工单为什么会积压开篇那家银行已经具备扫描能力工单仍然积压是因为本应分层处理的事项被放进了同一个队列。如果按本文的体系重新设计扫描误报由安全团队按专业流程复核不上委员会。已准入组件的常规升级由系统责任人在授权范围内决策不上委员会。许可证问题由法务结合使用场景出具意见信息不足先退回补充不上委员会。只有高风险例外、长期无法整改、跨部门争议和重大退出投入才进入授权决策机构。科技管理工作组持续检查积压、到期例外和策略有效性推动规则从“依赖开会”变成“可重复执行”。这样委员会讨论的数量会减少但每次讨论的管理价值会提高平台产生的工单不再只是风险列表而是进入了明确的责任和授权结构。组织设计的验收标准也应回到处置结果每一类问题能否在正确的层级由有权负责的人作出可追溯的决定。角色、会议和文件的数量不能作为成效证明。接下来先管组件入口组织、制度、流程、平台和运营框架搭好之后第一个需要落下去的具体控制是组件准入。但“准入”并不等于维护一张简单白名单。银行需要回答什么组件可以推荐使用什么可以一般使用什么必须逐次审批什么只能限时使用什么应该明确禁止组件本身的风险和系统重要性又该如何共同决定管控强度第 04 篇进入第一个具体控制银行如何建立组件准入、分类分级和推荐技术栈让大部分常规选型在组件进入项目前就有稳定答案。数据来源中国人民银行办公厅、中央网信办秘书局、工业和信息化部办公厅、中国银保监会办公厅、中国证监会办公厅《关于规范金融业开源技术应用与发展的意见》2021。https://www.cac.gov.cn/2021-10/27/c_1636928705274546.htm中国人民银行JR/T 0290-2024《金融业开源软件应用 管理指南》2024。https://cfstc.pbc.gov.cn/bzgk/detail/?bzId2060id0国家标准化管理委员会GB/T 43698-2024《网络安全技术 软件供应链安全要求》2024。https://std.samr.gov.cn/gb/search/gbDetailed?id173829859D2E1AA5E06397BE0A0AA311National Institute of Standards and Technology,Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, NIST SP 800-218, 2022. https://csrc.nist.gov/pubs/sp/800/218/final