当 AI 智能体被攻击的那一刻，才是灾难的开始……
MMaximilian Schwarzmüller
Computing/SoftwareBusiness NewsInternet Technology
Transcript
00:00:00我正在记录这段音频，就在一场极其毁灭性的供应链攻击
00:00:06开始几个小时后。这场供应链攻击蔓延到了更多的 NPM 以及 Python 软件包。
00:00:13在我录制此时此刻，尚不清楚它何时以及在哪里结束。我确实
00:00:19在我的 YouTube 频道上制作了一个单独的视频，深入探讨了这次特定的供应链攻击，
00:00:25因为它非常复杂。我在那里进行了深度剖析，解释了所有细节，因为
00:00:30那非常有趣。但在这里我想谈谈供应链攻击、安全以及 AI，
00:00:38在这个我们所处的供应链攻击和 AI 时代。因为我确信情况会变得
00:00:45更糟。我担心许多人还没有真正看清所有的危险。作为
00:00:54开发者、技术使用者和 AI 用户，老实说，我们还有更多工作要做。即使
00:01:01我们不是开发者，这也会影响我们。我知道大多数观看或收听的人都是开发者。
00:01:07但正如我将要说明的，这不仅仅关乎编写代码，也不仅仅关乎
00:01:13你们所熟知的供应链攻击。但让我们从基础开始。什么是供应链攻击？
00:01:20软件开发背景下的供应链攻击，简单来说就是你所使用的依赖项
00:01:26遭到了破坏。简而言之，这就是供应链攻击的核心。而遭到破坏
00:01:35当然可以指各种情况。我们通常看到的是，受损的软件包中含有
00:01:41收集凭据和令牌的恶意代码。它会扫描你的硬盘以查找
00:01:49你可能存在 .env 文件中的秘密，或你的 AWS 凭据等等。然后它利用这些
00:01:56凭据来访问你的账户，同时也进行自我传播。从而影响其他软件包。如果
00:02:04你是一个开源包的维护者，甚至是闭源的，如果你正在开发
00:02:11其他人使用或依赖的某些包或工具，那么入侵你的机器
00:02:19来破坏你分发的那个包或工具当然很有吸引力，因为，你猜怎么着，
00:02:26这随后会影响更多的人。所以我们看到的所有这些供应链攻击，包括
00:02:32这次从 Tanstack 软件包开始的供应链攻击，它们都是传播到
00:02:38其他包的蠕虫，影响越来越多的包，并最终影响安装并使用
00:02:44这些包的机器。现在，你可以采取一些措施来保护自己，
00:02:51我在另一个频道，也就是 Akatamine 频道，专门为此制作了一个视频。例如
00:02:56确保你只安装至少发布了三天以上的包，我是指软件包版本，
00:03:02或者在开发容器或虚拟机中运行你的代码。
00:03:08这些都是你应该做的。你也不应该在系统上存储纯文本形式的密钥。
00:03:15相反，使用像 Inphysical 或 Doppler 之类的服务，将密钥以加密方式
00:03:22存储在云端或其他形式中，这样即使攻击者扫描了你的系统，
00:03:28他们也看不到那些明文密钥。这些都是你现在必须做的。这很重要，
00:03:37因为这些供应链攻击越来越多。我们看到的次数在增加，这是为什么呢？
00:03:42这当然不是因为多年前你无法运行这样的攻击。
00:03:49那时候也是可能的，而且确实发生过，但发生的频率却剧增了，
00:03:56当然，AI 是一个重要原因。所以让我们来看看 AI 的角色。AI 是一个重要原因，
00:04:06因为当然，它使得发起此类攻击变得更加容易。如果你是一个攻击者，你当然可以
00:04:14利用 AI 来分析外面各种你想要破坏的软件包代码库，
00:04:22看看他们是如何构建包的？他们又是如何分发包的？例如，
00:04:30这次引发近期供应链攻击的 Tanstack 攻击中，维护者使用了一种
00:04:38理论上安全的方法，即 NPM 的受信任发布流程，我也在
00:04:45那个频道的另一个视频中深入探讨了这一点。但他们还使用了
00:04:51某种特定方式的 GitHub Actions 事件触发器，其安全性并不完美，这
00:05:00使得攻击者能够利用缓存投毒，将恶意代码从不受信任的环境
00:05:07带入受信任的环境，攻击就是这样开始的。详情请看另一个视频。
00:05:15但 AI 当然让分析代码库、分析其 GitHub Action 工作流
00:05:22或其他任何 CICD 提供商的工作流变得更容易。AI 可以批量分析所有这些工作流脚本和代码，
00:05:30它可以寻找安全漏洞。维护者当然也可以利用 AI 来扫描他们的
00:05:38代码库并寻找潜在的攻击向量。但作为攻击者，你天生具有
00:05:45优势，因为你可以寻找一切，尝试各种方法；而作为
00:05:52维护者，你必须预见到所有情况，AI 虽然能帮忙，但它仍不完美。
00:05:58作为攻击者你拥有优势，而 AI 简化了这一过程。AI 当然也简化了
00:06:04编写恶意代码的过程。它简化了编写任何代码的过程。而且
00:06:12如果你看过我的其他视频或听过其他剧集，你就知道我非常主张
00:06:20研究代码、进行代码审查，而不是把一切都外包给 AI。但当然，
00:06:27对我来说很明确的一点是，你应该利用 AI 来提升生产力。我们大家仍在摸索
00:06:33使用多少 AI 才是合适的。有些人会告诉你 100%，他们甚至不看代码。
00:06:40对我来说并非如此，但这中间有一个光谱。无论如何，AI 确实能让
00:06:46大量产出代码变得容易。如果我们说的是恶意代码，那么对
00:06:53攻击者来说，有些事情就很重要：你想要能完成任务且
00:06:59不易被察觉的代码。你不在乎代码是否优美，是否遵循了某些最佳
00:07:06实践；你的“最佳实践”就是攻击成功。当然 AI 可以帮上忙，
00:07:13它可以帮忙编写所有的恶意代码，构思如何攻击
00:07:19软件包。这就是 AI 出力的地方。但这只是故事的一面。让攻击变得容易只是其中一部分，
00:07:26另一个非常重要的方面是，现在的代码比以往任何时候都多。这意味着
00:07:35目标也比以往任何时候都多。我是说，也许你关注过那篇博客，或者整个关于 GitHub
00:07:43可靠性问题和宕机的故事。嗯，原因在于由于 AI，推送到 GitHub 的
00:07:49代码比以往任何时候都多。因为生成代码比以往更容易，且
00:07:55有比以往更多的人在生成代码和编写软件，其中包括许多人根本不知道
00:08:02那些代码在干什么，它是关于什么的。盲目编码（Wipe coding）是个大趋势，它有其应用场景，我是说，
00:08:11如果我想把五个 PDF 文档合并成一个，我很乐意让一个 AI 代理帮我完成，
00:08:18它可能会写一些代码来实现。我不在乎那些代码，因为这是个一次性
00:08:24的任务，对吧？但如果我在我的系统上运行它，那么这个代理可能会安装某些
00:08:32用来合并 PDF 的软件包，而那个包可能已经受到了供应链攻击。所以，如果我不看代码，
00:08:37我甚至不知道使用了某个包，因为我只关心合并 PDF 文档。
00:08:43因此，由于无论是为软件还是为一次性任务编写的代码都比以往多，
00:08:49导致安装软件包的情况比以往任何时候都频繁。而这当然
00:08:56使得发动这类供应链攻击比以往任何时候都更具吸引力，因为
00:09:01目标比以往任何时候都多，包括许多对软件安全、
00:09:06网络安全或类似领域一窍不通的目标。老实说，我们许多开发者也是如此，我们可能
00:09:14在理论上知道某些风险，但我们可能并不在乎，因为能把工作
00:09:22完成实在是太方便了。我们必须重新思考，我们必须重新思考。我们必须保护好我们的机器，必须确保
00:09:31我们在安全的环境中进行开发，比如在虚拟机和开发容器中，确保
00:09:37周围没有泄露的凭据。如果我们使用 AI 代理（我们可能都会用），我们
00:09:44在那方面也得小心，因为那里也有两种处于危险中的方式。所以让我们仔细看看
00:09:53AI 代理在这里是如何产生问题的。其中一个问题就是我刚才提到的，当我们使用 AI
00:10:00代理时，特别是当我们把它们用于一些与编写代码或
00:10:08软件没有直接关系的事情时，或者当我们用它们来帮助我们开发程序时，我们并不一定能
00:10:17看到它们所做的一切。如果你正在使用 Claude Code 或类似的工具，我
00:10:23对这些工具并无偏见，事实上我还有关于 Claude Code、Claude Coder、CodeX 的课程，我有这些课程，因为
00:10:30它们非常有用。但如果你正在使用它们，只是让它们运行，并告诉它们“我
00:10:35需要这个功能”，而你并不太在意过程，你可能甚至都意识不到它们
00:10:41正在安装什么。所以，又是软件包被安装，你可能被入侵，可能受到影响。现在，
00:10:49对此的一种防御措施当然是限制你想要使用的软件包数量；但同样，
00:10:54如果你使用的是 AI 代理，你可能无法控制这一点。它可能会安装一些你
00:11:00永远不会安装的包。所以这是一个显而易见的危险。这里还有一个不那么明显的：
00:11:07AI 代理是非常有吸引力的攻击目标。我这么说是什么意思呢？嗯，这些供应链攻击，
00:11:15我提过它们像蠕虫一样传播。它们攻击或影响各种软件包。
00:11:23现在，对于攻击者来说，入侵 Claude Code、CodeX、
00:11:32PyCoding 代理、OpenCode 或任何其他 AI 代理，当然都非常有吸引力。为什么呢？因为如果你有
00:11:42某种恶意代码，它实际上专门针对或仅针对影响和渗透 AI 代理包、
00:11:52代码库和源码而优化，那么这种恶意代码就可能包含提示词注入部分。
00:12:00例如，它可以明确针对所有这些 AI 代理，修改它们的代码，使其
00:12:08首要任务不再是窃取数据——我是说，注入的恶意代码（即包代码本身）
00:12:15假设不是为了窃取数据，而是为了调整 AI 代理的代码，使其拥有
00:12:22一些特殊指令，让它在被使用的机器上做一些事情，比如在你的
00:12:28机器上做一些你不想让它做的事。想象一下 Claude Code 有一个秘密的系统提示词，
00:12:34它通常是由 Anthropic 的员工设置的，但现在被那个恶意
00:12:39代码修改了。代码告诉它忽略你要求的任何事情，只是伪装它正在做你
00:12:46要求它做的事；或者它应该做你要求的事，但除此之外，它还应该扫描
00:12:52系统中的密钥。此外，它也许应该编写一个小程序来执行扫描，
00:13:00然后将数据发送到某个远程服务器或类似的地方。这里有着无限的
00:13:06可能性，因为突然之间你的系统上就有了一个特洛伊木马。突然之间你就有了
00:13:12一个在你的系统上失控的 AI 代理。这并不是因为 AI 本身变坏了，不是因为模型
00:13:20坏了或错了，而是因为代理代码本身及其系统提示词等被影响并
00:13:28遭到了破坏。这并非不切实际的情形。我向你保证，这在未来
00:13:34某个时刻必然会发生。这是如此明显且有趣的攻击目标。AI 代理是如此明显且有趣的
00:13:41目标。这会发生的。我们将看到这些供应链攻击上升到一个新高度，它们不只是
00:13:49像通常那样：影响一堆包并收集凭据——这本身已经够可怕了，
00:13:54且发生频率还在增加；我们还将看到 AI 代理因为恶意
00:14:01代码而失控。这只是时间问题。正如你所看到的，这里有很多层级。这就是
00:14:08我们现在所处的新现实。我想这有点像互联网的早期。在我们
00:14:14还在摸索阶段时，一切都充满了坎坷。我们必须弄清楚如何加强安全性，
00:14:21以及如何安全地做事。一个显而易见的步骤，无论是对于开发还是运行
00:14:26AI 代理，那就是你不想在一个容易出问题的环境中去操作。你不想
00:14:32在一个存储着凭据、密钥或任何其他对你重要数据
00:14:37的环境中运行它。你不想在你的主机器上运行。你想运行代理，你想
00:14:42在隔离的虚拟机、远程机器或任何能限制爆炸
00:14:49半径的地方构建软件。因为再说一次，出问题只是时间问题。我们
00:14:56必须意识到这一点，那是重要的第一步。情况变化很快，安全是
00:15:03一个巨大的问题，而且它将一直是一个巨大的问题，并且随着 AI 的加速、随着这些 AI
00:15:11模型变得更聪明（特别是结合了它们运行所在的工具时），它会变得更加突出。
00:15:17这引入了许多全新的功能，但与此同时，它们也带来了极大的便利。
00:15:23便利总是危险的，因为它会让你变得草率，忽视一些细节。没错，
00:15:30AI 无处不在。许多对网络安全一无所知的人正在使用它。甚至
00:15:34那些对此有很多了解的人也处于巨大的危险中。所以我认为我们要经历一段
00:15:40激烈的动荡期。我们必须重新思考，并在运行代理和
00:15:49编写代码时格外小心。