近年来，从SolarWinds攻击到Log4j漏洞，软件供应链安全事件层出不穷，动辄影响数百万用户。开发者越来越意识到：仅仅依赖数字签名验证最终软件包是远远不够的——攻击者可能在构建流程的任何环节植入恶意代码。正是在这一背景下，由纽约大学、卡内基梅隆大学等研究机构联合开发的In-toto框架脱颖而出，成为保障软件供应链完整性的重要技术方案。
何为In-toto？
In-toto是一个开源软件供应链完整性安全框架，现已被云原生计算基金会（CNCF）孵化。其核心理念是：软件供应链的每个步骤，从源代码提交、编译构建、测试验证到签名发布，都应当被记录、验证并可追溯。In-toto通过定义明确的元数据“布局”（layout），让软件项目所有者能够精确指定谁有权执行哪些操作，以及每个步骤产生的结果必须满足什么条件。
简而言之，传统安全方案只检查最终制品是否被篡改，而In-toto则对整个“生产过程”进行监管。
工作机制：布局、步骤与链接
In-toto框架包含三个核心概念：布局、步骤与链接。
- 布局：由项目负责人签名创建，是一份“安全策略”文档。它定义了供应链中所有允许的步骤（如“编译”、“单元测试”、“打包”），每个步骤的责任人（使用其公钥标识），以及步骤之间的依赖关系。布局还包含对最终制品的预期校验和等检验规则。
- 步骤：布局中声明的每一个具体操作。每个步骤由相应的执行人完成，执行人使用自己的私钥对步骤产生的元数据——即“链接”文件（link metadata）进行签名。
- 链接：记录了某一步骤的详细信息，包括输入（源代码版本、依赖库）、输出（生成的二进制文件、测试报告）、命令、运行环境等。链接文件被签名后，任何人都无法否认或篡改。
当消费者（如CI/CD系统或最终用户）收到一个软件包时，In-toto会要求提供完整的链接文件链和布局。然后通过验证每个链接的签名是否与布局中指定的责任人匹配，以及步骤顺序和制品哈希是否符合布局规则，来判断整个供应链是否完整可信。
为何重要：从“信任节点”到“信任流程”
传统做法中，软件发布者会对最终制品（如Docker镜像或安装包）进行签名，用户只需要验证这个签名。但这样存在一个盲区：签名本身并不能保证二进制文件在构建过程中没有被植入后门。攻击者可以入侵构建服务器、篡改编译脚本，甚至污染上游依赖，最终由合法签名者签发一封“干净”的证书。
In-toto将信任从“最终节点”扩展到了“完整流程”。它强制供应链各方对自身行为负责，并留下不可伪造的证据。例如，即使构建服务器被攻破，若攻击者无法获得负责“构建”步骤的执行人私钥，就无法生成合法的链接文件，最终验证会失败，从而被用户察觉。
实际应用与生态集成
In-toto已被多个重要项目采纳。例如，Sigstore项目（负责代码签名与验证）利用In-toto记录构建流水线；TUF（The Update Framework）与In-toto结合，可同时保证更新分发渠道的完整性和供应链步骤的可审计性。在Kubernetes生态中，In-toto被用于验证OCI（容器镜像）构建过程的完整性，确保镜像不是由恶意节点生成。
此外，GitHub Actions、GitLab CI等CI/CD平台也提供了In-toto集成插件。开发者只需在流水线中插入几个步骤，就能自动生成和验证元数据。例如，美国国家安全局（NSA）发布的“软件供应链安全指南”就明确推荐使用In-toto配合硬化CI/CD管道。
挑战与未来
尽管In-toto理念先进，普及仍面临挑战：一是要求供应链各参与方都掌握并管理密钥，增加了运营复杂度；二是元数据需要在存储和传输过程中保持可用，对基础设施有一定要求。为此，社区正推进与OIDC（OpenID Connect）等身份协议的结合，以简化密钥分发；同时开发“Inspector”等工具，自动收集和验证元数据。
随着NIST SP 800-218（安全软件开发框架）和欧盟《网络弹性法案》对供应链透明性提出强制性要求，In-toto作为成熟的开源方案，有望成为行业标准。毕竟，在数字信任崩塌的时代，证明“怎么做”比证明“是谁做的”更重要。