开源项目Scorecard中签名发布检查功能的问题分析

在开源软件供应链安全领域，签名发布是一个重要的安全实践。OSS Scorecard项目作为评估开源项目安全性的工具，其"Signed-Releases"检查项用于验证项目是否对其发布版本进行了加密签名。然而，近期发现该功能存在一个关键问题：即使项目中存在.sigstore签名包，检查结果仍显示未签名。

问题背景

Scorecard的Signed-Releases检查项旨在评估项目是否对其发布版本进行加密签名。根据设计，当项目最近5个发布版本都包含签名时，该项应获得8分(满分10分)。但在实际使用中发现，即使项目使用sigstore/gh-action-sigstore-python等工具生成了.sigstore签名包，检查结果仍显示0分，并报告"0 out of 5 artifacts are signed or have provenance"。

技术分析

该问题源于Scorecard版本更新滞后。虽然修复代码已于5个月前合并，但由于Scorecard项目本身在此期间没有发布新版本，导致修复未能及时生效。具体表现为：

1. 签名验证逻辑未能正确识别.sigstore格式的签名包
2. 检查结果错误地将有效签名标记为未签名状态
3. 影响所有使用sigstore工具链进行签名的Python项目

解决方案

项目维护团队采取了以下解决措施：

1. 在即将发布的v5.0.0版本中包含该修复
2. 先行发布候选版本(v5.0.0-rc1和v5.0.0-rc2)包含修复
3. 更新scorecard-action至v2.3.3版本，确保通过GitHub Action使用的用户能获得修复

最佳实践建议

对于开源项目维护者：

1. 定期检查Scorecard评估结果，验证签名状态是否被正确识别
2. 考虑使用最新版本的Scorecard或等待v5.0.0正式发布
3. 保持发布签名的连续性，确保每个版本都包含有效的签名

对于安全评估人员：

1. 了解Scorecard版本对检查结果的影响
2. 手动验证签名状态作为补充，特别是对于关键项目
3. 关注Scorecard的更新动态，及时获取最新功能改进

该问题的解决将提升Scorecard在评估项目发布签名实践方面的准确性，进一步强化开源软件供应链安全评估能力。