点评软件供应链安全框架 in-toto 的审计结果
在笔者之前一篇关于软件供应链安全的文章中，带出了 in-toto 这个软件供应链安全框架。这个项目在 2023 年 2 月进行了项目规范及源代码审计，审计结果已公布在项目网站上。无论是开发者或网络安全管理人员，本着DevSecOps的精神都值得认真一读。
笔者：国际认证信息系统审计师、软考系统分析师
本篇全文近6千字，需要有软件供应链安全知识的基础。
对 in-toto 不了解的读者可以先看看笔者之前的软件供应链文章：
软件供应链安全继续强化：SBOM清单基座规范SBOMit启动制订
in-toto 的审计结果和审计报告发布在如下网址：
in-toto | Security Audit '23
https://in-toto.io/security-audit-23/
https://in-toto.io/2023-security-audit-report.pdf
执行审计的机构是 X41 D-Sec GmbH（https://www.x41-dsec.de/）。根据项目组发布的内容可知，安全审计包括了两方面内容：
（1）对 in-toto 框架规范的架构审查
（2）对 in-toto 在 Python 和 Go 两种语言的具体实现的源代码审计。
据项目组说明，虽然 in-toto 规范之前已经接受了 CNCF 的 TAG-Security 的安全审查，但并没有经过正式的审计。鉴于 in-toto 规范已经成熟并且获得实际应用，项目决定通过审计强化规范的可靠性，并发布规范的 1.0 版本。
参考 in-toto 项目组的动机，理论上任何软件架构框架、开发项目都应当适时引入外部安全审计，通过源代码级别的外部审计提高架构设计和代码实现的安全性，从而应对当前网络安全的严峻态势。
在实践中，暂不管甲方（项目拥有者）是否有足够的财务能力开展外部安全审计，问题的关键实际是在于安全审计服务方这一边，是否确实有能力提供基于源代码的安全审计服务。
源代码安全审计主要有两大方向：基于开发语言和运行环境的弱点和漏洞和基于业务逻辑的弱点和漏洞进行审计，难点在后者。
业务逻辑，可以是被审计的软件框架的设计逻辑，或软件所支撑的生产业务的运行逻辑。执行审计的人如果没有该领域足够的知识储备，是难以判断出被审计的对象是否存在弱点或漏洞。知识储备一般是来自于相关的从业经验，但仅凭年资还不足够说明。
就比如笔者本人。如果是审计自己熟悉的第三方实验室行业及其延伸相关领域（实验室供应链相关上游的制造业或服务业、下游的信息消费者）的软件项目，可谓是小菜一碟。
但如果是自己完全不熟悉的行业领域，审计能力就主要存在于第一种方向，即开发语言和运行环境的弱点和漏洞。在业务逻辑方面虽然可以借鉴参考已有的经验，比如重点放在财务和内控，然后以审计思维结合信息系统充分发散，但依然难以保证能完全覆盖。
因此，甲方在甄选外部安全审计服务商时，有必要直接和服务商的审计师进行直接交流，以判断服务商是否确实具备充足的审计能力。
在 in-toto 的安全审计最终报告中，审计人员的总体结论认为源代码的质量非常好，同时就 in-toto 框架规范的总体设计和参考实现代码的结构提出了8个问题，包括1个被标记为高严重程度问题、4个被标记为中严重程度问题以及3个被标记为低严重程度问题。此外，报告中还列出了几个与 in-toto 框架安全性无关的信息性发现。
in-toto 项目组在 GitHub 的项目中为安全发现创建了 Advisor 条目，为信息性发现创建了 Issue 条目。
在笔者看来，项目组以发现的问题的性质，区分处理的方式大体上还是恰当的。项目组有着如下的前置说明：
所有安全相关问题都可以通过正确使用 in-toto 框架或通过充分理解 in-toto 框架的适用范围来获得缓解。因为个别定性为高严重性的安全问题实际是一种现实中必须如此的使用模式，且已持续如此了一定时间。因此项目组的修复措施首先是在规范和使用文档中的相关澄清说明。
网络安全规范在定义和遵循之间存在理想和现实的差距，每一个网络安全从业人员对此都应该有所体会。理想中的完全安全到了现实的实践总会有折中。网络安全也和软件工程一样，无法在赛博空间中穷尽现实世界的一切变化。
这也是缸中之脑大概不可能实现的理由。
审计报告和项目组的解释内容都有相似的特点：概括性的精炼简洁。要看懂内容，需要熟悉软件企业内部供应链组成、软件构建过程管理、软件构建环境情况等要素。
在技术专业性之外，还可以从审计员对发现的描述和定级结果中体会到审计员的独立性。即使项目组对于某些发现的解释是显得比审计员更有道理，但审计员认定的发现和定性并不会因此而撤回。
https://github.com/in-toto/docs/security/advisories/GHSA-wqrg-wjp9-wqfq
审计发现：in-toto 没有检查文件元数据的完整性。这可能容许攻击者对最终产品（即构建产生的成品软件）实现特权升级或降级。
项目组解释：in-toto 的设计目的是保护软件构建产物内容的完整性而不是产物的元数据。但如审计人员所建议的，供应链的所有者可以自由地选择特定的文件容器格式提升其功能特性，比如把文件的权限作为文件内容的一部分，从而使文件的元数据加入到 in-toto 的保护范围。
笔者评论：很明显，审计人员所考虑的范围更广。审计员认为文件的完整性应包括文件的元数据，即文件的创建时间、访问权限和所有者信息等。元数据是有可能随着软件文件被打包而分发到用户的系统环境上的，比如在 Linux 环境使用 tar 进行打包，文件的访问权限是会默认被带入 tarball，并在提取文件时还原。如果文件被攻击者篡改后特意设置了可执行属性并被打包分发，则该被篡改文件在所分发的目标环境获得运行机会的难度就少了。
这种情况的可能性在 Windows 环境相对小点，但也不是不可能发生，取决于打包软件。
由于这个发现超出了软件构建过程本身，更多地和操作系统环境、软件分发相关，所以 in-toto 项目组让供应链的所有者（也就是 in-toto 框架的使用者）自行判断是否需要通过使用（或自行设计实现）某种文件容器，把文件元数据也纳入到保护范围。
详细地说，就是这种文件容器能把文件内容和文件元数据捆绑容纳在内。当软件构建过程产生成品软件的组成文件时，不再直接输出为操作系统所管理的文件，而是把文件内容和与之匹配的元数据输出到文件容器，由容器去承载和保护供应链产生的成品软件。
https://github.com/in-toto/in-toto/security/advisories/GHSA-wc64-c5rv-32pf
CVE: CVE-2023-32076
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-32076
审计发现：参考实现代码中的链接生成工具可以被配置为使用存储在遵循 XDG 基目录规范的目录中的 RC 文件进行配置。而该配置文件是位于 in-toto 运行目录中的名为“.in_totorc”的隐藏文件（笔者注：在 Linux 环境以.开头的是隐藏文件）。如果攻击者控制了软件构建过程步骤的输入，则其可以通过设置或篡改该隐藏文件，为供应链构建过程增加对物料或产物的排除、屏蔽等过滤条件而逃避检测。
项目组解释：这是“职责实体（Functionaries）不执行验证”的一种特殊情况，如后文所述。项目组与 in-toto 框架的采用者交流后发现用户通常使用API参数或CLI参数设置 in-toto 配置，而很少使用 RC 配置文件。因此，项目组从参考实现中删除了与 RC 配置文件相关的功能。
笔者评论：首先还是要吐个槽，英文的多义词其实很不好理解。Functionary 这个词如果按词典翻译为公职人员、官员就显然会显得很可笑。就算翻译为职责人员都会导致误解。在笔者认为，这 Functionary 在软件供应链中并不一定是人，也可以是执行软件构建过程某项工序的一段程序、脚本。所以我将其命名为“职责实体”，当然程序和脚本的错误，最后都还是要有人来背书。
对于该中等严重性发现，项目组接受并确认为漏洞性质，提交给 MITRE 后被接受为编号 CVE-2023-32076。
使用 RC 文件作为配置文件，而且是隐藏性质的文件命名，确实是比较老派的做法。这种直接在运行目录里面扔配置文件的做法，让人联想到Apache Web Server 在 WEB 文件目录里面放 .htaccess 的做法。而这个 .htaccess 的做法现在已经被公认为不是良好的网络安全实践了，且 .htaccess 的配置解析还曾经出过漏洞（比如CVE-2017-9798）。所以审计人员指出这是个安全问题，是完全有道理的。
项目组在考虑如何修改调整前，还跟用户进行了交流，以使用者反馈为调整的依据，进行了比较彻底的整改。这也是项目组的审慎态度。如果调整影响到大多数用户，那么这就还是刚才说的理想和现实的问题，项目组就要想其它办法折中处理，而不能一删了之。
https://github.com/in-toto/docs/security/advisories/GHSA-73jv-h86v-c2vh
审计发现：攻击者可以重放尚未过期，但已被替换的旧布局（笔者注：即构建环境）。如果旧的布局中存在漏洞，则攻击者就可以反复利用。建议增加版本号管理布局，为用户提供检测和选用布局的方法。
项目组解释：我们认为这超出了 in-toto 的范围，并已经更新了规范，明确地将此标注为并非 in-toto 要实现的目标。相应地，ITE-2 和 ITE-3 是两个“可接受的” in-toto 增强功能，它们详细说明了更新框架（The Update Framework，TUF，https://theupdateframework.io/）如何与 in-toto 一起使用，以抵御布局重放攻击。
相关链接：
https://github.com/in-toto/ITE/blob/master/ITE/2/README.adoc
https://github.com/in-toto/ITE/blob/master/ITE/3/README.adoc
笔者评论：审计发现的详细意思是，如果构建环境是动态产生和管理其生命周期的，那么 in-toto 框架没有清晰地管理到构建环境的生命周期（布局文件内只有过期时间而没有版本号），这就存在被攻击者超越而加以利用的可能。供应链管理除了物流管理之外，对构建过程的安全管理也非常重要，
可以参考太阳风事件中，该公司就是软件的构建过程被劫持利用而被持续篡改软件的最终产品。重温一下笔者对太阳风事件的看法：
但项目组的解释我倒不是很认同。基于版本号的布局管理，确实比只有过期时间更清晰。而关键的是，项目组的解释直接把该问题和 TUF 划等号，这属于在主观上降低了风险的作用范围，在审计角度是不可取的。
https://github.com/in-toto/docs/security/advisories/GHSA-6q78-j78h-pqm2
审计发现：链接元数据文件并不固定地绑定到布局上。这可能允许攻击者通过用早期版本的链接文件替换现在的链接文件来重放步骤。建议对布局文件施加 GUID，然后链接文件通过 GUID 绑定引用布局文件。
项目组解释：这个问题可以通过在布局中使用全局唯一的步骤名来缓解。但是，规范并没有强制要求这样，因为链接元数据重用，例如对于不同的供应链，或独立于任何供应链生成链接元数据，是有效的用例。此外，如前所述，ITE-2 和 ITE-3 被设计为防止不允许的元数据重用。
笔者评论：这个问题也同于属于布局重放。审计人员的着重点在于操作系统的文件系统中，链接（笔者注：也就是用 ln 命令所创建的）是脆弱的，易于修改的，因此会存在被利用的可能。
由于都是布局重放的问题，所以项目组用了和上一问题同样的应对办法，甚至提议了更弱一些的缓解措施比如用时间戳，又或者避免重用布局文件中的步骤名称（参见 GITHUB 链接内容）。
但在笔者看来这解释依然是不够严谨。因为这问题和其它可以转移责任的问题不同，在于此问题与 in-toto 框架的功能性直接相关。下文的密钥和签名的问题能转移给拥有者我是认同的，是因为密钥和签名本身是有自成体系（公钥加密体系）的管理手段的，拥有者不需要太强的应对能力。但现在这个问题的应对建议，包括所提议的弱一些的缓解措施，都对供应链拥有者构成了能力压力。
https://github.com/in-toto/docs/security/advisories/GHSA-p86f-xmg6-9q4x
审计发现：攻击者如果控制了产品的传送过程，可以通过只修改传送过程中的产品来危及整个供应链而仍能保持不被发现，而被修改后的产品就会危及在供应链后面环节的职责实体。
项目组解释：
在几种可能的缓解措施中，首选的方法是鼓励职责实体要严格地把链接的生成从对不可信的物料的操作中分离。此建议与 SLSA 等级3级对来源生成的要求一致，即“来源是不可篡改的”，可以在不更改 in-toto 规范的情况下应用。项目组还提供了新的工具作为其他的解决办法。
相关链接：
https://slsa.dev/spec/v1.0/requirements#provenance-non-forgeable
https://github.com/in-toto/in-toto/pull/589
笔者评论：这里涉及到 SLSA 软件物料供应链层级指南。软件供应链安全管理的关键一点就是物料的来源说明。这不仅包括来自上游的物料，也包括自己产生的软件产品的来源说明。
SLSA 的中文资料比较多，所以我这就不详细说了。
https://github.com/in-toto/in-toto/security/advisories/GHSA-jjgp-whrp-gq8m
审计发现：在验证元数据的签名时，不会验证参考实现代码中的 PGP 密钥。更具体地说，in-toto 不检查签名有效期是否在未来（低严重性）、是否存在已撤销的签名（中等严重性）或密钥是否具有正确的使用标志（低严重性）。
项目组解释：审计员建议使用 GnuPG 的功能进行签名验证以解决所发现的问题。但项目组认为这是不可取的，因为 in-toto 的设计是（开放性地）允许在隔离的外部资源进行验证。相反地，是软件供应链所有者的责任在将密钥作为验证密钥推广之前审查它们，并在必要时使用 in-toto 提供的机制撤销它们。
笔者评论：这事情两边都有道理。审计发现的内容是数字签名应用中常见的安全漏洞，是每一个使用数字签名进行完整性校验的人都应该熟知的。顺带一提，这也是信息系统审计师认证考试必考的考点。结合之前审计人员的发散思维来看，很可能就是认证信息系统审计师的持证人员。
至于项目组认为，对数字签名密钥、签名的过程和结果（即签发的证书）的管理超出了 in-toto 框架的范畴，责任应该落在供应链所有者自己。在笔者角度也支持该解释，道理依然是不可能无穷无尽地把所有发散内容全部管上。关键是项目组要在文档中指出如果用户使用不当，就可能会发生的安全问题。
就如我在前面所指出的，信息系统审计过程中的审计人员的发散思维是必要的，这是职业要求。因为审计并不仅仅考虑被审计对象，还需要把使用被审计对象的用户考虑在内。审计人员本身要考虑审计风险，只要审计的发现与被审计对象存在相关性，就必须作出说明。
除了通过审计确认了 in-toto 框架规范在根本上的有效性和可信性之外，在 in-toto 项目组看来，外部安全审计对安全的观点、立场和见解与项目组成员本身的差异，促使了项目组更深入地思考了 in-toto 框架的发展，会促使 in-toto 规范得到持续加强。
在笔者认为，外部审计的过程和结果对 in-toto 项目是确实有带来有益之处的。
就如古语有云当局者迷旁观者清，外部审计会以怀疑和否定的角度全面审视项目的设计和实现，而且还会基于对网络安全基准更广泛的理解，超越项目本身发散性地发掘安全缺陷，这不仅促进了项目本身的安全性得到提升，还提升了用户在落地应用 in-toto 项目时的安全性。
本站微信订阅号：
本页网址二维码：