OSSF Scorecard 探针设计优化：从工具枚举到分类检测的演进

在软件供应链安全评估领域，OSSF Scorecard 作为重要的自动化评估工具，其探针（probe）机制的设计直接影响着评估的准确性和可维护性。本文将深入分析当前探针设计中存在的工具枚举问题，并提出向分类检测转变的优化方案。

当前探针设计的挑战

Scorecard 现有的探针机制面临三个主要问题：

1. 代码重复严重：每个工具的检测都需要独立的探针实现，导致大量重复代码。例如在模糊测试检测中，每种语言特定的模糊测试工具都需要单独实现，造成约250行/工具的模板代码。

2. 测试脆弱性：新增工具检测需要同步修改多处测试代码，否则会触发UniqueProbesEqual检查失败。

3. 警告冗余：用户会收到未使用每个工具的独立警告，而非针对工具类别的综合评估。

分类检测方案设计

我们建议将探针问题重构为"项目是否使用了X类工具"，而非"项目是否使用了X类中的Y工具"。这种转变带来以下改进：

数据结构优化：

type Finding struct {
    Values map[string]string  // 从int改为string类型
    // 其他字段保持不变
}

检测结果示例：

{
    "probe": "fuzzed",
    "outcome": "Positive",
    "values": {"tool": "QuickCheck"}
}

技术实现考量

类型系统改进

原设计的map[string]int存在明显局限：

• 只能表示数值型指标
• 对非数值数据需要变通处理（如将分支名放在key中）
• 类型转换增加复杂度

改为map[string]string后：

• 保持简单性的同时提高灵活性
• 数值可通过字符串表示（如"90"）
• 支持任意分类标签和工具名称

评估逻辑调整

评估层需要相应修改：

1. 分类探针需要收集并记录具体工具信息
2. 评分规则改为基于类别而非具体工具
3. 结果展示需要聚合同类工具检测

方案优势分析

1. 可维护性提升：

   • 减少90%的探针实现代码
   • 消除工具新增时的测试修改负担
   • 降低未来扩展新工具的成本

2. 用户体验改善：

   • 提供更简洁的评估结果
   • 避免重复警告
   • 保持修复建议的针对性（通过附加文档）

3. 架构灵活性：

   • 为未来探针扩展预留空间
   • 支持更丰富的元数据记录
   • 便于下游结果处理和分析

实施路径建议

1. 首先完成Finding结构的类型变更
2. 逐步迁移现有探针到分类模式
3. 更新评估逻辑和测试用例
4. 完善文档和示例说明

这种演进式改进可以在保持兼容性的同时，显著提升Scorecard的代码质量和用户体验，为后续的功能扩展奠定更好的基础。