给开源依赖做准入前，我会先用 OpenSSF Scorecard 跑一遍安全体检
AI 应用和云服务项目很容易把依赖评估压缩成两个动作：看 Star 数，再跑一次漏洞扫描。这个动作太薄了。真正会影响上线风险的，还包括维护是否停滞、默认分支有没有保护、CI 是否覆盖关键路径、workflow token 是否过大、发布物有没有签名、仓库里是否混进二进制产物。OpenSSF Scorecard 的价值就在这里：它把这些开源项目健康信号做成自动化检查，先给团队一张可讨论的风险清单。
从候选仓库到自动检查、风险分层、修复清单和定期复扫的轻量流程 来源：Codex image generation
适合放在哪个环节
我会在依赖准入前先跑 Scorecard，事故复盘后再补通常已经太晚。比如团队准备引入一个新的 SDK、GitHub Action、CLI 工具或基础镜像构建组件时，先把候选仓库跑一遍 Scorecard。结果不直接替代人工判断，但能迅速提示哪些问题需要继续追问：项目最近是否仍在维护，是否声明安全策略，默认分支是否要求 review，依赖是否有更新工具，CI token 是否保持只读，是否存在已知漏洞。
OpenSSF 官方说明里写得很清楚，Scorecard 会通过一组自动化 checks 评估开源项目安全风险，每项检查给出 0 到 10 分，并提供风险级别和修复提示。它支持两种常见入口：对自己拥有的仓库用 GitHub Action 持续扫描，对外部候选项目用 CLI 做一次性评估。公开仓库使用 Scorecard Action 也有免费入口，私有仓库则要按 GitHub 的安全功能条件处理。
不要只盯总分
Scorecard 有 aggregate score，但准入时只看总分会误导。一个项目可能因为没有 fuzzing 或 CII badge 失分，但你的场景真正关心的是默认分支保护、危险 workflow、Token 权限和漏洞状态。反过来，总分看起来不差，也可能藏着和你部署方式强相关的短板。我的做法是把结果拆成三组：高风险阻断项、可接受但要记录的项目特性、后续可以帮上游改进的维护项。
高风险阻断项通常包括已知漏洞未处理、workflow 有危险模式、默认分支缺少保护、release 缺少可信发布路径、CI token 权限过大。可接受项则要结合项目体量看，例如小工具没有 fuzzing 未必立即阻断，但要在依赖账本里写明。维护项可以变成上游 issue 或内部替代方案观察点，避免准入结论在三个月后失效。
落地成一张轻量清单
第一步，为每个候选依赖保存 Scorecard 输出、仓库地址、版本范围和评估日期。第二步，把高风险 checks 映射到团队自己的政策，比如默认分支保护和只读 token 是必须项，安全策略和依赖更新工具是建议项。第三步，把准入结论写进依赖台账，标明允许使用、暂缓引入或需要替代方案。第四步，对已经进入生产路径的关键依赖做定期复扫，因为维护状态、漏洞和 workflow 配置都会变化。
这套流程的重点是把开源依赖从“感觉可信”推进到“有证据可追踪”。Scorecard 不能证明一个项目绝对安全，也不能替代代码审计和威胁建模，但它能把许多可机器检查的实践提前暴露出来。对小团队来说，这已经足够把依赖选择从口头经验变成可复盘的工程记录。