当前位置：首页 > 文章列表 > 科技周边 > 业界新闻 > OpenSSF Scorecard 怎样把依赖安全信号放入审查流程

OpenSSF Scorecard 怎样把依赖安全信号放入审查流程

来源：17golang原创 2026-11-14 04:57:18 0浏览收藏

如果团队把第三方依赖当成黑盒，只看版本号和漏洞列表，审查往往会漏掉构建权限、发布签名、分支保护以及工作流写权限等问题。OpenSSF Scorecard 的价值，是把这些软件供应链实践拆成可解释的检查项，再交给工程团队判断风险和安排修复。

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

官方仓库：https://github.com/ossf/scorecard

Scorecard 的总分适合做筛选信号，不适合直接当作“安全”或“不安全”的裁决。真正可落地的做法是：先看高风险单项，再确认检测范围和例外原因，最后把结论写进审查记录与修复 PR。

一、先分清总分、单项分数和风险等级

Scorecard 的每个自动检查都会返回 0 到 10 的分数，并带有风险等级；这些结果再汇总成整体分数。高风险检查反映的是更容易被利用、或一旦被利用影响更大的工程环节。例如代码审查、分支保护、令牌权限、依赖固定和发布签名，通常比“是否声明许可证”更值得优先看。

因此，阅读结果时不要只问“总分是多少”，而要问三个问题：

哪个检查项失分，具体检测到了什么文件、工作流或仓库事实？
这个检查项的风险等级是什么，是否会直接影响构建、发布或依赖更新？
Scorecard 是否支持当前项目的托管平台、发布方式和工具链？

仓库依赖和工作流经过 Scorecard 检查项与风险等级进入审查清单的结构图 — 图1：Scorecard 信号分层与审查入口的结构说明图，不是运行截图。

二、依赖审查优先看哪些检查项

围绕“依赖是否值得进入构建和发布链路”这个问题，可以先筛出一组紧凑的检查项：

检查项	审查问题	后续动作
Pinned-Dependencies	工作流、脚本和构建依赖是否锁定到不可变版本？	确认是否使用完整提交哈希或生态认可的固定版本。
Vulnerabilities	依赖或发布对象是否存在未修复漏洞？	区分可达路径、受影响组件和升级窗口。
Token-Permissions	CI 令牌是否遵循最小权限？	把只读权限放在工作流顶层，把必要写权限缩到具体任务。
Signed-Releases	发布产物是否能证明来自预期的发布流程？	核对签名、发布主体和消费者的校验方式。
Dependency-Update-Tool	依赖更新是否有持续维护机制？	确认更新工具、审查规则和升级失败时的责任人。

这张表不是“必须全部满分”的清单。例如库项目可能没有传统意义上的发布包，或某种发布方式暂时不在自动检测范围内。检查结果只负责提出可追问的线索，最终结论仍要结合项目的真实交付方式。

三、用 GitHub Action 把结果留在工程系统里

官方 Action 支持把结果保存为 JSON 或 SARIF。团队若要在代码扫描界面集中查看结果，通常选择 SARIF；若要在内部系统做二次聚合，可保留 JSON。下面是一个缩减后的工作流示例，版本号和 Action 提交引用应以官方仓库的当前发布说明为准。

name: OpenSSF Scorecard

on:
  push:
    branches: [main]
  schedule:
    - cron: "15 7 * * 1"

# 默认只读，避免整个工作流继承不必要的写权限。
permissions: read-all

jobs:
  scorecard:
    runs-on: ubuntu-latest
    permissions:
      # 上传 SARIF 与发布结果分别需要明确声明权限。
      security-events: write
      id-token: write
    steps:
      - uses: actions/checkout@v4
        with:
          # 不把仓库凭据留在后续步骤的工作区中。
          persist-credentials: false
      - uses: ossf/scorecard-action@v2.5.0
        with:
          # SARIF 便于接入代码扫描界面，文件名保持稳定方便归档。
          results_file: results.sarif
          results_format: sarif
          publish_results: true
      - uses: github/codeql-action/upload-sarif@v3
        with:
          # 只上传本次 Scorecard 生成的结果文件。
          sarif_file: results.sarif

生产环境不应只复制示例中的浮动版本。更稳妥的做法是按照官方工作流示例，把 Action 固定到完整提交哈希，并在升级时单独审查变更。与此同时，顶层权限应保持只读，确实需要写权限的任务再在 job 级别声明。

四、把“低分”翻译成可审查的问题

一个好的审查记录不会写“Scorecard 只有 6 分，所以拒绝”。它应该把结果拆成事实、影响和行动：

事实：记录具体检查项、结果文件、扫描对象以及检测范围。
影响：说明它可能影响依赖更新、构建隔离、发布完整性还是仓库维护。
补证：查看项目是否通过另一种方式满足要求，只是自动检查没有识别。
行动：决定升级依赖、收紧权限、补充签名、增加审查规则，或记录一个明确的例外。

例如，Pinned-Dependencies 低分不一定说明所有依赖都可被替换。官方文档指出，该检查主要观察 Dockerfile、shell 脚本和 GitHub 工作流；Go 模块的完整语义版本也有其特殊处理。审查时应继续确认构建入口是否还有其他动态下载路径。

五、用维护者注释处理自动检测的盲区

Scorecard 提供维护者注释机制，用来解释“测试数据中的二进制文件”“已经修复但检测仍能看到的历史配置”“当前场景不适用”或“使用了工具但无法被识别”等情况。注释不是给低分涂色，而是把上下文留在结果旁边，避免下一位审查者重复猜测。

annotations:
  - checks:
      - binary-artifacts
    reasons:
      - reason: test-data # 说明该二进制只用于测试数据，不是发布产物。
  - checks:
      - dangerous-workflow
    reasons:
      - reason: remediated # 说明风险已由人工门禁和审批流程补救。
  - checks:
      - pinned-dependencies
    reasons:
      - reason: not-supported # 说明当前工具链的固定方式暂未被识别。

注释的前提是团队能拿出对应证据。对于“已修复”，要能指向修复 PR 或策略变更；对于“不适用”，要写清业务边界；对于“未检测到”，要避免把“工具没识别”误写成“项目没有做”。