代码仓库启用了分支保护，供应商风险团队究竟能确认什么？
分支保护供应商风险证据的边界：受保护分支快照只能证明配置存在，不能证明审查执行、绕过受限或交付版本经过该流程，五层证据帮你把配置与执行分开。
一次扫描能确认的只有一件事：在扫描当天，该仓库的配置要求在变更合入该分支前满足特定条件。它不能证明要求的审查真的发生过、绕过不可能、被扫描的配置是完整的，或者供应商交付的就是那个版本。对负责供应商复核的软件供应链情报负责人来说，把“规则已配置”与“规则被执行、交付的产品确实经过这套流程”分开，是快速放行一个依赖与安排一次审计之间的差别。
先定义几个术语，因为每个术语都是一处“可见设置”与“真实行为”可能分叉的点，而供应商风险证据要捕获的正是这种分叉。受保护分支（protected branch）是 GitHub 中规则可以阻止删除和强制推送、并要求变更在到达分支前满足审查或状态检查等条件的分支（GitHub 文档，2026 年 8 月 3 日访问）。拉取请求（pull request）是审查者在合并前批准或拒绝的变更提案；要求审查的规则意味着每个拉取请求需要配置数量的批准。状态检查（status check）是来自外部工具——通常是持续集成流水线——的通过或失败信号，可被设为合并前的必需项。Open Source Security Foundation（OpenSSF）Scorecard 则是对开源仓库安全实践（含分支保护）自动打分的工具。
关键事实：官方来源怎么说
GitHub 文档（2026 年 8 月 3 日访问）说明，分支保护规则可以控制删除和强制推送，并要求变更在到达分支前满足审查或状态检查等条件；必需审查可以指定审查者人数，过时批准（stale approvals）可以被驳回，管理员或自定义角色的绕过行为可以不同。文档把可见规则呈现为一项配置观察，其确切范围和绕过设置仍需核实——发布者自己把“设置”与“执行”分开陈述。
OpenSSF Scorecard 的检查文档（详细检查文档，2026 年 8 月 3 日检索）含 20 个检查小节，并多次警告：CI-Tests、Dependency-Update-Tool、Fuzzing、Packaging、SAST 等基于检测的检查得分低，并不等于项目有风险的确定指示，因为自动化检测可能漏掉有效实践。其 Maintained 检查在“过去 90 天每周至少一次提交”时给最高分，同时明确提示外部用户考虑本就无需高频活动的软件。分数描述的是检索当天自动化能检测到什么，不是项目实际在做什么，更不代表任何采购方的意图。
当前 Branch-Protection 检查的层级是：阻止强制推送和删除为 3/10；满足 Tier 2 审查条件后为 6/10；设了必需状态检查为 8；两名审查者加 code-owner 审查为 9；驳回过时批准并纳入管理员为 10。这些是配置测量的深度层级，不是产品认证，层级里没有任何一项能证明人类审查真的发生过。
五个证据层：一张表对应一个结论
一个观察喂给五个独立的问题。把五层放进一张表，能让带日期的配置事实钉在原位，不漂移成执行声明。
| 证据层 | 它记录什么 | 它仍留下什么未解 |
|---|---|---|
| 指定分支与规则快照 | 哪个分支受保护、规则原文、扫描日期 | 规则在实践中是否被执行 |
| 审查与状态检查要求 | 审查者人数、过时批准是否驳回、必需状态检查 | 审查是否真的进行、检查是否真实 |
| 绕过与扫描权限局限 | 谁能绕过（管理员、自定义角色）、扫描方的访问级别 | 生产合并是否面对同样的限制 |
| 交付版本 | 供应商交付的确切修订或构建 | 该修订是否经过受保护流程 |
| 负责的供应商决定 | 谁确认了这些事实、记录保存在哪里 | 配置下个季度是否仍然成立 |
为什么这对供应商复核重要
哪些信号能预测供应商产品可以安全集成，是更大的问题，见指南供应商资质与产品采购信号；这里的要点是，把配置直接折算成风险会产生两种可预见的错误。第一种：规则很强但发布流水线独立——受保护流程只覆盖开发，产物在别处构建和签名——仓库获得它没挣得的低风险评级。第二种：仓库最后一次发布走了紧急绕过，却因为没人问交付的是哪个版本而被当作安全。两种错误都把带日期的配置当成交付产品的证明；五层证据迫使“哪个版本、经过哪套流程、由谁确认”进入记录。
最强的反驳，以及扫描权限的局限
最强的反驳是：分支保护是自动化且公开的，高 Scorecard 分数本身已是足够的信号。答案就在 Scorecard 文档里（2026 年 8 月 3 日检索）：基于检测的检查得分低不是风险的确定指示，因为自动化检测可能漏掉有效实践。如果低分不能证明风险，高分配置分数同样不能证明安全——两者衡量的都是自动化能看到什么，而不是实际发生了什么。分数还是一个快照：Maintained 检查奖励的是过去 90 天的活动节奏，告诉你的只是检索当天的提交节奏，而非你正在接手的那个修订版本。
扫描权限局限是同一论点的实操版本。多数供应商扫描用只读令牌运行：它能看到规则存在，但看不到绕过名单、管理员成员或审计日志事件——正是这些设置决定规则是否适用于产生交付版本的那次合并。这就是为什么“扫描访问级别”是表中第三层，也是为什么低权限扫描之后必须由供应商侧确认它看不到的部分。
工作示例：一条复合 Telegram 消息
设想供应商维护者在私有群里发来一条消息。以下消息为复合示意（composite/illustrative），仅用于演示方法，不代表任何真实客户对话，也不构成任何真实供应商行为的证据：
复合 Telegram 消息（仅示意）： 供应商维护者，私有群组频道，2026 年 7 月 14 日：“main 分支已开启分支保护，合并前一切都经过审查。我们发给你的 2.4.1 构建可以放心接入，额外审计可以省了。”
用五层过一遍。第一层：“main”命名了分支，但没有规则原文和快照日期。第二层：没有审查者人数，没有点名状态检查。第三层：没有绕过名单——而只读扫描根本看不到绕过名单。第四层：2.4.1 是标签不是修订；哪个 commit SHA、由哪条流水线构建、带哪些结果？第五层：消息来自群组频道，但供应商这边没有任何具名的人在可留存的记录里确认过其中任何一点。
Telegram 的隐私语境划定观察边界：Telegram 隐私政策（2026 年 8 月 3 日访问）把 bot 描述为独立的第三方服务，可以带或不带消息访问权限运行，并说第三方开发者应在访问数据前征得许可。观察渠道有访问模式，访问模式限制观察能主张什么——这与五层是同一套纪律。关于如何权衡渠道级信号，见Telegram 信号来源。
FAQ
分支保护能证明供应商的代码审查真的发生过吗？
不能。它只证明配置在扫描当天要求审查。审查是否进行、状态检查说了什么、谁能绕过规则、交付的是哪个版本，都必须与供应商分开核实。
OpenSSF Scorecard 的分支保护分数是产品质量认证吗？
不是。它是可自动化检测的设置的配置测量。Scorecard 文档自己警告低检测分数不证明风险，同样的逻辑反过来也成立：高配置分数不证明安全。
看到供应商仓库有分支保护后，我应该问什么？
要分支名和规则快照、审查者与状态检查要求、绕过名单及所用扫描器的访问级别、确切交付版本，以及负责确认这一切的具名人员。
下一步值得做的事
挑一个仓库显示启用了分支保护的候选依赖，在下一次复核前填好第一层和第五层：写下分支名、快照日期，以及供应商这边由谁来确认其余部分。这一页纸就把“你已知的”与“你在假设的”分开，也给供应商的安全团队一个具体可答的问题。如果 Telegram 群在你的信号采集中，保持同样的边界：TOP Prospect 只处理你主动连接且有权访问的 Telegram 群，保留来源证据，产出的候选项与评分不是事实认证，最终决定由人工做出，且不会自动联系群成员。关于这套流程如何融入复核工作，见Telegram 商业信号情报——五层证据与人工签字始终是事实来源。
常见问题
分支保护能证明供应商的代码审查真的发生过吗？
不能。它只证明配置在扫描当天要求审查。审查是否进行、状态检查说了什么、谁能绕过规则、交付的是哪个版本，都必须与供应商分开核实。
OpenSSF Scorecard 的分支保护分数是产品质量认证吗？
不是。它是可自动化检测的设置的配置测量。Scorecard 文档自己警告低检测分数不证明风险，同样的逻辑反过来也成立：高配置分数不证明安全。
看到供应商仓库有分支保护后，我应该问什么？
要分支名和规则快照、审查者与状态检查要求、绕过名单及所用扫描器的访问级别、确切交付版本，以及负责确认这一切的具名人员。