SLSA框架中源代码追踪要求的优化与重构思考

在软件供应链安全领域，SLSA框架作为一套成熟的安全标准，其源代码追踪（Source Track）要求对于保障软件构建过程的完整性至关重要。近期社区对现有规范中的"强制变更管理流程"要求提出了优化建议，这反映了实际落地过程中对规范可操作性的深度思考。

当前规范存在的挑战

现有SLSA v1.1规范将"强制变更管理流程"定义为源代码控制系统（SCS）需要提供组织额外要求的能力。这种表述方式在实践中可能产生两个主要问题：

1. 责任边界模糊：规范侧重SCS的能力提供，但未明确构建平台实际执行这些控制措施的义务
2. 消费者预期不明确：缺乏对保护分支技术控制措施的标准化描述，导致下游消费者难以建立统一的安全预期

架构优化的三个方向

1. 强化SCS的执行义务

建议参照"隔离强度"要求的表述方式，明确要求构建平台必须强制执行组织定义的技术控制措施。这种表述转变将：

• 从"能力提供"升级为"强制实施"
• 明确SCS在变更管理中的主动执行角色
• 与技术控制的实际落地场景更好对齐

2. 明确生产者的分支保护责任

当前规范将保护分支的定义放在SCS要求中，建议调整为：

• 在L2及以上级别要求生产者显式声明保护分支
• 建立分支保护策略与构建级别的对应关系
• 为消费者提供透明的分支保护状态可见性

3. 标准化技术控制要求

建议在生产者要求中增加技术控制规范，可采用两种实现路径：

• 直接定义消费者可预期的标准控制措施（如强制代码审查、CI检查等）
• 要求生产者通过策略声明明确控制措施，由SCS强制执行

实施影响分析

这种架构调整将带来多重效益：

1. 责任分离更清晰：SCS负责执行，生产者负责声明，消费者获得透明性
2. 安全基线更明确：通过标准化技术控制要求，建立可验证的安全基准
3. 落地更可操作：减少规范解读的歧义，提升不同实现之间的一致性

未来演进建议

该优化方向与SLSA源代码POC中的"策略"概念高度契合，建议后续：

1. 建立策略执行的标准接口
2. 定义常见技术控制的元数据规范
3. 开发配套的验证工具链

这种架构演进将使SLSA规范在保持灵活性的同时，提供更强的实施指导性和可验证性，最终提升整个软件供应链的安全水位。