OSSF Scorecard 项目安全检查详解
项目概述
OSSF Scorecard 是一个开源项目安全评估工具,它通过一系列自动化检查来评估开源项目的安全状况。本文将深入解析 Scorecard 中的各项安全检查指标,帮助开发者理解每个检查项的重要性、风险等级以及改进建议。
二进制文件检查 (Binary-Artifacts)
风险等级:高
核心问题:源代码仓库中包含可执行二进制文件会带来安全隐患。
技术解析:
- 二进制文件无法像源代码一样被审查,可能存在未经验证的代码或被篡改的风险
- 长期来看,二进制文件可能与源代码版本不一致
- 包含预编译二进制文件可能导致构建流程退化
允许的例外情况:
- 既是源代码又可执行的文件(如shell脚本)
- 由工具生成的源代码(如bison/yacc生成的代码)
- 生成的文档文件
改进建议:
- 从仓库中移除所有生成的二进制文件
- 坚持从源代码构建的原则
- 建立自动化构建流程
分支保护检查 (Branch-Protection)
风险等级:高
核心问题:未受保护的分支容易遭受未授权代码注入。
保护机制详解:
分级保护要求
第一级要求(3/10分):
- 禁止强制推送(force push)
- 禁止分支删除
第二级要求(6/10分):
- 合并前至少需要1位审核者批准
- 要求通过PR提交变更
- 合并前要求分支为最新状态
- 要求批准最近的推送
第三级要求(8/10分):
- 合并前至少通过1项状态检查
第四级要求(9/10分):
- 合并前至少需要2位审核者批准
- 要求代码所有者参与审核
第五级要求(10/10分):
- 推送新提交时取消过期的审核
- 要求管理员参与审核
改进建议:
- 在代码托管平台启用分支保护规则
- 根据项目安全需求逐步实现更高级别的保护
CI测试检查 (CI-Tests)
风险等级:低
核心问题:缺乏自动化测试可能导致未知问题进入代码库。
技术实现:
- 检查最近约30次提交中的CI系统运行记录
- 支持的CI系统包括:Appveyor、Buildkite、CircleCI、GitHub Actions等
注意事项:
- 目前仅支持GitHub平台
- 可能无法检测所有类型的CI测试实现
改进建议:
- 在仓库中添加测试脚本
- 将测试与CI/CD平台集成
- 确保每个PR都会触发测试
开源最佳实践检查 (CII-Best-Practices)
风险等级:低
评估标准:
- 金级认证:10分
- 银级认证:7分
- 通过认证:5分
- 进行中:2分
改进建议:
- 注册OpenSSF最佳实践项目
- 根据项目实际情况逐步满足各项要求
代码审核检查 (Code-Review)
风险等级:高
核心问题:缺乏代码审核可能导致问题或未经验证的代码进入项目。
评分机制:
- 未审核的机器人提交:扣3分
- 未审核的人工提交:单次扣7分,多次额外扣3分
注意事项:
- AI/ML机器人的审核不计入有效审核
- 小型项目可能难以满足所有变更都需审核的要求
改进建议:
- 招募更多维护者参与审核
- 在仓库设置中强制要求代码审核
- 对管理员/代码所有者同样实施审核要求
贡献者多样性检查 (Contributors)
风险等级:低
评估标准:
- 最近30次提交中,来自至少3个不同组织的贡献者
- 每个组织贡献者至少有5次提交
注意事项:
- 小型或专业项目可能难以满足此要求
- 仅支持GitHub平台
危险工作流检查 (Dangerous-Workflow)
风险等级:严重
核心问题:危险的工作流配置可能导致仓库被未授权访问。
检测模式:
-
不受信任的代码检出:
- 检查是否在
pull_request_target
或workflow_run
触发的工作流中显式检出PR代码 - 这类工作流具有写入权限和访问密钥的能力
- 检查是否在
-
脚本注入风险:
- 检测工作流内联脚本是否可能执行未经验证的输入
- 如直接将
github.event.issue.title
等上下文变量注入可执行代码
改进建议:
- 审查所有工作流配置
- 避免在危险触发条件下检出不受信任的代码
- 对上下文变量进行严格过滤和转义
总结
OSSF Scorecard 提供了一套全面的开源项目安全评估体系,开发者可以通过这些检查项了解项目的安全状况并有针对性地进行改进。每个检查项都针对特定的安全风险,从高风险的代码审核和分支保护,到低风险的贡献者多样性,形成了一个完整的安全评估框架。
实施这些安全措施时,开发者应根据项目实际情况和资源条件,优先处理高风险问题,逐步完善项目的安全防护体系。
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考