依赖项与软件供应链安全：警惕您所用代码带来的风险

现代业务应用几乎从不完全从零开始编写。开发者会使用数百乃至数千个第三方库和组件：用于界面、支付、发送邮件、图像处理等等。这种方式节省时间和成本，但带来了一个技术圈之外很少被谈及的后果：您继承了所用每个组件的安全风险。

近年来，针对软件供应链的攻击越来越频繁。攻击者不再直接攻破您的系统；他们渗透进流行的库、构建服务或开发者账号，然后等待被污染的组件传播到成千上万的应用中。从来不是目标的企业也可能受到波及。

本文面向企业主和决策者，说明依赖项与软件供应链安全。目的不是把您变成安全专家，而是帮助您向团队或供应商提出正确的问题，了解合理的基本做法，并避免最常见的疏忽。

摘要

• 每个第三方库都是您应用攻击面的一部分
• 风险既来自已知漏洞，也来自被蓄意污染的组件
• 在用组件的清单，是所有后续安全措施的基础
• 例行且受控的更新，比拖到堆积如山更安全
• 供应链安全涉及人员、流程和工具，而不只是某一个产品

为什么依赖项是业务问题

一个普通的网页应用可能直接加载的库只有几十个，但每个库本身又依赖其他库，如此层层嵌套。当所有层级都被计算在内，数量可能达到数百乃至数千个组件，它们由您不认识的人编写，由志愿者维护，并在没有您参与的情况下更新。

每个组件都是以与您的应用相同的访问权限运行的代码。有问题的库可以读取客户数据、窃取访问密钥或打开后门。难点在于可见性：没有工具和流程，大多数企业并不确切知道自己的系统里运行着哪些组件。

从业务角度看，影响是实实在在的：客户数据泄露、服务中断、声誉受损、法律责任以及恢复成本。这一切的发生，并不是因为您在自己编写的代码上不够谨慎，而是因为您所信任的他人代码。

供应链风险的类型

依赖项的风险并不统一。了解其类型有助于确定相应的防御措施，因为应对旧漏洞与应对被蓄意污染的组件，方式并不相同。

• 已知漏洞：已发布的库版本中可被利用的缺陷
• 恶意包：被蓄意制作来窃取数据或运行有害代码的库
• 维护者账号被接管：攻击者控制合法库开发者的账号并发布被污染的版本
• 名称仿冒：名称与流行库相似的恶意包，因输入失误而被安装
• 依赖混淆：构建系统拉取了恶意的公共包，而不是内部包
• 构建被入侵：构建和发布工具或服务被渗透
• 被遗弃的库：没有维护者的组件，因此漏洞永远不会被修复

最后一类常被低估。曾经流行如今无人维护的库，仍在许多应用中运行，而当发现新漏洞时，没有人去修复。识别被遗弃的组件，是风险管理的重要组成部分。

第一步：知道您用了什么

您无法保护自己不知道的东西。最有价值的第一步，是拥有一份应用所用组件的完整清单，包括版本和来源。这份清单常被称为软件物料清单（SBOM），企业客户和监管机构越来越多地要求提供。

这份清单应当由构建过程自动生成，而不是手工编制，否则很快就会过时。有了清单，当重大漏洞被公布时，您几分钟内就能回答：我们是否使用了该组件、在哪个应用中、哪个版本？没有清单，回答这个问题需要数天的追查。

1. 01为每个应用自动生成直接和间接组件的清单
2. 02记录每个组件的版本、来源和许可证
3. 03把清单与每次发布一同保存，以便向前追溯
4. 04把清单与持续更新的漏洞信息来源关联起来
5. 05标记关键的、无人维护的或许可证有问题的组件

漏洞扫描与修复优先级

扫描工具可以把您的组件清单与已知漏洞数据库进行比对，并在匹配时发出警告。这既便宜又自动，因此应当成为构建流程的一部分。但这些工具也可能产生大量警告，而这正是需要人来判断的地方。

并非所有漏洞对您来说都同样危险。一个位于您从不调用的函数中的严重缺陷，可能无法被利用，而一个暴露在互联网上的组件中的中等缺陷，可能非常危险。要按严重程度、组件是否面向公众，以及是否存在已知的活跃利用来确定优先级。

还要确定由谁负责。没有负责人的警报不会得到解决。每个应用都应有明确的个人或团队来接收、评估和关闭发现的问题，并针对每个严重等级商定时限。

更新：影响巨大的小纪律

许多重大事件的发生，并非因为新的漏洞，而是因为修复程序已经提供了数月却没有被应用。因为担心弄坏东西而推迟更新，感觉很安全，实际上却是在堆积风险，让下一次更新变得更大、更令人生畏。

更健康的做法是小而频繁的更新，并辅以自动化测试，让人确信变更不会破坏重要功能。小更新更容易测试、更容易回滚，出了问题也更容易找出原因。

• 安全更新在测试之后立即应用，而不是等待大的窗口期
• 大版本更新定期安排，并留出测试时间
• 足够的自动化测试，以便快速验证变更
• 更新引发问题时的回滚方案
• 能自动提出更新建议供人工审阅的工具

在使用之前选择并评估组件

最便宜的预防发生在组件进入您的应用之前。在使用新库之前，问几个几分钟就能回答的简单问题：它是否被积极维护、有多少人在用、是否有安全问题的历史，以及它的许可证是什么。当代码借助 AI 助手编写时，这些检查更加重要，因为 AI 有时会推荐过时甚至并不存在的库，详见 AI 辅助软件开发。

• 维护活跃度：最近一次发布、对问题的响应，以及维护者数量
• 流行度与使用情况：被广泛使用的组件会受到更多他人的审视
• 漏洞历史及修复速度
• 它带来的依赖项数量，因为每增加一个都会扩大攻击面
• 与您业务模式兼容的许可证
• 其功能是否真的需要，还是可以简单地自己编写

最后一个问题常被忽视。为了一个小功能而引入一个大库，会不必要地增加风险。只要功能简单且不涉及密码学等敏感事项，有时自己写几行代码，比增加一个新的依赖项更安全。

保护构建与发布流程

供应链不仅关乎您引入的库，也关乎您自己的应用是如何构建和交付的。如果您的构建系统被入侵，攻击者就可以把恶意代码塞进您自己的产品，再带着看似合法的签名分发给您的客户。

• 对代码仓库和构建系统的访问启用多因素认证
• 为自动化流程所用的账号和令牌设置最小访问权限
• 把密钥和机密存放在专门的位置，而不是代码里
• 变更合并之前由第二个人审阅代码
• 锁定依赖项版本，使构建可重复且一致
• 记录整个发布流程中谁在何时更改了什么

嵌入代码中的机密是一个经典错误。存放在仓库里的访问密钥，尤其是公开仓库，几分钟内就可能被发现并被滥用。请使用机密管理器，并自动扫描仓库，以检测不小心存入的机密。

代码之外的供应链：供应商与服务

贵公司的供应链还包括与您系统相连的第三方服务：支付服务商、分析服务、客户支持工具等等。从外部服务加载到您网店页面中的脚本，如果其提供方被入侵，就可能窃取支付数据。

控制允许在您系统中运行的内容。把第三方脚本限制在真正需要的范围，使用限制脚本来源的内容安全策略，并定期检视已连接的外部服务。每一次集成都是您给予的信任；请确保它值得。

对于您购买或租用的软件供应商，询问他们的安全实践：如何管理依赖项、修复漏洞的速度有多快、是否提供组件清单，以及发生事件时如何通知客户。

开源组件的许可证与合规

除了安全，依赖项还带来法律层面的问题：许可证。每个开源组件都附带决定如何使用、修改和分发它的条款。有些许可证非常宽松，另一些则要求公开衍生代码或署名。忽视它们可能引发纠纷，或在不合适的时候迫使产品作出改变。

用于安全的同一份组件清单，也可以用来检查许可证。制定一项简单的政策，说明哪些许可证类型可以接受、哪些需要审查、哪些在您的产品中被禁止。这样，开发者可以快速决定，法务团队只处理真正需要关注的情况。

如果您向客户销售应用、提供软件即服务，或正为融资或并购做准备，这一点尤其重要。评估您业务的一方几乎肯定会检查许可证合规性，整洁的清单能加快这一过程。

平衡速度与安全

快速行动与谨慎之间存在天然的张力。产品团队希望新功能尽快发布，而安全管控让人感觉像是刹车。解决之道不是二选一，而是让安全管控成为工作流程中的自动部分，使其几乎不增加摩擦。

对每次变更进行自动扫描、自动提出更新建议，以及在后台运行的许可证检查，能够在不增加大量手工工作的情况下提供保护。只有例外情况和高风险发现才需要人工决策，使团队的注意力集中在最重要的地方。

做好应对事件的准备

无论预防做得多好，事件仍可能发生。准备工作决定了事件是被控制住，还是演变成危机。提前规划：联系谁、如何评估影响、如何隔离受影响的系统，以及必要时如何通知客户和主管部门。

准确的组件清单在事件中帮助极大。当重大漏洞被公布时，拥有清单的团队能迅速知道自己是否受影响以及在哪里，然后在攻击者有机会利用之前修复。没有清单的团队则只能摸索，而时间在不断流逝。

像消防演习一样演练这份计划。模拟一个场景，例如宣布某个流行库已被污染，然后走查会采取什么行动。一次简单的一小时演练，往往能暴露纸面上看不到的缺口。

务实的起步步骤

1. 01请团队或供应商为您最重要的应用生成组件清单
2. 02在构建流程中启用自动漏洞扫描
3. 03为每个严重等级设定负责人、优先级阈值和修复时限
4. 04养成例行更新的习惯，并辅以自动化测试
5. 05把机密从代码移到专门的存储，并启用机密扫描
6. 06检视在您系统中运行的第三方脚本和服务，移除不需要的
7. 07制定一份简短的事件计划，并每年演练一次

值得向团队或供应商提出的问题

以下问题无需技术专长就能提出，但答案能揭示团队成熟度的很多信息。清晰而自信的回答是好兆头，而含糊或带有防御性的回答，则指向在事件发生之前需要改进的领域。

• 我们是否有应用所用组件的完整清单，它有多新？
• 我们所用的组件出现漏洞时，如何通知我们？
• 从关键漏洞公布到修复被应用，平均需要多长时间？
• 谁可以更改我们的代码和发布流程，这种访问如何受到保护？
• 机密和密钥存放在哪里，谁可以访问？
• 如果我们使用的某个流行库被证明已被污染，我们会怎么做？

结语

软件供应链安全不是解决一次就可以忘记的问题。它是一种持续的纪律：知道自己用了什么、监控漏洞、例行更新、谨慎选择组件，并保护构建流程。

对企业主而言，最重要的一步是提出正确的问题，并确保有负责任的负责人。有了几个一贯的基本习惯，您就能享受第三方组件的好处，而不必承担失控的风险。