02-如何把金融行业标准翻译成开源治理动作
以下场景根据多个银行项目中的共性问题脱敏合并，不对应任何单一机构。
2024 年 6 月，某银行科技管理部接到任务：半年内完成一次开源治理专项自查，结果需支撑监管检查或相关材料报送。
部门负责人翻出三个月前刚修订的《开源软件使用管理办法》，一共 28 页，逐条引用了 JR/T 0290 和 JR/T 0291 的章节编号。看起来该有的都有了。
但自查一开始，问题就暴露了。
安全团队问：“管理办法里写了’应建立开源软件引入评估机制’，但谁来做评估？评估什么？不通过怎么办？”
研发团队问：“制度里写了’使用开源软件需经过审批’，但我们的 CI/CD 流水线一天跑几十次构建，怎么审批？”
采购团队问：“供应商管理制度里提了’要求供应商提供 SBOM’，但合同模板里没有这一条，采购流程也没有这个节点。”
28 页的制度，落到具体执行层面，每个部门都在问同一类问题：这条要求，到底谁来做、怎么做、做到什么程度算合格？
三个标准：各有侧重，又相互重叠
先理清金融行业开源治理相关的三个核心标准，它们各自解决什么问题，彼此之间是什么关系。
JR/T 0290-2024：管怎么建
《金融业开源软件应用管理指南》由中国人民银行于 2024 年 1 月发布，是金融行业开源治理的管理框架标准。
它的核心逻辑是：先搭组织，再定制度，再建流程，最后用工具固化。标准提出了六个管理维度[1]：
| 维度 | 核心内容 |
|---|---|
| 配套组织架构 | 建立决策团队（高层管理者）和管理团队（专项人员、技术人员、安全人员、法务人员） |
| 配套管理规章制度 | 覆盖全生命周期管理，包含应急处置机制 |
| 生命周期流程管理 | 引入 → 使用 → 持续评估 → 退出，形成闭环 |
| 风险管理 | 法律风险（许可证）、安全漏洞风险、供应链风险，识别—记录—处置—评价循环 |
| 存量管理 | 对已在用开源软件做清单和台账管理 |
| 工具化管理 | 借助自动化工具进行成分分析、漏洞扫描和许可证合规检测 |
同时，标准将管理效果划分为三个层次：制度层面（有没有制度和规章）、流程层面（引入、使用、退出有没有闭环）、工具层面（是否实现平台化和自动化）[1]。
JR/T 0291-2024：管怎么评
《金融业开源软件应用评估规范》与 JR/T 0290 同日发布，是管理指南的配套评估标准。
它聚焦于开源软件生命周期的三个关键节点：引入评估、维护评估、退出评估，为每个节点规定了实现要求、评估方法和判定准则[2]。与 JR/T 0290 相比，JR/T 0291 的侧重点是评估如何实施、依据什么判定，但两者对流程、风险和评估要求存在交叉。
GB/T 43698-2024：管整条链
《网络安全技术 软件供应链安全要求》由国家标准化管理委员会于 2024 年 4 月发布，2024 年 11 月实施。它是国家标准，适用范围不限金融行业。
这个标准从完整软件供应链出发，既划分供需双方的责任，也提出组织管理、供应活动管理和风险管理等安全要求[3]。对银行而言，它将开源组件治理从内部研发流程扩展到采购、交付、验收和持续供应关系中。
三份标准的关系不是"一份标准只回答一个问题"，而是从不同角度覆盖同一组治理问题：
| 治理问题 | JR/T 0290 的主要贡献 | JR/T 0291 的主要贡献 | GB/T 43698 的主要贡献 |
|---|---|---|---|
| 组织与责任 | 管理架构和制度体系 | 明确各评估阶段需要的执行与判定活动 | 需方组织管理和供方安全责任 |
| 引入管理 | 全生命周期流程与引入管理 | 引入评估的实现要求、方法和判定准则 | 采购、交付等供应活动的安全要求 |
| 持续风险管理 | 风险识别、记录、处置和评价 | 维护评估与重新评估 | 供应链风险评估与处置 |
| 退出与替代 | 生命周期退出机制 | 退出评估方法和判定 | 供应中断、风险变化等供应链场景的安全控制 |
| 工具与证据 | 工具化管理、存量台账和运营记录 | 评估输入、过程和结果证据 | 跨供需双方的安全信息与验证证据 |
这张表仍然是治理视角的归纳，不是对标准结构的完整复述。实际项目应使用正式版标准逐条建立对照关系，不能仅依据本表开展符合性判定。
制度只有 28 页，为什么执行不下去
回到开篇的场景。那份 28 页的管理办法，问题出在哪里？
不是内容写错了，而是标准原文和制度条文之间，缺了一层"翻译"。
标准提出开源软件应在评估通过后再正式引入，制度却只留下了"应建立开源软件引入评估机制"这类概括性表述。要把它落到执行层面，至少需要回答五个问题：
- 谁来做评估？——安全团队、架构团队、还是专门的治理委员会？
- 评估什么？——安全漏洞、许可证、社区活跃度、架构适配性，每一项的权重和门槛是什么？
- 评估流程是什么？——开发提申请 → 工具自动扫描 → 人工审核 → 审批 → 入库，每一步的时限和责任人是谁？
- 不通过怎么办？——直接拒绝，还是允许附条件使用？例外审批的权限在谁手里？
- 怎么证明做了？——评估记录、审批意见、入库时间戳，存在哪里？审计时怎么调取？
标准回答的是"应当"，制度需要回答的是"谁、做什么、怎么做、怎么证明"。这中间的差距，就是本文所说的"翻译"。
这里的"翻译"不是字面转换，而是要求解释+治理设计：先保留标准原意和要求强度，再结合本行的组织架构、风险偏好和系统重要性，补充标准不会替单一机构规定的角色、时限、门槛和例外机制。
翻译方法：从"要求"到"动作"的五步映射
这套将标准条款翻译为治理动作的方法，来源于我在多个银行开源治理项目中近三年的实践经验。2024 年 JR/T 0290、JR/T 0291 和 GB/T 43698 相继发布后，我将这套方法用于三份标准的落地分析，经过持续迭代，形成了本文的五步映射。核心逻辑是：每一项标准要求，最终都应该落成可执行、可验证的治理动作。
映射模板
| 步骤 | 做什么 | 输出 | 至少需要回答的问题 |
|---|---|---|---|
| 1. 提取要求 | 从标准原文中提取出明确的要求项 | 要求清单 | 适用范围是什么？对哪些系统、组件、采购形态适用？ |
| 2. 分配责任 | 为每项要求指定主责部门和协同部门 | 责任分工表 | 谁执行、谁最终负责、谁提供意见、谁需要知会？ |
| 3. 定义流程 | 将要求转化为具体的流程节点和流转规则 | 流程图/流程说明 | 触发条件是什么？首次引入、版本变更还是定期复审？评估时限是什么？ |
| 4. 确定控制 | 判断哪些节点适合自动化，哪些必须人工审批 | 控制策略表 | 判定标准是什么？什么叫通过、附条件通过、不通过？例外如何授权、有效期多长？ |
| 5. 设定证据 | 为每个控制点定义需要留存的审计证据 | 证据清单 | 谁负责验证控制真实生效？证据保存多久、如何检索？ |
五步走完后，每个要求项最终会形成一张包含 11 个字段的动作卡片：要求来源、适用范围（步骤一）→ 责任（步骤二）→ 触发器、流程（步骤三）→ 控制规则、判定标准、例外机制（步骤四）→ 验收标准、证据、复审周期（步骤五）。五步是工作过程，11 个字段是最终交付物。
示例：翻译"引入评估"相关要求
第一层，锁定标准输入。 JR/T 0290-2024 第 7 章"生命周期流程管理"的 a）"引入管理"明确提出：“明确要求开源软件经评估通过后再正式引入。”[1] 该条款与 JR/T 0291-2024 的引入评估要求，共同构成这张动作卡的标准输入。项目底稿必须继续记录正式版标准的准确条款号、完整原文、要求强度和版本。
第二层，将标准输入规范化为可分配的要求项。 结合两份标准的相关内容，可归纳为：引入前完成评估，并对安全、合规、社区与维护、服务支持等方面做出判断。从这一步开始，后续的角色、时限、门槛和例外条件都属于本行治理设计，不应反过来声称为标准原文。
步骤一：提取要求
| 编号 | 要求项 | 来源 |
|---|---|---|
| R01 | 引入前完成评估 | JR/T 0290-2024 第 7 章 a）引入管理 |
| R02 | 评估维度包含安全性 | JR/T 0290、0291 相关要求（本文归纳） |
| R03 | 评估维度包含合规性（包括许可证） | JR/T 0290、0291 相关要求（本文归纳） |
| R04 | 评估维度包含社区与维护情况 | JR/T 0290、0291 相关要求（本文归纳） |
| R05 | 评估维度包含服务支持情况 | JR/T 0290、0291 相关要求（本文归纳） |
步骤二：分配责任
| 评估维度 | 主责部门 | 协同部门 |
|---|---|---|
| 安全性评估 | 安全团队 | 架构团队 |
| 合规性评估 | 法务/合规团队 | 安全团队 |
| 社区活跃度评估 | 架构团队 | — |
| 商业支持度评估 | 架构团队 | 采购团队 |
| 常规准入审批 | 被授权的审批人/系统责任人 | 安全、架构、法务/合规团队 |
| 高风险或例外事项决策 | 开源治理委员会（或被授权的风险决策机构） | 系统责任人及各专业评估团队 |
关于职责分工中的问责（Accountability）： 专业评估团队对自己的评估意见负责，但不宜代替系统责任人承担全部使用决策后果。常规准入应按制度授权由系统责任人或指定审批人决策；只有限制规则例外、高风险组件、跨部门争议或超出授权范围的事项，才升级到开源治理委员会或其他风险决策机构。制度明确不允许例外的红线规则不进入风险接受流程。完整的 RACI 矩阵（含 R 执行、A 问责、C 咨询、I 知会四类角色）将在下一篇组织设计中展开。
步骤三：定义流程
扫描结果分成三条路径：命中制度明确规定不允许例外的红线规则，直接阻断，但保留误报复核通道；命中风险规则，进入人工评估，结合可利用性、暴露面和系统重要性判断；满足准入规则，进入常规审批。对非红线事项，如果需要附限制条件使用或进行风险调整，再升级到例外审批。每一条例外必须包含适用范围、补偿措施、责任人、到期时间和复审条件。
步骤四：确定控制
| 流程节点 | 控制方式 | 判断依据 |
|---|---|---|
| 自动扫描 | 自动化+人工复核 | 适合规则化执行和批量初筛，但组件、漏洞和许可证识别可能存在误报漏报 |
| 架构评估 | 人工 | 社区活跃度、架构适配性需要专业判断 |
| 准入或例外审批 | 人工 | 涉及使用决策或风险接受，必须由经授权的角色承担责任 |
| 入库 | 自动化 | 审批通过后自动同步到内部制品库 |
步骤五：设定证据
| 控制点 | 证据类型 | 留存要求 |
|---|---|---|
| 自动扫描 | 扫描报告（含时间戳、组件清单、漏洞列表） | 与入库记录关联，保存期限依据本行档案和审计要求确定 |
| 架构评估 | 评估表（含各维度评分、评估人、评估时间） | 电子签批，保存期间防止未经授权的修改和删除 |
| 审批 | 审批记录（含审批人、审批意见、时间戳） | 防篡改、保留版本及操作日志，支持审计导出 |
| 入库 | 入库记录（含组件名称、版本、入库时间、来源） | 自动生成，受控变更，保留完整操作日志 |
五步走完后，R01 不应只停留在"引入前完成评估"这句话上，而应落成一张完整动作卡：
| 字段 | R01 动作卡示例 |
|---|---|
| 要求来源 | JR/T 0290-2024 第 7 章 a）引入管理，并关联 JR/T 0291 引入评估相关条款；项目底稿记录完整原文和版本 |
| 适用范围 | 自研、外包交付和商业软件中首次引入或关键版本变更的开源组件 |
| 责任 | 申请人提交场景信息；安全、架构、法务/合规分别出具意见；系统责任人或授权审批人做准入决策 |
| 触发器 | 首次引入、关键版本变更、使用场景变化，或重大漏洞、许可证变更、停止维护等风险事件 |
| 流程 | 申请→自动扫描→专业评估→准入或例外决策→入库→持续监控 |
| 控制规则 | 红线规则直接阻断；风险规则进入人工评估；已准入组件的普通构建只执行自动门禁 |
| 判定标准 | 通过、附条件通过、不通过；具体门槛按系统等级和本行风险偏好设定 |
| 例外机制 | 仅适用于非红线事项，必须包含适用范围、补偿措施、责任人、到期时间和复审条件 |
| 验收标准 | 所有应评估维度均有结论，责任人完成签批，准入状态与制品库和门禁策略一致 |
| 证据 | 申请记录、扫描报告、专业评估意见、审批或例外记录、入库记录 |
| 复审周期 | 按本行制度定期复审；触发重大风险事件时立即重新评估 |
五步映射与 VCD 框架的对应关系： 上一篇提出了银行开源治理的 VCD 三要素——Visibility（可见性）、Control（控制力）、Decision（决策能力）。五步映射是 VCD 在标准翻译场景中的具体展开：步骤一的适用范围和评估维度定义需要看见哪些对象与信息，步骤五定义这些信息如何转化为可追溯证据，共同支撑 V；步骤三和步骤四通过流程、准入和阻断规则支撑 C；步骤二通过决策授权和问责关系支撑 D。VCD 不是三个彼此独立的模块，这五步也不是——它们是一条从"标准要求了什么"到"谁来做、怎么做、怎么证明"的连续链路。
哪些适合自动化，哪些必须保留人工
这是标准翻译过程中最容易出错的环节。一个常见的误区是：把"流程化"等同于"自动化"，试图把所有标准要求都写进流水线规则。
实际上，标准中的要求可以分成三类，每类适用不同的控制方式。
适合自动执行：数据采集和初筛
| 标准要求 | 自动化方式 | 说明 |
|---|---|---|
| 识别代码中的开源组件 | SCA 工具扫描 | 依赖文件、二进制、容器镜像均可分析，但存在误报漏报，需关注检出率和准确性[4] |
| 匹配已知漏洞 | CVE/NVD 数据库比对 | 匹配不等于漏洞真实可利用，需结合可达性和系统上下文判断 |
| 检测许可证类型 | 许可证数据库匹配 | 可自动识别常见许可证文本，但双许可证、例外条款和特定分发场景仍需人工确认 |
| 生成 SBOM | 工具自动输出 | 格式可自动化（CycloneDX/SPDX），但还需要校验数据字段、更新频率、完整性及与交付制品的一致性[5] |
| 阻断未准入组件构建 | CI/CD 门禁 | 基于白名单/黑名单的二元判断，策略本身需要持续维护 |
核心原则：自动化适合执行规则和采集数据，不天然保证识别结果和规则本身正确。 关键结果仍需要质量校验、误报处理和策略维护。OWASP 的依赖治理指南也将误报处理列为工具能力之一[6]，这与上一篇强调的"工具有了但数据不一定准确"是一致的。
必须人工：涉及专业判断和责任承担
| 标准要求 | 原因 |
|---|---|
| 确定组件在特定系统中的风险等级 | 需要结合系统重要性、网络暴露面、数据敏感度综合判断 |
| 审批风险接受（豁免） | 风险接受是责任决定，不能由工具代劳 |
| 评估社区活跃度和长期维护前景 | 需要理解技术趋势和社区治理结构 |
| 判断许可证在特定业务场景下的合规性 | 需要结合具体许可证条款、修改方式以及内部使用、网络服务或对外分发等场景判断 |
| 决定是否替换或退出 | 涉及业务影响评估、迁移成本和替代方案比较 |
核心原则：凡是需要结合业务上下文、涉及风险承担、或无法用规则穷举的，保留人工判断。
工具能力会继续演进，但制度仍需要把风险接受和责任授权明确到具体角色，不能因为某个判断环节可以自动执行，就隐去决策责任。
需要人工+自动化结合：工具提供数据，人做决策
| 标准要求 | 分工 |
|---|---|
| 漏洞优先级排序 | 工具提供 CVSS 评分、可利用性、影响面数据；人结合系统重要性确定处置优先级 |
| 供应商 SBOM 审核 | 工具比对 SBOM 与实际制品的一致性；人评估供应商交付完整性和可信度 |
| 存量风险梳理 | 工具生成全量清单和风险状态；人制定分阶段处置计划 |
三个标准，一份"翻译对照表"
把三个标准的关键要求整合到一起，可以得到一份从"标准原文"到"治理动作"的对照表。这不是一次性工作，而是需要在项目推进过程中持续维护和更新的活文档。
读表指引： 这张表的核心列是"控制方式"。即使是"工具化管理"，也只有扫描、门禁和记录生成等执行环节可以自动化，工具选型、策略制定、例外处理和效果验证仍需要人工承担。工具是必要条件，但不是充分条件。使用时，请根据本行的组织架构和风险偏好，重点调整"主责部门"和"控制方式"两列。
| 标准 | 关键要求 | 主责部门 | 核心流程 | 控制方式 | 审计证据 |
|---|---|---|---|---|---|
| JR/T 0290 | 建立组织架构 | 科技管理部 | 成立治理委员会，明确决策层和管理层 | 人工 | 任命文件、会议纪要 |
| JR/T 0290 | 制定管理制度 | 科技管理部 | 制定管理办法、准入规范、处置规范 | 人工 | 制度文件、发布记录 |
| JR/T 0290 | 生命周期管理 | 安全+研发 | 引入→使用→评估→退出 | 自动+人工 | 各节点审批和操作记录 |
| JR/T 0290 | 风险管理 | 安全团队 | 识别→记录→处置→评价 | 自动+人工 | 风险台账、处置记录 |
| JR/T 0290 | 存量管理 | 安全+运维 | 盘点→台账→定期复审 | 自动+人工 | 存量清单、复审记录 |
| JR/T 0290 | 工具化管理 | 平台+安全团队 | 自动扫描→结果分析→策略维护→数据质量校验→覆盖度监控 | 人工+自动 | 平台配置、扫描记录、误报处理记录、覆盖度和数据质量报告 |
| JR/T 0291 | 引入评估 | 架构+安全 | 提交→扫描→评估→审批→入库 | 自动+人工 | 评估表、审批记录、入库记录 |
| JR/T 0291 | 维护评估 | 安全团队 | 持续监控→定期评估→触发复审 | 自动+人工 | 监控记录、评估报告 |
| JR/T 0291 | 退出评估 | 架构+安全 | 风险触发→评估→制定退出方案→执行 | 人工 | 退出方案、执行记录 |
| GB/T 43698 | 供方管理 | 采购+安全 | 合同约定→交付验收→持续验证 | 人工+自动 | 合同条款、SBOM、验收记录 |
| GB/T 43698 | 需方组织管理 | 科技管理部 | 建立安全策略→明确责任→培训→审计 | 人工 | 策略文件、培训记录、审计报告 |
| GB/T 43698 | 供应活动安全 | 采购+安全+法务 | 供应商准入→合同安全条款→交付物安全验证 | 人工 | 供应商清单、合同、验证记录 |
翻译过程中最容易踩的三个坑
坑一：把条文摘抄当作制度落地
写完了制度文件，在每一条后面标注"依据 JR/T 0290 第 X 章"，就觉得完成了。回顾本文开篇那家银行的 28 页管理办法——每一条后面都标注了标准章节编号，但安全团队问"谁来做评估"，研发团队问"怎么审批"，采购团队问"合同里没有这一条"。这就是典型的条文摘抄，不是在建立治理机制。
正确做法： 每一项关键制度要求完成后，都配套可执行的落地检查表。以"引入评估"为例：
| 检查项 | 责任部门 | 执行频率 | 检查人 | 控制或升级措施 |
|---|---|---|---|---|
| 新引入或关键版本变更的组件完成安全扫描 | 安全团队 | 每次触发评估 | 科技管理部（定期抽查） | 引入前阻止入库或发布；存量生产组件登记风险、采取补偿措施并限期整改 |
| 许可证与本行策略匹配 | 法务/合规 | 每次触发评估 | 科技管理部（定期抽查） | 引入前阻止准入；存量组件根据使用场景评估后制定整改或退出计划 |
| 架构评估表完成签批 | 架构团队 | 每次触发评估 | 被授权的审批人 | 未完成评估时不得进入下一阶段；需例外使用时进入升级决策 |
一份 4-5 行的检查表，比一段 500 字的制度条文更能驱动执行。制度告诉你该做什么，检查表告诉你没做会怎样。
坑二：把推荐性标准写成强制监管要求
JR/T 0290 和 JR/T 0291 是金融行业推荐性标准，GB/T 43698 是推荐性国家标准。它们本身不当然等同于强制性法律义务，但可以被银行纳入内部制度、合同或项目验收基线，转化为特定范围内的约束。
在制度中，可以写"参考 JR/T 0290 的框架设计本行开源治理体系"，但不应只因为该标准存在，就声称某项做法是外部强制要求。如果银行决定将其内部化为强制控制，应在本行制度中明确适用范围、责任和执行要求。
正确做法： 标准提供框架，银行根据自身风险偏好、系统重要性和资源状况，决定实施的深度和节奏。制度文件中明确区分"可参考标准"和"本行强制要求"。
例如，制度中可以这样表述：
本行参考 JR/T 0290-2024 的管理框架设计开源治理体系及评估机制。以下条款为本行强制执行要求：[逐条列出]。以下条款为本行推荐实践，各团队可根据系统等级和业务场景自行裁量：[逐条列出]。
这样写，既承认了标准作为框架来源的价值，又明确了本行内部真正的约束边界。监管检查时也不会出现"制度引用了推荐性标准但执行不到位"的自我举证风险。
坑三：翻译了流程，但没翻译组织能力
流程图画好了，责任矩阵填好了，控制策略也定好了——但执行流程的人没有经过培训、不知道这件事跟自己的 KPI 有什么关系、也不清楚不执行会触发什么后果。
这比"流程不完善"更容易导致治理失败。一张流程图不会自动产生执行力——它需要对应的组织能力来承载：安全团队会不会用 SCA 工具判断漏洞？架构团队懂不懂开源社区的治理结构和维护趋势？采购团队知不知道 SBOM 长什么样、在合同里怎么约定？
正确做法： 翻译标准的同时，同步启动三件事：一是针对参与部门的专项培训（不是全员科普，而是"你的角色需要做什么"的场景化培训）；二是在相关岗位的考核指标中明确开源治理职责；三是前三次执行由治理委员会或科技管理部派专人盯流程，确保第一轮跑通。翻译的最后一公里，是让人知道"这是我的事"。
可以用一张角色能力表做上线前检查：
| 角色 | 至少需要具备的能力 | 现状评估 | 常见提升措施 |
|---|---|---|---|
| 安全团队 | 解读 SCA 结果，判断误报、可达性和补偿措施 | 具备/部分具备/不具备 | 案例培训、联合复核和误报知识库 |
| 架构团队 | 评估架构适配性、社区治理和长期维护趋势 | 具备/部分具备/不具备 | 评估模板、示例组件试评和专家评审 |
| 采购团队 | 识别 SBOM，将交付、更新和漏洞通报要求写入合同 | 具备/部分具备/不具备 | 合同条款库、验收清单和供应商沟通话术 |
| 法务/合规团队 | 结合许可证条款和具体使用场景形成合规意见 | 具备/部分具备/不具备 | 场景化许可证培训、意见模板和外部专业支持 |
回到开篇：如果那家银行用了这套方法
还记得开篇那家银行吗？28 页制度，三个部门都在问同一类问题。
用五步映射法回头来看，他们的问题是典型的"只做了步骤一（条文摘抄），没做步骤二到五"。如果他们把"引入评估机制"这一条走完五步映射，三个部门的问题不是什么难题：
安全团队问：“谁来做评估？评估什么？”
→ 步骤二（分配责任）已经把安全性评估的主责明确给了安全团队，其他维度则由架构、法务/合规和采购等团队分别承接。安全团队不是只看扫描报告，而是要结合组件可达性、系统暴露面、系统等级和补偿措施形成安全评估意见。
研发团队问：“CI/CD 流水线一天跑几十次构建，怎么审批？”
→ 步骤四（确定控制）已经区分了自动门禁和人工审批。不是每次构建都重新审批，而是在新增组件、关键版本变化、使用场景变化，或出现重大漏洞、许可证变更、停止维护等重要风险事件时触发重新评估。前提是银行已经建立可机器执行的组件准入状态和策略清单；普通构建只根据这些策略执行自动门禁。
采购团队问：“合同模板里没有 SBOM 条款，采购流程没有这个节点。”
→ 这个问题的答案在综合对照表的 GB/T 43698 三行里：供应商 SBOM 需要在采购环节作为合同条款加入，在验收环节验证，在运维阶段持续更新。五步映射把它翻译成了"主责部门（采购+安全）→核心流程（合同约定→交付验收→持续验证）→控制方式（人工+自动）→审计证据（合同条款、SBOM、验收记录）"。采购团队不需要懂开源治理，只需要知道：合同模板要加一条，验收清单要加一项。
三个部门的困惑，本质上不是他们不理解标准，而是标准翻译到一半就停了——停在了条文层面，没有再往前走一步。
这恰恰是本文想说的：一份能执行的管理制度，与一份"看起来该有的都有"的制度之间的差距，就是这一步翻译。
从翻译到落地：下一篇预告
这篇文章把"标准翻译成治理动作"的方法讲清楚了，但翻译出来的动作，最终需要被组织承接。
一个组件引入流程，涉及安全扫描、架构评估、许可证审查和准入决策——这些由安全、架构、法务/合规、系统责任人或被授权的审批人分别承接；高风险、例外或跨部门争议事项再升级到治理委员会或其他风险决策机构。但扩大到整个开源治理体系，至少还要覆盖研发（日常使用和版本管理）、运维（部署和持续监控）、采购（供应商合同和 SBOM 验收）和审计（证据调取和合规检查）。算下来，一个完整的银行级开源治理体系，至少涉及科技管理、架构、安全、研发、运维、采购、法务和审计八个部门。
下一篇，我们来拆这八个部门各自应该承担什么责任？是否需要成立开源治理委员会？什么级别的问题才需要上升到委员会决策？管理办法、准入规范、风险处置规范这些制度如何分层？
下一篇见。
数据来源
- 中国人民银行, JR/T 0290-2024《金融业开源软件应用管理指南》, 2024. https://cfstc.pbc.gov.cn/bzgk/detail/?bzId=2060&id=0
- 中国人民银行, JR/T 0291-2024《金融业开源软件应用评估规范》, 2024. https://std.samr.gov.cn/hb/search/stdHBDetailedCNF?id=0FD7E9C4C5036738E06397BE0A0A217C
- 国家标准化管理委员会, GB/T 43698-2024《网络安全技术 软件供应链安全要求》, 2024. https://std.samr.gov.cn/gb/search/gbDetailed?id=173829859D2E1AA5E06397BE0A0AA311
- National Institute of Standards and Technology, NISTIR 8397, Guidelines on Minimum Standards for Developer Verification of Software, 2021. https://doi.org/10.6028/NIST.IR.8397
- National Telecommunications and Information Administration, The Minimum Elements for a Software Bill of Materials (SBOM), 2021. https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom
- OWASP Cheat Sheet Series, Vulnerable Dependency Management Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html
扫一扫
206
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
