登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  业界新闻

OpenSSF Scorecard 怎样查看分支保护分数

来源:17golang原创

时间:2026-10-27 02:50:58 192浏览 收藏

想用 OpenSSF Scorecard 查看一个仓库的分支保护分数,先不要看页面顶部的 Aggregate score。正确做法是打开项目结果,定位 Branch-Protection 这一行,再展开详情;如果项目不在公开结果里,就用 CLI 只运行这个检查。

官方地址:https://scorecard.dev/viewer/

Branch-Protection 是一个 0–10 分的单项检查,而且采用分层计分:Tier 1 没通过时,后面即使配置得很完整,也不会直接拿到更高层级的分数。
  • 先找对指标:看 Branch-Protection,不要用总分代替它。
  • 再看分层:3、6、8、9、10 分分别对应不同的保护门槛。
  • 最后看范围:Scorecard 主要判断默认分支和发布分支,令牌权限也会影响可见设置。

OpenSSF Scorecard 查看入口怎么选

公开项目可以使用 Scorecard Viewer,把仓库路径作为查询对象,进入结果页后在检查列表中找到 Branch-Protection。这里要区分两类数字:Aggregate score 是所有检查按风险权重计算的总分,Branch-Protection 旁边的数字才是分支保护单项分数。

如果 Viewer 没有现成结果,或你想针对某个仓库即时查看,可以用 CLI。官方 CLI 支持用 --checks 缩小检查范围,用 --show-details 展开原因:

# 只查看目标仓库的分支保护检查,并展开每条规则的原因
scorecard --repo=github.com/your-org/your-repo \
  --checks=Branch-Protection \
  --show-details

# 需要脚本读取结果时,改为官方支持的 JSON 格式
scorecard --repo=github.com/your-org/your-repo \
  --checks=Branch-Protection \
  --format=json

把 your-org/your-repo 换成实际仓库路径即可。查看结果时先确认仓库对象没有写错,再记录单项分数和原因文本,避免把另一个项目的总分当成当前仓库的分支保护结论。

Scorecard Viewer 与 CLI 汇聚到 Branch-Protection 单项检查并区别总分的静态关系说明图
图1:Scorecard 查看入口与单项检查的关系说明图;这是静态说明图,不是网页或终端截图。

Branch-Protection 的 0–10 分怎样读

Scorecard 的 Branch-Protection 不是把每个开关简单相加,而是逐层满足门槛。当前官方检查文档给出的阅读方式可以整理成下面这张速查表:

最高层级需要满足的核心条件对应分数
Tier 1禁止强制推送、禁止删除分支3/10
Tier 2至少 1 名审核者;管理员变更也走 PR;分支保持最新或使用合并队列;审核最近一次可审查推送6/10
Tier 3合并前至少通过 1 项状态检查8/10
Tier 4至少 2 名审核者,并要求 CODEOWNERS 审核9/10
Tier 5新提交后撤销过期审核,并把管理员纳入审核约束10/10

例如,仓库启用了两名审核者和状态检查,但仍允许删除默认分支,那么 Tier 1 没有完整满足,分数就可能停在较低层级。读详情比只看分数更重要,因为详情会指出是哪个分支、哪项规则没有满足。

Branch-Protection 从 Tier 1 到 Tier 5 的分数层级和管理员权限范围静态说明图
图2:Branch-Protection 分层评分与权限范围说明图;这是静态说明图,不是运行结果截图。

为什么同一个仓库可能看到不同分数

第一类差异来自检查范围。官方文档说明,Branch-Protection 主要检查项目的默认分支和发布分支;某个开发分支设置得很严,并不会自动把默认分支的分数抬高。阅读详情时要看它列出的分支名,而不是只看仓库里任意一条规则。

第二类差异来自权限。DismissStaleReviews、EnforceAdmins、最近一次可审查推送和严格状态检查等设置,可能需要管理员令牌才能完整读取。令牌权限不足时,Scorecard 会基于它能访问到的设置计算结果;这时不要把“未显示”直接等同于“仓库未配置”。

第三类差异来自规则集覆盖。GitHub 的 Repository Rules 可以覆盖分支保护规则的部分能力,Scorecard 的官方说明也提示规则集和经典 Branch Protection 的可读权限不同。排查时把分支名、规则来源和访问权限一起记录。

按分数缺口安排修复和复查

查看分数的目的不是追求一个脱离场景的数字,而是找到下一项实际控制。可以按下面顺序处理:

  1. 先补 Tier 1:关闭默认分支和发布分支的强推、删除能力,避免公共历史被直接改写。
  2. 再补审核门槛:至少要求一名独立审核者;团队规模允许时再增加第二名审核者和 CODEOWNERS。
  3. 补齐合并前检查:把真正能阻止缺陷进入主分支的 CI 状态检查设为必需,而不是只运行但不阻塞合并。
  4. 确认管理员边界:决定管理员是否也必须走 PR、是否撤销过期审核,并使用足够权限重新读取详情。

复查时只比较同一个仓库、同一组目标分支和同一权限条件下的结果。如果只换了令牌或规则集,而没有保留这些上下文,分数变化很难说明真实配置变好了还是读取范围变了。

常见问题

Branch-Protection 分数和 Scorecard 总分有什么区别?

Branch-Protection 是单项检查,范围是分支保护;Aggregate score 是多个检查按风险权重合成的总分。要回答“分支保护做得怎样”,应引用单项分数和详情。

为什么设置了很多规则,分数还是只有 3 分?

先查 Tier 1 的强推和删除保护。Scorecard 是分层计分,低层级未完整满足时,高层级条件不会直接叠加。

没有管理员令牌还能查看吗?

可以查看,但部分仅管理员可读的设置可能无法完整判断。应在结果里保留权限条件,必要时用有权限的维护者令牌重新运行;不要把权限不可见当成规则一定缺失。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>