OpenSSF Scorecard 检查项在 CI 中的落地方式

OpenSSF Scorecard 接入 CI，建议从独立分析任务开始：使用官方 Action 生成结果文件，保留运行记录，再按检查项安排整改。分析任务成功不等于仓库所有检查都满足团队政策，也不等于结果已经对外发布。

官方地址：https://github.com/ossf/scorecard-action

先确认仓库与触发范围

官方 Action 面向公开仓库，也对具备 GitHub Advanced Security 的私有仓库提供支持；其他场景需对照官方命令行方案判断。官方说明列出 push 与默认分支 schedule 支持，pull_request 和 workflow_dispatch 为实验性触发，fork 仓库和 GitHub Enterprise 仓库不受支持。不要把同一份配置直接复制到所有仓库。

从官方工作流模板建立独立分析任务

在仓库 Security 的 Code scanning 配置入口寻找 OpenSSF Scorecard 工作流，或依照官方 README 的手工配置说明建立 .github/workflows/scorecard.yml。采用经审核的完整提交 SHA 固定 Action 引用，更新引用时记录变化。先确认分析能运行并产生文件，再讨论阻断合并的策略。

results_file 决定文件位置，results_format 决定格式；供 GitHub 扫描面板使用时选择 SARIF。公开发布与文件生成应分开考虑，publish_results=true 涉及 OIDC 权限和额外工作流限制，不能为了排错给整个流水线开放写权限。

把结果转成可负责的整改项

假设某个团队首次接入后看见多个低分项。不要立刻用总分设置合并门槛：先阅读每项原因，确认工具能否访问所需信息，再判断是实际控制缺口、能力限制还是不适用。为需整改项记录责任人、对应仓库设置和目标状态；例外则写理由与复查时间。

上传分析产物与上传 code scanning 是不同动作。保留文件时考虑失败路径、保留时长和访问权限，不把令牌与秘密配置写入普通产物。

执行、发布与门禁必须分别判断

官方 README 说明结果发布失败可能只表现为警告，结果文件仍可生成。需要观察 job summary 与对应输出，而不能只凭绿色任务认定外部结果已更新。团队自定的检查项门禁也应独立说明失败含义，避免将网络失败误标为代码安全问题。

先观察一段时间，确定适用项与数据可见性，再选择明确的策略作为门禁，是本文的实施建议。Scorecard 用于发现安全实践信号，不能替代代码审阅、漏洞处理或针对具体系统的风险判断。

常见问题

总分提高能说明没有漏洞吗？不能。分数反映检查覆盖的实践信号，仍需阅读原因及实际风险。

初次接入必须公开发布吗？应先明确结果用途和官方配置要求，不要把文件留存与公开徽章混为一谈。

配置细节请以官方 Action README为准；检查项含义可查Scorecard 项目说明。