Scorecard 与 CII Best Practices Badge

• 三项检查项各自的具体含义与检测方式
• 三者如何从不同维度覆盖"开发流程"整体安全
• 如何在 CI 中落地 Scorecard 检查并形成闭环

这三项都是 Scorecard 中关于"流程与协作"的检查项。Code Review 检查代码在合并前是否经过评审（通过检查 PR 是否由非作者 review、是否禁止直接 push 分支），反映代码质量与人为把关；Dangerous Workflow 检查 GitHub Actions 是否使用了容易受攻击的写法（如 pull_request_target、push 事件触发、actions/checkout 后执行不可信代码、未使用最小权限的 GITHUB_TOKEN），反映 CI 自动化本身的安全；Dependency Update Tool 检查仓库是否配置了依赖更新工具（如 Dependabot、Renovate），反映依赖是否持续更新。三者协同：Code Review 把住"人"的关卡，Dangerous Workflow 把住"机器"（自动化流水线）的关卡，Dependency Update Tool 把住"依赖"进化的关卡，共同构成对开发流程完整性的覆盖。

它们分别针对开发流程中不同环节的薄弱点，单看某一项都只能覆盖局部。工程上通过定期运行 scorecard 命令（或 GitHub Action 的 ossf/scorecard-action）生成报告，并设置门禁或告警，将三项指标纳入团队安全基线，从而让流程安全可度量、可改进。

• 五项检查各自关注的安全维度
• 它们如何覆盖"开发、测试、发布、使用"全生命周期
• 协同落地的工程手段

这五项分别覆盖不同安全能力：Fuzzing 检查是否配置了模糊测试工具（如 OSS-Fuzz），覆盖运行时输入健壮性；License 检查是否包含许可证文件（如 LICENSE），覆盖合规与使用边界；SAST 检查是否配置了静态分析工具，覆盖源码级漏洞；Security Policy 检查是否有 SECURITY.md 说明漏洞报告渠道，覆盖漏洞响应入口；Token Permissions 检查是否给 GitHub Token 设置了最小权限（contents: read 等），覆盖发布与 CI 的权限边界。协同上，它们构成"预防（SAST）-测试（Fuzzing）-合规（License）-响应（Security Policy）-权限（Token Permissions）"的完整闭环，任何一项缺失都可能导致安全盲区。

五项能力各有侧重，覆盖从编码到发布再到漏洞响应的全生命周期。工程上通过统一运行 Scorecard 与其他安全工具（如 CodeQL、Dependabot）形成安全基线，并让每一项在 CI 中有对应检查与告警。

• Scorecard 分数仅是过程指标而非安全结果
• 刷分（gaming）的典型表现
• 治理方向：以结果为导向、结合人工复核

Scorecard 的检查项大多是"可验证的签名（signature）"而非"真实安全效果"，因此存在刷分空间：例如只放一个空的 SECURITY.md 而不真正响应漏洞，或配置了 SAST 但从不阅读报告。治理的关键在于：一是把 Scorecard 分数定位为"过程健康度"而非"安全结果"，避免单纯以分数作为考核指标；二是补充结果性指标（如漏洞修复 SLA、安全事件数、漏洞被利用率）；三是对高分项做人工复核，确认不是空壳配置；四是结合迁移测试、漏洞奖励计划等真实安全实践来评估。

任何以单项分数为唯一 KPI 的指标都可能被钻空子。正确做法是"过程指标 + 结果指标"双轨，并让安全团队人工抽查，识别"有配置但无实际执行"的情况。

• Signed Releases 检查项的含义
• SLSA Build L3 的要求
• 两者的对应与差异

Signed Releases 检查项评估仓库发布（release）是否经过签名，签名工具可以是 GPG、cosign（配合 sigstore 的 Rekor/Keyless）等。SLSA（Supply chain Levels for Software Artifacts）Build L3 要求更高：不仅要求签名，还要求构建过程可复现、构建产物与源提交绑定、构建元数据可验证、构建平台被强化且不被开发者篡改。因此 Signed Releases 是 SLSA Build L3 的必要不充分条件——签名是 L3 的基础，但 L3 还要求构建可复现与来源可验证。

Scorecard 的 Signed Releases 是 SLSA 合规的组成部分，但达到 SLSA L3 需要更完整的构建可复现性与元数据绑定。理解二者是从"有没有签名"到"构建过程是否可信"的递进。

• 三项检查各自含义
• 它们从哪些环节保障供应链完整
• 代码入口、代码验证、依赖来源三个环节的对应关系

Branch Protection 检查是否对主分支启用了保护规则（如要求 PR 评审、状态检查、禁止直接推送），防止未经验证的代码进入主分支；CI Tests 检查是否配置了 CI 测试（如 GitHub Actions），确保代码变更经过自动化验证；Pinned Dependencies 检查依赖是否固定到具体版本或哈希（如 actions/checkout@v4 或 sha256），防止依赖被替换或篡改。三者从"代码入口（分支保护）、代码验证（CI 测试）、依赖来源（固定版本）"三个关键环节共同保障供应链的完整性。

供应链完整性要求"代码可信、测试通过、依赖可追溯"。这三项分别对应这三个诉求，是 Scorecard 中供应链完整性的核心检查。

• Scorecard 的 probe 架构与本地化
• 私有平台的适配
• 自托管 runner 的使用

Scorecard 默认针对 GitHub 公共仓库，很多探针（probe）依赖 GitHub API。在企业私有 GitLab 或 GHE 上落地时，需要：一是本地化部署 Scorecard CLI（或自建服务），并配置私有仓库的访问凭据；二是适配探针，部分探针（如依赖是否存在、PR 行为）需要原型平台支持，可通过 --local 模式扫描本地 clone 的仓库，或使用自定义探针适配 GitLab 的 Merge Request 模型；三是用自托管 runner 在 CI 中定时运行 Scorecard，将结果写入内部仪表盘或安全平台，形成对私有仓库的持续评估。

私有仓库的落地难点在于探针依赖平台 API，公共仓库的检查模型与私有仓库的 MR/权限模型不完全一致，需要本地化与适配。

• 三档要求的递进关系
• 各档关键判定条件
• 各档是上一档的严格超集

该徽章由 OpenSSF 维护，通过在线问卷形式评估开源项目的安全实践。三档递进：passing（合格）要求满足大部分基础必选项（如公开源码、版本控制、基础文档、基本的测试与许可证）；silver 在 passing 基础上要求全部必选项通过、至少 2 名核心维护者、有安全披露流程、代码审查等；gold 在 silver 基础上要求加密签名发布、主动安全扫描并修复高危 CVE、更严格的测试与文档等。每一档都是上一档的严格超集。

三档设计体现了安全实践从"基本可用"到"高可信"的递进，gold 档通常对应企业级开源软件的高级承诺。

• 100% 通过率的含义
• 核心维护者要求
• 安全披露流程的搭建

Silver 等级要求所有必选项 100% 通过（不能有未满足的必选项），这意味着项目需要完整覆盖版本控制、测试、文档、许可证等基础实践；要求至少 2 名核心维护者，避免单点依赖（Bus Factor），确保项目可持续；要求有安全披露流程，即明确汇报漏洞的渠道（如 SECURITY.md、安全邮件组）和响应承诺。工程上需要通过制度约定、贡献者管理（如 GitHub 的 CODEOWNERS）和安全响应团队来落实。

Silver 档的核心是"项目的可持续性与可响应性"，2 名维护者降低单点风险，安全披露流程保证漏洞能被外界触达。

• 加密签名发布
• 主动安全扫描
• 主动修复高危 CVE

Gold 等级要求更高。加密签名 release 指对发布产物进行数字签名（如 GPG、cosign），确保产物真实、可溯源；主动安全扫描指不仅依赖用户报告，而是主动运行 SAST/DAST/SCA/模糊测试等工具扫描代码与依赖；主动修复高危 CVE 指对发现的高危漏洞在承诺时限内（如 7 天）完成修复并发布。工程上需要将签名、扫描工具集成进 CI/CD，并建立漏洞跟踪与修复 SLA 机制。

Gold 档强调"主动"与"承诺"，是项目安全可信的最高级别体现，需要安全工具链与响应制度的完整支撑。

• Token Permissions 与构建可信度的关系
• Signed Releases 与构建产物可信的关系
• 协同验证的逻辑

SLSA Build L3 要求构建过程可信、可复现且来源可验证。Scorecard 的 Token Permissions 检查 CI 工作流是否使用最小权限 Token，这直接关系到构建过程能否被攻击者滥用（若 CI 用了高权限 GITHUB_TOKEN，攻击者可能篡改构建）；Signed Releases 检查发布产物是否签名，保证产物与源代码件绑定。两者协同：最小权限 Token 保证"构建过程不被篡改"，签名保证"构建产物可溯源"，共同支撑 SLSA L3 的"构建可信 + 产物可信"要求。

协同验证的实质是"过程可信"（Token 最小权限）与"结果可信"（签名）的叠加，二者缺一不可。

• Source L3 的含义
• Code Review 与 Branch Protection 的作用
• 协同逻辑

SLSA Source L3 要求源代码的完整性可信，即提交到主干的内容必须经过验证、来源可追溯。Scorecard 的 Code Review 检查代码是否经过评审，Branch Protection 检查是否禁止直接推送到主分支并强制状态检查。两者协同：Branch Protection 强制"必须经过评审才能合并"，Code Review 保证"评审真实发生"，共同确保进入主干分支的代码可信、可追溯，从而支撑 SLSA Source L3 对源码完整性的要求。

源码完整性需要"强制机制 + 实际执行"双保险，Branch Protection 是强制机制，Code Review 是实际执行，二者协同验证源的可信度。

• Scorecard 指标的定位
• 健康度与安全度的关系
• 侧重安全实践的过程健康度而非单纯活跃度

Scorecard 衡量的是开源项目的"安全健康度"（security health），即通过可自动验证的检查项评估项目在供应链安全方面的实践水平，包括代码审查、依赖更新、漏洞扫描、许可证、签名发布等。它侧重"安全实践的过程健康度"，而非单纯的社区活跃度或代码质量。虽然有些检查项（如维护活跃度）与项目健康相关，但整体定位是安全供应链健康度。

理解 Scorecard 的定位有助于正确使用：它是安全实践中可自动化的"体检清单"，而非万能的质量或安全"成绩单"。

• 四项检查各自含义
• 它们如何反映发布成熟度
• 从产物、打包、漏洞、维护四个维度刻画发布成熟度

Binary Artifacts 检查仓库中是否被提交了二进制/编译产物（通常建议不要提交可执行文件，防止隐藏恶意代码）；Packaging 检查项目是否配置了发布打包（如 npm、PyPI、GitHub Releases 元数据）；Vulnerabilities 检查是否配置了漏洞扫描或依赖漏洞告警；Maintained 检查项目在过去时间内是否有提交活动（反映维护活跃度）。四项共同反映一个项目的"发布成熟度"：是否避免二进制提交、是否规范打包发布、是否持续扫描漏洞、是否保持活跃维护。

发布成熟度不仅指"能发布"，还包括"发布的产物是否干净、是否被扫描、项目是否持续维护"，这四项从不同角度刻画了成熟度。

• Scorecard 的计分方式
• 短板项的影响
• 木桶效应与优先改进高权重短板项

Scorecard 的最终分数是各检查项得分的加权平均，权重由各检查项的重要性决定（如 Code Review、Branch Protection、Dependency Update Tool 等被认为更重要，权重更高）。因此一个短板项（如未启用分支保护）会拉低整体分数，尤其当它是高权重项时影响更明显。这一设计体现了"木桶效应"——供应链安全取决于最薄弱环节。

理解加权机制有助于优先改进高权重短板项，把有限资源投入到影响最大的环节，而不是平均用力。

• 三个层级
• 层级递进关系
• 各层级对安全与工程实践的要求递进

CII Best Practices Badge（OpenSSF Best Practices Badge）分为三个层级：passing（合格）、silver（银级）、gold（金级）。每一层是上一层的严格超集，要求更全面、更严格的安全与工程实践。passing 是基础门槛，silver 强调可持续性与安全披露，gold 强调主动安全与签名发布。项目可逐级申报，展示其安全实践水平。

层级递进设计让项目能渐进式提升安全实践，并对外展示可信度。

• 评分的解读方法
• 改进策略
• 把评分纳入 CI 持续监控以防回退

解读供应链评分（如 Scorecard 分数）时应先看各项检查的明细而不只看总分，识别短板项；再结合业务风险判断哪些项最需要优先改进（如高风险项目优先解决分支保护、依赖更新）。改进上要有节奏：先修复影响最大的高权重项（如启用分支保护、配置依赖更新工具），再逐步补齐其他项，并把评分纳入 CI 持续监控，避免回退。

评分是诊断工具而非目标，正确做法是"先诊断、再按优先级改进、后持续监控"。

• Scorecard 的 CI 接入方式
• 持续监控机制
• 评分门禁与低于阈值告警

Scorecard 可通过 GitHub Action（ossf/scorecard-action）在 CI 中运行，将结果作为 job 的 test 输出，也可配置为当评分低于阈值时告警（如极低分阻断合并）。持续监控上，可将每次运行的结果写入 dashboard 或漏洞管理平台，定期对比分数变化，结合 Dependabot、CodeQL 等形成统一的安全监控视图。对私有仓库可用自托管 runner 定时扫描。

CI 接入让评分"流入"开发流程，监控让分数"可追溯变化"，二者结合避免评分"一次性"与"无人跟进"。