X记录空间昨天，GitHub 表示已检测并控制了一起员工设备遭入侵事件，该事件涉及一个被植入恶意程序的 VS Code 扩展。该公司表示，目前的评估是，此次入侵仅涉及 GitHub 内部代码库的数据泄露，攻击者声称入侵了约 3800 个代码库，这与 GitHub 目前的调查结果基本一致。GitHub 已移除恶意扩展，隔离了受影响的终端，并优先轮换关键凭证。
几天前，我做了类似的事情，只是方向相反。我把笔记本电脑上的 OpenAI Codex Chronicle 卸载了，换成了运行在我自己的 Mac mini 上的本地 Gemma 4 实例。最初，这是出于成本考虑。但这次安全漏洞让我无法忽视这种架构的安全隐患。
一个受信任的第三方二进制文件。已安装在本地。拥有对您的屏幕、文件和令牌的完全读取权限。用户自行设置的出站网络路径，由于是用户设置的，因此所有防火墙都允许该路径通过。
即使破坏了二进制文件的供应链中的任何环节，也不需要破坏平台本身。平台会按照指令运行。
你走了进来。
这就是 GitHub 数据泄露事件。如果类似 Codex Chronicle 的工具在构建流程或分发层遭到入侵，也会面临同样的问题。它们的架构非常相似。
本地模型并非绝对安全。即使本地代理已被攻破并拥有文件系统和 shell 访问权限，它仍然是一个特权执行环境。区别在于，本地架构降低了强制性的外部信任边界，并使检查成为可能。
警告信号早已无处不在。
TeamPCP并非孤例。该组织在公开报告中被追踪为UNC6780，在本周之前，其2026年的目标列表包括Trivy、Checkmarx、LiteLLM、Bitwarden CLI、PyTorch Lightning，以及最近与一周前Grafana数据泄露事件相关的TanStack和durabletask npm和PyPI漏洞。
看看那份清单。
Trivy、Checkmarx、LiteLLM、Bitwarden CLI、PyTorch Lightning。
这些工具都是开发者或与开发者相关的工具。它们都值得信赖，本地安装，并且经常更新。然而，它们每一个都是木马程序，其攻击范围从开发者的笔记本电脑延伸到云账户，最终进入生产环境。
此次攻击活动中，针对 npm 的攻击更为严重。根据 SlowMist 和其他研究人员的公开分析，攻击者攻破了 npm 账户atool，并在几分钟内向数百个软件包推送了数百个恶意版本。Mini Shai-Hulud 恶意软件家族专门针对 GitHub 令牌、AWS 密钥、Kubernetes 密钥、SSH 凭证、密码管理器数据库和本地加密钱包文件。
这不是一连串的坏运气。这是一场蓄意且持续的针对供应链的攻击，最终波及到每一位开发~/.config者~/.aws。~/.ssh
开发者端点是边界
近十年来，主流的安全模型是：信任开发者，加强平台安全。
工程笔记本电脑的端点安全通常很薄弱：企业级 EDR，可能还有 DLP 代理和 MDM。真正的控制措施体现在代码审查、CI/CD 策略和生产环境访问权限上。
那种模式已经过时了。
在大多数环境中，开发者终端节点是权限最高、监控最少的节点。它拥有服务器的 SSH 密钥，拥有范围广泛的云 CLI 令牌，拥有 GitHub 凭据，可以推送到生产环境的代码仓库，并且拥有未加密的源代码。
而且，它越来越多地运行着安全团队从未审查过的受信任的第三方流程。
VS Code 扩展就是一个例子。大多数开发环境中都有几十个这样的扩展。每个扩展都以开发者的完整用户权限运行。每个扩展都可以读取开发者可以读取的任何文件。
MCP 服务器和 AI 编码代理几乎原封不动地继承了相同的信任模型：本地执行、广泛的文件系统可见性、环境凭证、用户批准的出站网络访问，以及大多数组织不会检查的供应链。
我运行着三十多台连接到我自己开发环境的MCP服务器。其中几台是我自己搭建的。我相信自己。
严格来说，我并不信任他们各自依赖的每一个供应链。
几乎没有人这样做。
业界采用了人工智能辅助的开发者工具，其操作严谨程度堪比浏览器扩展，而非特权基础设施。便捷性胜出的速度远超信任模型跟上的速度。
机械执法究竟是什么样子的
解决办法并非是发个备忘录提醒开发人员注意。让疲惫的工程师在午夜检查他们的扩展列表，这并非管控措施，而只是一厢情愿。
解决方法是采用机械强制执行机制，无论开发人员是否关注都会运行。
在我自己的开发架构中，这看起来像是四层结构。没有一层是巧妙的，每一层都很乏味。
无聊才是重点。
第一层：提交前钩子。每个代码仓库的每次提交都会在提交完成前运行一个 Python 扫描器。该扫描器针对 OpenAI、Anthropic、Google、GitHub、Slack、Discord Webhook、AWS 访问密钥以及其他十几种令牌格式设置了特定的模式，并能.env检测原始文件和证书/私钥文件。它会排除示例和占位符格式，以降低误报率。如果提交中包含真正的密钥，则提交会被阻塞。该钩子并不关心开发者是否注意到这一点。
第二层：代理钩子。Claude Code 和 Codex 都公开了可以在文件写入和命令执行之前触发的钩子。我对提议的编辑运行了相同的扫描器。代理无法通过正常的写入路径将密钥持久化到磁盘，因为钩子会在写入发生之前阻止该操作。
这样可以捕获真正的错误，例如代理程序将.env读取到的内容改写到它要写入的下一个文件中。它还可以捕获凭据侦测。在password代码库中搜索或使用 cat 命令的 Bash 命令.env会在工具调用边界处被阻止，而不是在应用程序层被阻止。
我有这次触发事件的实际日志。今年春天早些时候，在一次真实的 OAuth 流程中，一个代理尝试通过探测本地 vault 目录、运行命令systemctl cat并在配置文件中进行 grep 搜索来获取共享密码。
五次 Bash 调用。五次都被拒绝。
每个命令都直接引用了安全策略的名称。正确的做法是让用户通过规范的 Vault 命令显式授权检索，而最终也正是如此。
鱼钩发挥了作用。
第三层：.claudeignore我的开发机器上的每个代码仓库都有一个。它相当于代理的“安全层” .gitignore。它从根本上防止 AI 工具将敏感路径加载到上下文中。敏感路径列表无可争议：.env*文件、证书和密钥结构、原始数据库文件、构建输出、编辑器元数据。如果代理从未接触过这些敏感信息，就不会意外地将其泄露到草稿、摘要或提交中。
第四层：单一密钥库。所有真实凭证都存储在 AWS Secrets Manager 的专用账户中，可通过单一 CLI 访问。应用程序代码、代理工具和 CI 均在运行时从密钥库拉取凭证。源代码提交的仅是占位符。凭证轮换只需在一个地方更新即可。如果某个密钥泄露，可以在几秒钟内进行全局轮换，而无需追踪所有曾经包含该密钥副本的配置文件。
我的安全策略文档中有这样一行：
钩子故障属于安全问题，而非代码风格问题。
如果机械层捕获到真正的秘密信息，它就会旋转。钩子不会请求关闭的许可。
它没有做什么
即使采用这种技术栈，也无法阻止 GitHub 被攻破。
一个被植入恶意代码且拥有开发者完整权限的 VS Code 扩展程序拥有自己的攻击路径。它无需提交任何数据，也无需调用代理的写入路径。它可以直接从磁盘读取令牌，访问任何网络端点，并立即窃取数据。
我的鱼钩都看不到它，因为它不会流经我的任何钩尖。
这是实话。机械层是纵深防御，而不是一道墙。
该堆栈的作用是强化常见的故障模式：开发人员将真实密钥粘贴到提交中，代理程序好心地将秘密回显到文件中，攻击者在初始入侵后用作下一步侦察的凭证探测。
它可以避免常见的错误。它会记录尝试次数。它还会显示特权路径。
更棘手的问题是 GitHub 数据泄露事件所揭示的：将第三方代码交付给开发人员本地环境的供应链几乎没有任何安全模型。
对于 VS Code 扩展程序，除了“被举报后移除”之外，没有其他有效的审查机制。对于 MCP 服务器，除了“信任维护者”之外，也没有其他有效的审查机制。既没有强制签名要求，也没有来源证明要求，更没有大多数团队可以信赖的运行时沙箱。
如果你是一名安全负责人，那么真正需要思考的问题不是：
“攻击者对GitHub做了什么？”
真正需要思考的问题是：
“我的环境中有哪些以开发者权限运行的第三方进程？如果今天下午其中任何一个进程遭到入侵，会发生什么情况？”
对于大多数组织而言，这个答案并不令人鼓舞。
即将发生什么
未来十二个月内，我预计会有三件事发生。
首先，主流平台将会加强安全防护。GitHub 和微软将收紧对 VS Code 扩展发布的控制。Anthropic 和 OpenAI 将在其工具生态系统中添加溯源签名。在注册表层面的必要变更真正发生之前，npm 和 PyPI 可能至少还会经历一波安全措施。
其次，MCP 服务器将会遭遇首次重大安全事件。信任模型存在缺陷，攻击面巨大，而防御方才刚刚起步。有人会编写一个恶意 MCP 服务器，其行为类似于恶意 VS Code 扩展，并且会在数周内持续运行而不被察觉。
第三，关于工程笔记本电脑端点安全的讨论将从“EDR 加一份备忘录”转变为“你的开发环境就是生产系统”。率先接受这种理念的组织，在接下来的十八个月里，成本将比那些等待“团队PCP时刻”的组织更低。
我上周末卸载 Codex Chronicle 的举动就是一个正确反应的小例子。我卸载的并非恶意软件，而是来自一家大型实验室的合法研究预览版。
我把它移除了，因为它架构不符合我的需求：本地功能会定期通过云服务使用最近的屏幕上下文，而我无法审核这个二进制文件，而且我不需要打开网络路径。
替代方案运行在我自己的硬件上，我可以对其进行检查，并且没有强制性的外部依赖项。
这种架构选择正是更多开发者工具在 2026 年应该默认采用的。并非出于隐私考虑而选择本地架构，而是因为本地架构的信任级别更低，故障模式也更容易被发现。
云往返应该只在真正需要云服务的情况下使用，而不是供应商希望用户重复使用云服务的情况。
GitHub 的安全漏洞事件比我能在白板上画出的任何威胁模型都更清楚地说明了采取这种安全措施的必要性。
真正有趣的问题不在于安全团队是否原则上同意这一点。大多数团队如果被问及，都会同意。
有趣的问题是，无论是否有人同意，他们的执法行动是否会继续进行。
如果你的开发者终端运行在策略备忘录上，那么明年将会非常昂贵。
