美国关键基础设施软件供应链安全指南的十大谬误

美国网络和基础设施安全局（CISA）等机构联合发布的软件供应链安全指南遭到了软件开发业界人士的广泛批评，企业网络安全专家凯利肖特里奇认为这份指南脱离实际甚至非常危险，任何实施该指南的企业都将面临灾难性的后果。里奇为此专门发布了万字长文，对指南进行了猛烈抨击，并提出了自己的十大反对意见（例如：牺牲交付速度来换取安全，结果你两样都得不到），内容整理如下：

不久前，美国网络安全和基础设施安全局(CISA)、国家安全局(NSA)和国家情报总监办公室(ODNI)发布了一份题为《保护软件供应链——开发人员推荐实践指南》（以下简称指南）的文件。我们原本期望该指南能够提供企业提高系统应对供应链攻击的弹性的实用方法，甚至新颖的方法，因为指南出自权威机构。

但结果非常让人失望，该指南充斥着不切实际、令人困惑甚至危险的建议。

网络安全界有一个集体谬论，即将“安全”作为首要任务是所有组织员工的“工作”。这种谬误使组织无法获得理想的防御结果。不幸的是，“软件供应链安全指南”再次强化了这种谬误。

针对《指南》中最显著同时也是最危险的谬误，笔者提出了十条反对意见：

1. 放慢软件交付速度无助于安全，反而会伤害它

2. （该指南基于）一个底层悖论（“思维机器”悖论）

3. 指南对大多数企业不适用

4. 大多数企业都不想实施该指南

5. 安全供应商的配套解决方案被过分强调

6. 相关的安全和基础设施创新被忽视

7. 关于软件交付实践和基本术语不准确

8. 主管部门传递的信息令人困惑、矛盾

9. 忽略了二阶效应和潜在的因果因素

10. 无视安全厂商自身软件安全的危险性

一、放慢软件交付速度无助于安全，反而会伤害它

牺牲交付速度来换取安全，结果你两样都得不到。来自企业软件工程界的经验证据清楚地表明，开发速度不仅有利于业务成果（如发布速度），而且也有利于安全成果（如恢复时间、修复安全问题的时间）。相反，“保护软件供应链指南”主张在整个软件交付过程中增加额外障碍和摩擦，这会有效地拖慢开发速度。

该指南要求集中化管理的安全团队对软件工程活动施加重大限制，从而实现“将安全作为重中之重”。例如，将IDE（和插件）视为威胁，需要“在集成到任何开发人员机器之前进行预先批准、验证和漏洞扫描”。

为了安全起见，速度甚至可靠性都被视为合理的“伤亡代价”。对于政府情报部门而言，国家安全是主要使命，因此他们认为安全摩擦和障碍是值得的。因为这些部门的目标不是通过更快地发布更多软件来增加市场份额或客户群或提高利润率。这意味着他们的观点根本无法转化为私营部门的观点，除非全社会都决定一家公司必须为国家安全而不是其股东服务。

实施该指南（例如被财富500强企业实施）导致的结果是：软件难以开发交付。软件工程师会辞职（因为低效工作而辞职）。无论企业的预算如何，根据指南的这些建议，企业的软件开发周期将极为漫长，并且质量会更差——这也直接损害了开发更高质量、更安全软件的目标。

二、指南基于一个潜在的悖论（“思维机器悖论”）

指南存在逻辑上的不一致（甚至可能是一个悖论），那就是：开发人员不可信，但又鼓励人工运行的手动流程而不是实施自动化。如果指南对开发人员引入的“意外缺陷”存在偏见，那么为什么要推荐手动流程来引入更多“人为错误”的机会呢？

如果担心开发人员的用户凭证会导致恶意攻击和错误，那么为什么要阻止（控制自动流程的拥有特权的机器）服务帐户，因为它们本质上与特定用户身份解绑？不使用服务帐户的话，就会出现人类用户离职或被解雇后凭据仍然可用的情况——这是一个危险的游戏。

该指南竭尽全力将开发人员描绘成内部威胁——无论是故意还是“训练不足”——但随后明确支持手动开发和发布流程。一方面软件工程师个人不值得信任，但同时又要求他们执行和批准软件交付活动，这不矛盾吗？

诚然，人类的大脑并不擅长每次都以相同的方式执行任务。计算机在这方面的表现要好得多！但是，尽管指南警告了人为错误的危险，但同时又希望依靠这些人来完成可重复任务，而不是将任务自动化。

三、指南对大多数企业不适用

大多数企业没有机会实施“保护软件供应链”指南中的建议。虽然该指南宣称是开发人员的参考指南，但实际上只是与NSA具有相同目标和资源的情报机构的参考指南。

谷歌经常遭到这样的批评：谷歌提出的“有用”建议都是基于谷歌庞大的预算和人才库，而没有考虑“普通人”所面临的限制和权衡。CISA、NSA和ODNI也掉入了类似的陷阱。

指南中的许多建议对企业来说是不切实际的，不仅仅是在“开发” 和“工程” 系统中禁止互联网访问的荒谬建议。例如，如果企业的开发文档记录了一个软件执行的所有内容，则相当于编写了两次（并且文档将不可避免地与源代码不同）；如果根本没有文档，只阅读源代码，企业可能会过得更好。

另一个例子，指南还建议“在开发过程中对所有软件组件执行模糊测试”。如果在开发过程中对所有软件组件进行模糊测试是一项严格的要求，那么企业可能永远都开发不出软件。指南还建议“使用测试方法……确保修复的漏洞能够真正修复所有可能的危害。” 如果企业软件工程团队有办法看清楚所有威胁和漏洞，为什么还需要这个指南？

四、大多数企业都不想实施这个指南

大多数企业不想实施该指南。因为指南的建议没有匹配企业规模，与企业软件交付优先级不一致，并且降低了生产力。

以国家安全为使命的情报机构别无选择，只能实施上述规范，否则就不能开发软件。而以赚钱为使命的私营企业不会面临同样的限制；相反，私营企业面临的限制是他们可支配的资源数量，为了支持他们的使命，通常最好将其用于收入或产生利润的活动而不是那些阻碍或侵蚀它的活动。

无论企业的商业模式是B2B还是B2C，企业客户的重中之重通常也不是安全性（尽管安全的优先级也很高）。只有当主要客户是情报机构时，安全才会成为客户最关心的问题，此类企业极少，特别是在财富500/1000强企业中。

站在大多数企业的视角，诸如“如果可能，工程网络不应直接访问互联网” 和“如果可能，开发系统不应访问互联网” 等建议对于营利性企业来说非常不现实。同样，在企业软件开发的现实中，贬低“易于开发”的特性也是不合理的；更具建设性的建议是：必须将此类（安全）功能视为系统设计的一部分，并通过适当的访问控制和审计日志提供保护。

从可靠性和弹性的角度来看，指南中的一些建议在软件工程师眼中是“糟糕的做法”，因此会被拒绝。例如该指南建议使用“临时SSH密钥”来允许管理员访问生产系统，而Ops工程师和SRE通常更喜欢不可变的基础设施来专门禁止使用SSH，这有助于提高可靠性（并切断对攻击者的诱惑机制）。

五、推荐的安全供应商配套解决方案被过分强调

指南过分强调供应商工具，几乎完全忽略了非供应商解决方案。具体来说，指南大肆吹捧现有安全供应商的一系列“配套”商业解决方案——IAST、DAST、RASP、SCA、EDR、IDS、AV、SIEM、DLP、“基于机器学习的保护” 等等——通篇充斥着赞美之词，却没有提供关于流程自动化并使其可重复和可维护的建设性、理智的建议。

该指南明确表示不鼓励开源软件。通过设计实现的安全性也很少提及，例如DIE反脆弱安全模型（取代CIA模型）。该指南给人的印象是安全供应商成功地游说政府部门将他们包含在指南中，这（使企业）对其中立性提出了质疑。

事实上，为了推销厂商的安全产品，指南甚至给出了诸如手动发布流程之类的危险建议。例如，指南建议：“在将软件交付给客户之前，开发人员应执行二进制成分分析以验证软件包的内容。” 但是，如果期望的结果是高质量、安全的软件，则开发人员不应该自己执行软件包发布（参见反对意见#2）。

再举一个例子，他们建议“应该在签入（check-in）和发布之前对每个版本的所有代码执行SAST和DAST分析……”但是企业应该如何在签入之前对代码执行DAST/SAST？这是一个荒谬的“左移”，接下来是不是要在开发人员头脑风暴如何编写代码时在他们的大脑里运行安全工具？

指南始终没有提及有必要将DAST/SAST集成到开发人员工作流程中并确保不牺牲开发速度。在企业软件安全中，安全附加解决方案的成功取决于其可用性或强制。

如果您使安全方式变得简单，并确保软件工程师不需要过度偏离他们的工作流程来与安全解决方案进行交互，那么很可能会产生更好的安全结果（或者至少不会导致更差的生产力结果）。另一种方法是强制实施安全解决方案；但如果该方案不可用，那么它将被绕过以确保工作仍然完成，除非有足够的强制力来强制使用。

当推荐安全方案与指南的“断开开发系统与互联网的连接”的建议相结合时，它产生了一个问题：如果开发系统未连接到互联网，您如何使用SCA工具等？

“基本卫生习惯”可以说比任何这些推荐方案都要好，包括：

• 了解存在哪些依赖项
• 确保了解向软件中添加的内容的目的性
• 选择您可以理解和维护的技术堆栈
• 选择适合您正在开发的软件的工具

“向软件中增加内容的目的性”是什么意思？它的意思是：

• 将依赖项作为设计的一部分，而不是实现
• 谨慎添加依赖项
• 了解为什么包含其他库和服务
• 了解依赖项的打包问题；例如，如果您包含一个依赖项，那么给操作和交付带来成本是多少？
• 如果您依赖另一个团队的服务，他们的SLO是什么？你信任他们吗？它是一个稳定的系统吗？是否存在问题？
• 如果它是一个开源库，它是由一个人还是一个团队维护？是一个提供付费支持服务的公司吗？你能看到这家公司的更新和补丁历史记录吗？

本质上，答案不是：“永远不要依赖” ，或者，了解您的依赖项是什么。

总体而言，指南建议的缓解措施都是关于输出而不是结果，是关于安全威胁因素，而不是实际保护任何东西并用实证方法验证其有效性。很明显，该指南不考虑每季度交付超过一次的组织；事实上，指南似乎认为快速的软件交付是不可取的，是错误的（根据反对意见＃1）。

六、省略了相关的安全和基础设施创新

如反对意见5中所述，该文件忽略了过去十年私营部门在软件安全方面的大量创新。该指南采取了NSA/CISA/ODNI的安全方式优于私营部门现状的立场，这是一种错误的二元论。

事实上，像SolarWinds这样的公司已经承认自身“动作慢”是一个不利因素，并且已经对其实践进行了现代化改造（包括使用开源代码）以提高安全性。

没有提及这些创新表明指南只是对手头的问题进行了孤立的审查，这削弱了指南的知识中立性。下面列出了企业安全团队希望在权威参考指南中看到的安全和基础设施创新类型：

• Netflix的Wall-E框架
• Segment.io关于威胁建模
• Segment.io关于基于时间的访问
• WebAssembly(Wasm)组件模型
• Wasmtime中的安全性和正确性字节码联盟
• IDE支持基于云的静态分析
• 通过CI/CD的软件交付
• 通过IaC自动修补
• GitHub的Dependabot工具
• 基于安全混沌工程的弹性安全日志管道
• Facebook on 2FA用于内部基础设施身份验证
• AWS的 API密钥金丝雀令牌
• Google的配置分发工作示例

指南还应该采用来自私营部门的调查数据和报告来加强指导，例如最近的Golang调查（其中有一个专门针对安全性的部分，包括模糊测试）和GitHub从2020年开始的Octoverse安全报告。

指南还警告不要“允许对手在远程环境中使用后门来访问和修改受保护的基础设施中的源代码。” 这差不多就是推翻了过去30多年的源代码管理(SCM)系统。

在现代软件交付过程中，你不可能在没有人注意到的情况下直接修改源代码。甚至子版本也是建立在跟踪增量的想法之上的。如果您更改了某些代码，系统会记录该代码何时更改，由谁更改，何时更改。大多数开发工作流将SCM系统配置为在将更改合并到重要分支之前需要同行批准。几十年来软件工程的实践一直如此，如果主管部门连这一点都不知道，那就堪忧了；如果指南推荐的供应商对此也没有说法，那就说明联邦采购存在严重问题。

七、指南关于软件交付实践的基本术语不准确

指南的整个文档对现代软件交付实践存在大量误解和不准确之处，包括对基本术语的误解和不准确之处，例如CI/CD 、编排、每日构建、代码存储库等等。这是信息安全相关的更大范畴的文化问题的一部分，即（政府部门）试图规范他们不了解的东西。

参考指南似乎不了解企业工程团队中谁在做什么。今天的产品和工程管理没有定义安全实践和程序，因为他们的优先事项不是安全，而是与他们权限范围内的业务逻辑相对应的成功指标（通常与收入和客户采用率有关）。QA的定义尤其令人困惑，这表明情报机构与私营企业的QA方法截然不同。

如果企业遵循“软件开发组经理应确保开发过程避免有意或无意地将设计缺陷注入生产代码”的建议，那么软件可能永远不会在私营企业再次发布。该指南似乎还认为软件工程师不熟悉功能蠕变（feature creep）的概念，好像压根不知道这是当今产品工程中的默认概念。

指南还充斥令人困惑的陈述，例如，“管理员不得（调整系统本身）除非必须修复生产的平均故障时间。” 我不知道它们是什么意思，也很难猜测它们可能意味着什么。这损害了指南的知识可信度。

即使在政府情报部门的专业领域（例如密码学），该指南也不准确。“加密签名可用于验证软件没有被篡改，并且是由软件供应商编写的。” 这是错误的说法。加密签名验证供应商在某个时候申请了该密钥，但并不能用来判定相关软件的安全性。例如，游戏Genshin Impact的反作弊驱动程序的密钥尽管容易受到提权漏洞的影响，但仍未被撤销。

在另外一个例子中，指南的作者将“零日漏洞”称为“容易被利用的媒介”。对于“方程式小组”黑客部队及其算资金而言，这可能是正确的，但从大多数网络犯罪分子以及企业的角度来看，情况并非如此。

企业面临的主要威胁仍然是泄露的凭据、社会工程和错误配置。对于财富500强来说，如果攻击者被迫使用零日漏洞来攻击你，那说明你的安全工作到位了，黑客用尽了常规攻击手段都不能奏效。这应该被认为是对企业安全态势的一种肯定。

八、来自政府机构的令人困惑、矛盾的信息

令人困惑的是，去年还强调可重复性和可扩展性需求的CISA在指南中只有一次提到了可重复性的重要性。另一家政府机构(NSA)在2020年1月的报告中指出，供应链漏洞需要高度复杂的利用，同时在野外的流行率很低。

然而，该指南似乎要求软件工程活动的设计将供应链漏洞作为最高权重因素。错误配置却很少被提及，尽管NSA曾认为错误配置才是最普遍且最有可能被利用的。

在前面提到的CISA的指南中，强调了云计算和自动化的一些好处。但在本参考指南中，他们却指出云比本地系统更危险（36条），但没有解释为什么会给出这个判断。

指南的很多措辞也令人困惑，并且从未得到澄清。什么是“高风险”缺陷？在开发环境中，“网络安全卫生”是什么意思？指南坚持“应该修复安全缺陷”，但缺陷（defeat）的定义是什么？它存在吗？它是可利用的吗？会是犯罪分子还是国家黑客的目标？都没有明确定义。

九、忽略二阶效应和潜在的因果因素

没有考虑二阶效应或潜在的因果因素，例如组织激励和生产压力。（有一次提到，一笔带过，而且开发人员可能面临各种限制）。这忽略了复杂系统中的弹性问题以及适用广泛的行为科学。事实上，指南的这些僵化建议可以说是适应能力的反面教材，是弹性科学中的一个陷阱。

如果企业要尝试实施这些建议（我非常不鼓励他们这样做），那么尽管存在令人晕厥的后果，如何实现这些建议的指导是必不可少的。如果不改变激励措施，指南的大部分内容将变得毫无意义。

指南的实施建议也没有讨论用户体验(UX)考虑因素，这些建议可能比实施的内容更能影响安全结果，因为不可用的工作流程注定会被绕过。由于该指南忽略了软件交付活动的复杂性并对开发人员行为进行“想当然”的解释，因此给出的建议通常是“粗野”的。

指南错过了讨论使安全方式变得简单的机会，最大限度减少开发人员工作流程摩擦的重要性，以及与IDE等工具集成的必要性等等。缺失这些内容导致指南既肤浅又空洞。

十、无视安全供应商软件的安全性

指南不厌其烦地讨论扫描第三方开发或使用的软件的必要性，以及一长串商业安全工具如何能帮助企业做到这一点（参见反对意见#5）。奇怪的是，指南没有提到需要扫描这些安全工具，例如为您的EDR或防病毒推荐解决方案执行SCA。

安全工具通常需要对系统进行特权访问，无论是作为内核模块运行还是需要对关键系统进行读/写(R/W)访问。考虑到安全工具中严重漏洞的悠久历史，这是一个相当令人不安的“疏漏”。除了端点安全工具产生的众多软件可靠性问题之外，还有很多问题也没有得到提及。众所周知，工程团队出于正当理由而鄙视服务器上的端点安全：内核恐慌、CPU瘫痪以及其他令人恼火的奇怪故障。

指南高度质疑IDE和其他开发人员工具的安全性，但对安全供应商和安全工具的代码却网开一面，没有任何安全警告，这感觉很奇怪。指南推荐的安全工具不需要任何安全检测？这些工具对代码开发部署中制造无数障碍的建议是否也适用于安全补丁？毕竟，补丁也是软件更改。如果开发安全工具不适用补丁，那么这对攻击者来说就是可以利用的巨大漏洞。

指南的另一个“惊喜”是防病毒软件被列为能够检测DLL注入之类威胁的分类，最近的经验数据表明，即使对于被认为远远领先于防病毒解决方案的EDR也做不到。同样，指南给人的印象是热衷于推销安全供应商，而不是提供一套更完整的安全战略建议。这些安全工具可能对底层系统造成的严重性能影响，例如生产环境主机上的内核恐慌，指南也没有提及。

结论

如果你将《指南》奉为圭臬并将其实施到企业中，结果将会是灾难性的，软件供应链将彻底崩溃。您所在的企业会将您视为理论家、傻瓜或两者兼而有之，您将把软件工程活动限制到一定程度，以至于完全放弃交付软件。公平地说，最安全的软件是从未编写过的软件。但是，在一个与软件交付密切相关的世界发展过程中，我们可以做得比指南建议的要好。