SLSA框架中关于源代码合并策略的技术探讨

在软件开发过程中，代码合并策略的选择一直是一个备受争议的话题。SLSA（Supply-chain Levels for Software Artifacts）框架作为软件供应链安全的重要标准，其源代码验证规范中对合并策略的要求引发了社区讨论。

合并策略的安全考量

传统的代码合并方式主要分为两种：squash+merge（压缩合并）和普通merge（保留历史合并）。从安全角度来看：

1. squash+merge的优势：

   • 简化历史记录，只保留经过审核的最终变更
   • 减少中间可能存在的恶意或错误提交的风险
   • 更清晰地展示经过验证的代码状态

2. 保留历史合并的优势：

   • 完整保留开发过程中的修改轨迹
   • 可以追溯审查过程中发现和修复的问题
   • 保留每个提交的数字签名信息

社区实践与技术现实

在实际开发中，不同社区对合并策略有着强烈的偏好：

• 许多开源项目坚持保留完整提交历史，认为这是代码审查过程的重要记录
• 企业级项目可能更倾向于squash+merge，以简化审计和追踪
• 现代代码审查工具通常默认显示净差异，而非逐个提交审查

SLSA框架的技术权衡

经过社区讨论，SLSA框架决定不强制要求squash+merge策略，主要基于以下考虑：

1. 兼容性需求：强制要求特定合并策略会阻碍许多项目采用SLSA标准
2. 验证可行性：只要能够明确标识哪些提交符合验证要求（保留、归属等），其他策略也可接受
3. 灵活性原则：允许项目根据自身需求选择最适合的合并方式

安全验证的关键点

无论采用何种合并策略，SLSA框架关注的核心是：

• 能够明确区分已验证和未验证的提交
• 确保所有最终合并的代码都经过适当审查
• 提供清晰的验证信息供下游消费者判断

最佳实践建议

对于关注供应链安全的项目：

1. 如果采用保留历史的合并方式，应确保审查过程覆盖所有提交
2. 考虑在合并提交中添加验证签名
3. 明确文档记录项目采用的合并策略及其安全影响
4. 让下游消费者能够了解项目的合并实践

SLSA框架的这一决策体现了在安全严格性和实践灵活性之间的平衡，为不同开发模式的项目提供了采用供应链安全标准的空间。