【开源治理·银行篇】04-组件准入与分类分级：白名单和推荐技术栈怎么建？

【开源治理·银行篇】04-组件准入与分类分级：白名单和推荐技术栈怎么建？

系列「金融开源治理实战」第一季 · 银行业

以下场景根据多个银行项目中的共性问题脱敏合并，不对应任何单一机构。

某银行完成第一轮开源组件盘点后，很快整理出一张几千行的组件清单。

为了尽快形成准入基线，项目组把已经在生产系统中出现、扫描没有命中禁止规则的组件先标记为“允许使用”，整张存量清单也就被当成了“白名单”。

几个月后，一个新项目准备选择 JSON 处理组件，研发团队在这张清单里找到了多个功能相近的选项，版本跨度超过五年。安全团队说：“这些组件当前都没有命中红线。”架构团队说：“技术栈基线只规定了 Java 版本，没有规定具体组件。”运维团队则提醒：“其中两个组件没有统一升级方案，出了问题只能由项目自己处理。”

研发最终选择了自己最熟悉的一个版本。它确实被标记为“允许使用”，却不是银行真正愿意长期维护的选择。

这张被当成白名单使用的存量清单没有撒谎，但也没有完成准入决策。它回答的是“过去用过什么”，没有回答：

• 新项目应该优先选什么？
• 什么只能在特定系统、特定版本和特定期限内使用？
• 什么虽然暂时没有高危漏洞，却不适合成为银行长期技术依赖？
• 同一个组件进入核心系统和内部辅助工具，是否应该采用相同门槛？

如果这些选择没有提前形成稳定规则，流水线就只能反复拦截，每个项目也都要重新争论。准入治理应当把判断往前移：哪些推荐，哪些允许，哪些需要审批、限制或禁止。

责任明确以后，还缺一套共同的判断依据

上一篇建立了银行级开源治理的组织、制度、流程、平台和运营体系，也明确了一个重要边界：专业团队负责说明风险，系统责任人负责在授权范围内作出使用决定，重大例外再升级。

JR/T 0291-2024 将开源软件评估放入引入、维护和退出等生命周期节点[1]。这意味着，银行不仅要明确谁有权作出决定，还要为不同生命周期阶段准备稳定的判断依据。

上一篇把决策权落到了具体角色，本篇继续处理这些角色作出决定时共同使用的依据。

但要让这套责任体系高效运行，不能让每一个项目都从零开始评估每一个组件。否则，治理委员会和专业团队很快又会被日常申请淹没。

组件准入的作用，就是把反复出现的专业判断沉淀为可复用策略：

一次完整评估
→ 形成组件状态和适用条件
→ 相同条件下重复使用
→ 条件变化时重新评估

落实到银行内部，准入不应是一次性的“通过/不通过”，而应是一个持续变化、能够被复审和撤销的治理状态。

白名单、准入清单和推荐技术栈不是一回事

很多项目把这三个概念混在一起，结果白名单越做越大，研发却仍然不知道该选什么。

三者之间存在包含关系，但不能互相替代：

• 存量系统正在使用，不代表新项目仍然允许引入。
• 允许使用，不代表银行愿意把它作为首选技术路线。
• 被推荐，也不代表任何版本、任何来源、任何系统都可以无条件使用。

因此，白名单不能只是组件名称列表。一条真正可执行的准入记录，至少要精确到生态、组件、版本范围、可信来源、适用范围和复审条件。

第一步：用五个维度评估组件，而不是只看漏洞

组件评估至少要同时覆盖安全、License、生态健康度、架构适配和运维保障五个维度。

OpenSSF Scorecard 提供了代码审查、项目维护状态、安全策略、签名发布、已知漏洞等开源项目安全健康信号[2]。这些信号可以帮助银行进行初筛，但不能直接把一个总分转换成“允许”或“禁止”：维护频率低可能意味着项目已经稳定，也可能意味着无人维护；许可证文件存在，也不等于具体使用场景已经完成合规判断。

类似地，SPDX License List 可以用标准标识符和表达式统一许可证事实，但 SPDX 本身强调其作用是收集、表达和交换事实，并不替使用者作出许可证合规的法律解释[3]。工具识别和标准化表达解决的是“看到了什么”，准入仍要回答“在本行这个场景下意味着什么”。

实际做组件准入时，我不建议试图用一个总分代替所有决策。更稳妥的结构是“红线+评分+专业判断”：

1. 红线项决定是否直接禁止，例如来源无法确认、命中本行明确禁止的许可证规则、存在不可接受且无补偿措施的重大风险。
2. 评分项帮助比较同类组件，例如生态健康度、文档、兼容性、维护能力。
3. 专业判断处理无法机械量化的事项，例如核心系统升级风险、许可证适用场景和供应商支持边界。

评分不必一开始就追求复杂模型，但需要说明“分数怎么来的”。例如，某银行可以把生态健康度拆成下面五项，对每项按 1—5 分评价，再根据本行关注重点设置权重：

这组权重只用于演示计算方法，不是银行通用阈值。评分主要用于同类组件之间的比较；红线可以直接否决，专业判断也不能被总分覆盖。

组件准入评估表

第二步：把“通过”拆成五类策略

只有“白名单”和“黑名单”两个状态，会把大量需要条件判断的组件挤到同一个灰色区域。更实用的做法是设置五类使用策略：

这五类策略不是风险等级的简单同义词。例如，一个社区健康度一般但业务不可替代的组件，可能被“限制使用”；一个风险很低但与本行技术路线重复的组件，也可能只被“允许”，而不进入推荐技术栈。

准入策略同时服务三个目标：

• 降低风险： 明确禁止和限制边界。
• 减少重复判断： 推荐和允许组件在相同条件下复用评估结果。
• 收敛技术栈： 让新项目优先使用银行有能力长期维护的少数组件。

第三步：组件风险和系统重要性共同决定管控强度

同一个组件用于内部报表工具和核心支付系统，不能只因为组件评估结果相同，就采用完全相同的控制方式。

进入分类分级矩阵之前，组件应先通过红线检查。来源无法确认、恶意组件、命中本行明确禁止且不允许例外的规则，直接进入禁止处理，不因为系统重要性较低而放宽。只有未命中红线的组件，才进入下面的双轴矩阵。

建议把组件属性与使用场景拆成两个轴：

组件侧需要考虑

• 是否位于基础框架、身份认证、加密、网络通信或数据访问等关键位置。
• 是否具有高权限、广泛依赖和较大故障影响面。
• 社区维护、漏洞历史、许可证和替代方案是否稳定。
• 银行是否具备自主维护能力或可靠商业支持。

系统侧需要考虑

• 是否属于核心、重要或一般信息系统。
• 是否面向互联网、处理敏感数据或直接影响客户交易。
• 是否具备灰度、回滚、隔离和补偿控制能力。
• 变更失败是否会影响业务连续性或重要服务。

分类分级矩阵

矩阵的作用不是自动替银行作出全部决定，而是统一默认处理方式。专业团队可以在证据充分时调整结论，但必须记录调整依据、责任人和有效期。

核心或高暴露系统即使选用了低风险成熟组件，也可能需要额外审批或验证。原因不在于组件风险被重新判高，而在于这类系统对兼容性、稳定性、回滚条件和业务连续性的要求更严格。

第四步：把组件状态做成生命周期，而不是静态名单

组件的漏洞、许可证、社区和支持状态都会变化。今天被推荐的组件，明天可能停止维护；今天只能试用的组件，经过验证后可能进入正式准入。

建议区分“生命周期阶段”和“使用策略”：

• 生命周期阶段描述组件当前走到哪个治理阶段。
• 使用策略描述当前允许如何使用。

建议状态流转

这是一张允许的阶段关系图，不表示所有组件必须机械经过每一个节点。已有充分评估证据的成熟组件可以从待评估直接进入有效；不适合生产使用的试用组件也可以直接结束试用。任何跳转都应满足目标阶段的进入条件并留下评估记录。

这样命名后，“推荐、限制、禁止”只表示使用策略，“有效、观察中、退出中、已停用”只表示治理阶段，平台不会在两个字段中读到同一组状态名称。

第五步：把白名单做成平台可执行的策略记录

一条只写着“允许使用 Log4j”的白名单记录无法直接执行，因为它没有回答版本、来源、系统和期限。

最小组件策略记录

其中，组件名和版本号仍不足以唯一标识实际制品。对容器镜像、二进制包和可重新发布的制品，还应固定摘要或哈希，避免同名同版本内容变化。

一条组件策略记录通常会被多个系统复用，因此不应把所有实际系统责任人都塞进一个 Owner 字段。平台还需要建立与之关联的系统使用记录：

最小系统使用记录

这些记录最终需要进入平台规则，但规则的所有者仍然是银行：架构维护推荐技术栈，安全维护安全门槛，法务维护许可证策略，科技管理负责流程和版本控制。工具厂商可以实现规则，不能替银行定义风险偏好。

白名单如何更新：四类触发器、一个失效机制

白名单最危险的状态不是“没有”，而是看起来存在、实际上已经过期。

建议同时设置四类更新触发器：

1. 版本触发： 主版本变化、关键依赖变化或构建方式变化。
2. 风险触发： 重大漏洞、恶意包、供应链事件或安全策略变化。
3. 合规触发： 许可证变化、权利声明变化或使用场景变化。
4. 生态触发： 停止维护、项目归档、维护权转移或替代项目成熟。

此外，每条“审批”和“限制”策略必须有明确有效期。到期后不是继续默认放行，而应进入三种结果之一：

• 完成复审，延长并更新条件。
• 完成整改，转为准入或推荐。
• 未完成复审，自动降级为阻断新增，并升级责任人处理。

例外不是永久白名单

例外记录至少应包含：

• 适用的系统、组件和精确版本。
• 业务必要性和无法采用推荐方案的原因。
• 已识别风险与补偿措施。
• 整改或替换责任人。
• 生效时间、到期时间和复审条件。
• 超期后的自动处理方式。

如果一条例外被不同项目反复申请，应回到策略层重新判断：它究竟应该被正式准入，还是应该被统一禁止，而不是让每个项目重复走形式化审批。

三种会让准入失真的做法

坑一：把扫描无风险当成准入通过

某个组件完成 SCA 扫描后，没有发现高危漏洞，许可证也被工具识别为常见许可证，于是项目直接将其标为“允许”。半年后，系统准备对外交付时，法务才发现实际交付包中还包含其他依赖和特殊条款，需要结合分发方式重新判断；运维团队也没有为该组件建立统一升级和替代方案。

扫描结果并没有错。它只是回答了当前知识库下识别到了哪些组件、漏洞和许可证文本，不能证明来源可信、社区可持续、架构适配，也不能替法务判断具体使用场景下的权利义务。

扫描应当作为安全和 License 事实输入，再由架构、法务、运维和系统责任人完成各自判断。工具“未发现问题”只能让流程继续，不能直接生成准入结论。

坑二：白名单只写组件名，不写条件

同一个组件的不同版本可能具有完全不同的漏洞和兼容性状态；同名同版本的制品也可能来自不同上游，甚至对应不同内容。一个组件可以在内部辅助系统中使用，也不代表它可以直接进入面向互联网的核心系统。

白名单记录必须包含版本、不可变标识、来源、适用范围、限制条件、Owner 和复审触发器。平台放行时比对的是这组条件，不是一个组件名称。

坑三：推荐技术栈只进不出

每个项目都希望把自己使用的组件加入推荐列表，却很少有人主动申请移除。几年以后，同类组件可能各有三四个“推荐选项”，架构团队无法集中维护，安全团队要维护多套规则，供应商和研发团队也无法形成稳定的升级能力。

推荐必须对应集中维护能力；每个推荐组件都要有 Owner、版本基线、替代关系和退出路线。新增一个推荐组件时，评审人应当追问：它替代什么，由谁维护，什么情况下开始退出。

把那张几千行的清单拆开

开篇那家银行不需要先删除所有存量记录，而应该把一张名单拆成三个层次：

1. 保留完整存量清单，继续回答“现在用了什么”。
2. 从存量中建立带条件的准入清单，回答“在什么条件下可以继续用”。
3. 从准入组件中选择少量银行愿意集中维护的组件，形成推荐技术栈，回答“新项目应该优先选什么”。

当研发再次询问 JSON 组件怎么选时，系统不再返回几百条“都没有命中红线”的记录，而是给出：

• 首选的推荐组件和版本基线。
• 可选但需要说明理由的允许组件。
• 仅限存量系统使用的限制组件。
• 不得新增的废弃或禁用组件。

准入治理提供的效率，就体现在大多数常规选择不再需要重新争论，而不是每个项目又多填一张审批表。

规则落地还差一个受控入口

准入清单和推荐技术栈建立以后，还有一个更现实的问题：研发机器和构建流水线是否只能获取这些已经准入的制品？

如果 Maven、npm、PyPI 和公共镜像仓库仍然可以被项目直接访问，白名单就只是一份参考文件。项目可以绕过内部审批下载同名不同内容的制品，也可能因为上游删除、替换或网络波动导致构建不可重复。

同样，组件进入“观察中”后，暂停新增、限定版本或进入复评的要求不能只停留在台账里。策略变化需要及时传递到组件获取入口和构建规则，否则生命周期状态发生了变化，项目仍然可以按原路径继续下载和使用。

第 05 篇将继续到获取环节：银行内部可信开源源站应该如何建设，以及准入结果怎样和组件的实际下载路径绑定。

数据来源

1. 中国人民银行，JR/T 0291-2024《金融业开源软件应用评估规范》，2024。https://std.samr.gov.cn/hb/search/stdHBDetailedCNF?id=0FD7E9C4C5036738E06397BE0A0A217C
2. Open Source Security Foundation, OpenSSF Scorecard — Check Documentation. https://github.com/ossf/scorecard/blob/main/docs/checks.md
3. SPDX Project, SPDX Overview and License List. https://spdx.dev/about/overview/ ; https://spdx.dev/learn/overview/