SLSA框架中如何处理源代码跟踪中的子模块问题

在软件开发过程中，Git子模块(submodule)是一种常见的代码组织方式，它允许将一个Git仓库作为另一个Git仓库的子目录。这种机制虽然方便，但在软件供应链安全领域，特别是SLSA(Supply-chain Levels for Software Artifacts)框架下，却带来了源代码跟踪(source-track)方面的特殊挑战。

子模块的本质与安全考量

从技术角度看，Git子模块本质上只是包含在其他仓库中的特殊文件(.gitmodules文件)。这些文件记录了外部仓库的引用信息。当开发者使用git clone --recurse-submodules命令时，Git会根据这些引用信息自动克隆所有相关的子模块仓库。

在SLSA框架下，我们需要特别关注的是：这些子模块是否应该被视为构建过程的一部分？如果是，应该如何记录和验证它们的来源和完整性？

SLSA级别与子模块的关系

SLSA的一个重要原则是安全级别不具有传递性。这意味着：

1. 即使主仓库达到了SLSA Level 3的安全要求，它所引用的子模块仓库可能只满足Level 1
2. 这种差异不会自动降低主仓库的安全等级
3. 每个子模块仓库的安全等级需要独立评估

这一原则确保了安全评估的精确性，避免了因为一个低安全级别的子模块而错误地否定整个项目的安全状态。

解决方案：显式声明子模块依赖

为了确保源代码跟踪的完整性，SLSA建议构建系统应该：

1. 将所有子模块仓库明确列为"resolvedDependencies"(已解析依赖项)
2. 为每个子模块提供完整的来源证明
3. 在构建证明中清晰记录每个子模块的使用情况

这种做法使得软件包验证者能够：

• 明确知道构建过程中使用了哪些外部代码
• 独立验证每个子模块的来源和完整性
• 根据项目需求设置适当的安全策略

实施建议

对于希望在SLSA框架下处理子模块的项目，建议采取以下措施：

1. 在构建配置中显式声明所有必要的子模块
2. 确保构建过程能够捕获所有子模块的精确版本信息
3. 在生成的SLSA证明中包含完整的子模块依赖树
4. 为关键子模块设置适当的安全等级要求

通过这种方式，项目可以在利用子模块带来的便利性的同时，不牺牲软件供应链的安全性和可审计性。