AI 时代该具备的安全意识 (1) 个人预防篇

最近软件行业安全事件频发，不仅涉及个别软件产品，许多主流编程语言、运行时和框架也陆续曝出漏洞。例如，PHP、Node.js 都出现了相当严重的漏洞。

当年 Ilya Sutskever 离开 OpenAI，创办以安全为目标的 SSI（Safe Superintelligence）时，曾引起行业内的广泛讨论。坦白说，当时看到这条新闻时，我们还很难理解这件事的迫切性。但随着 AI 能力持续提升，以及近期网络攻击手段的演变，我们也开始更加理解，为什么 AI 时代的安全问题需要受到高度重视。

过去，一位懂得网络攻击的黑客，由于个人时间有限，能够用于寻找漏洞并发起攻击的时间也有限。然而，现在当同一位黑客能够指挥数十、上百个 AI 智能体寻找漏洞时，漏洞被发现的速度会比过去快得多。

近期在软件安全领域，我们还看到一个值得大家更加警惕的观点：目前 GPT 与 Claude 等模型的厂商，在安全对齐上投入了相当多的资源，让模型遵守安全规范、避免协助有害行为。换句话说，当黑客想利用这类模型进行网络攻击时，模型往往会拒绝。

然而，部分开放权重模型 (open-weight models) 在安全对齐上并没有相应的投入。这让攻击者更容易绕过安全限制。随着开放权重模型的能力持续提升，攻击者获取强大 AI 的门槛也可能随之降低。在这个背景下，可以预期接下来的攻击事件可能会更加频繁。

为此，我们计划推出三篇系列文章。第一篇从个人预防的角度切入，讨论工程师平时能做些什么，提前降低遭受攻击的风险。第二篇从个人应对的角度切入，讨论如果真的出了问题，如何快速响应、减少损失。最后一篇则从团队的角度切入，讨论资深工程师可以为团队引入哪些制度与措施，让安全不再仅仅依赖个别工程师的小心谨慎。

工程师平时可以养成哪些安全习惯？

回顾近期发生的安全事件，从软件工程师的角度来看，有许多事情可以做，无论是个人项目还是日常工作，都可以尝试。如果公司目前还没有采取这些措施，也可以试着成为推动改变的人。下面我们逐一讨论。

锁定依赖版本

近期许多重大软件安全事故之所以影响广泛，是因为它们发生在软件供应链的上游。之前我们在《通过 API 避免重复造轮子》中谈过这个比喻：相比重复制造别人已经做过的轮子，软件行业一直有复用现有成果的习惯。这就像供应链一样，并非所有东西都要自己做，有些可以直接使用上游提供的成果。

在软件供应链的背景下，过去软件工程的最佳实践之一，是持续更新依赖包，避免使用过时或存在已知漏洞的版本。相信大家在工作中或多或少使用过的 Dependabot、Renovate 等工具，就是在这样的背景下普及的。

过去，如果正在使用的某个版本后来被发现存在漏洞，而平时又没有持续更新的习惯，那么一次性升级到已修复漏洞的版本，往往会困难重重，甚至让许多开发者感到痛苦。

然而，近年来几起重大供应链攻击，并不是在旧版本中寻找漏洞，而是攻击者通过夺取权限等手段，直接发布植入恶意代码的新版本，趁不知情的用户更新时发起攻击。甚至在 PHP 的 Laravel-Lang 供应链攻击中，还出现过攻击者直接改写已有版本的 Git 标签，用恶意代码替换某个已发布版本的情况。

无论是哪一种情况，都建议养成锁定版本的习惯。同时，除非是紧急安全修复，否则应当等更新冷却期结束后再升级。例如，之前的 Axios 漏洞出现在 1.14.1 版本，这个版本发布后不久就被识别为带有恶意代码的版本。如果没有立即更新，基本上就不会受到即时影响。

2026 年 7 月，GitHub 宣布 Dependabot 默认对常规版本更新设置 3 天冷却期。GitHub 研究了 2018 至 2026 年间受到广泛报道的供应链攻击，认为等待三天可以避开其中大多数在短时间内被发现并下架的恶意版本。当然，这并不意味着等 3 天就一定能避免攻击。但至少按照目前社区安全研究人员的检测速度，3 天冷却期能够降低自己成为第一批受害者的概率。有些研究认为应该等得更久，例如 Google Cloud 的安全研究建议设置 7 天冷却期。

同时，锁定版本时还需要配合锁文件 (lockfile)。根据包管理器的设计，锁文件会记录对应 Git 提交的完整性哈希。以 PHP 的 Composer 为例，使用已有锁文件执行 composer install，可以避免重新解析依赖版本，降低在不知情的情况下获取到被替换的包的风险。

当攻击者修改已发布的版本，让同一个版本号指向不同的代码时，锁文件中记录的 Git 提交哈希可以帮助识别这种变化，从而降低意外更新的风险。

减少第三方依赖，必要时自行维护

上一节讨论了针对依赖包的预防措施。除了继续依赖第三方包，近期行业内也出现了更激进的观点。例如，开源社区知名工程师 Mitchell Hashimoto 主张，相比直接使用第三方包，更好的做法是将依赖包 fork 出来自行维护，删除不需要的功能，除非用户确实受到影响，否则不要更新。每次更新都应该能够指出具体需要哪一处代码变更。

这个观点既是在重新审视软件供应链的利弊，例如只使用一个小功能，却要安装一个庞大的依赖，可能弊大于利；更重要的目的，则是拿回对依赖包的控制权。按照他的主张，如果目前自行维护的版本已经够用，就没有必要升级或追加功能，这样可以减少受漏洞影响的可能性。

过去，这一主张经常被批评为不切实际，因为自行维护分支需要付出一定成本。尤其对于比较复杂的包，自行维护有时几乎不可能。然而，在 AI 智能体大量参与开发的时代，这项成本已经不像过去那么高，因此近期也能看到越来越多团队朝这个方向尝试。

加入 E+ 会员方案

如果你觉得这篇分享有帮助，想阅读更深入的内容，欢迎加入 E+ 会员。除了有会员专属的深度文与影片，探讨前后端开发、AI 工程、职业发展，同时有 Discord 社群一同交流与成长。

许多 E+ 会员通过所任职公司的教育训练补助 (E+ 会开立有统编的发票)，不用花自己的钱，也能每周通过深度主题文与社群交流，拓展技术视野、加速职业成长。