SLSA框架中的构建缓存污染威胁分析与防护方案

构建缓存安全威胁概述

在软件供应链安全领域，构建缓存机制虽然能显著提升构建效率，但同时也引入了潜在的安全风险。SLSA框架特别指出了"构建缓存污染"这一重要威胁，攻击者可能通过操纵缓存内容来破坏构建过程的完整性。

构建缓存污染的两大攻击类型

1. 哈希碰撞型攻击

这类攻击源于缓存键设计不完善，未能完整覆盖所有构建输入的传递闭包。典型场景包括：

• 仅基于源代码文件哈希生成缓存键，忽略了编译器命令行参数
• 未将编译器二进制本身的哈希纳入缓存键计算
• 构建环境变量等隐式依赖未被正确包含

攻击者可利用这种缺陷实现持久化攻击。例如，通过精心构造的编译器参数注入恶意代码，当后续构建误用被污染的缓存时，就会引入安全隐患。

2. 真实性缺失型攻击

这类攻击更为直接，攻击者利用构建环境对缓存的完全写入权限，提前预测并伪造合法缓存键对应的内容。即使缓存键设计完善，只要写入过程不受控，攻击者就能：

• 预先计算未来构建可能使用的缓存键
• 直接向缓存注入恶意构建产物
• 绕过实际构建过程验证

构建缓存安全防护方案

针对哈希碰撞的防护

完整输入覆盖原则：缓存键必须包含所有构建输入的传递闭包，包括：

• 源代码文件内容
• 编译器及工具链版本
• 构建命令参数
• 环境变量等隐式依赖

参考实现：Bazel的远程构建缓存机制通过严格的密封性设计，确保所有输入都被正确纳入缓存键计算。

针对真实性缺失的防护

写入权限控制：将缓存写入权限限制在可信构建平台内部，确保：

• 每个缓存条目都真实对应其键值
• 外部实体无法直接操作缓存内容

验证机制增强：可采用类似SLSA L3级别的验证方案，为每个缓存条目生成可验证的证明，确保其构建过程的真实性。

实践建议

对于构建系统设计者和使用者，建议：

1. 严格审计现有构建缓存机制，检查是否存在上述两类漏洞
2. 优先选择支持完整输入覆盖的构建系统
3. 实施细粒度的缓存访问控制策略
4. 考虑为关键构建环节禁用缓存机制

通过实施这些防护措施，可以显著降低构建缓存被滥用的风险，保障软件供应链的安全可靠。