文章总结： 文档分析了GitHub因员工安装恶意VSCode扩展导致代码库泄露的安全事件，指出当前AI开发环境中插件、Agent等组件增多带来的供应链风险。重点介绍了Perplexity开源工具Bumblebee的功能：以只读方式扫描开发环境依赖项并匹配风险清单，帮助开发者实现环境可见性。强调安全需从识别潜在威胁入手。 综合评分： 82 文章分类： 供应链安全,安全工具,安全运营,安全意识,解决方案

Github被黑后，我尝试了Perplexity的AI开发风险扫描器

原创

路人甲 路人甲

仙人甲

2026年5月27日 18:29 江苏

在小说阅读器读本章

去阅读

5月中旬，开发者安全圈被一个事件刷屏。

GitHub遭遇黑客入侵，约3800个内部代码库被外泄。

经调查，攻击入口是其员工电脑上一个被投毒的VS Code扩展。

黑客团队盗取了Nx Console插件核心开发者的token，并发布恶意版本到官方商店。

而一名GitHub员工不幸下载了此版本的插件，短时间内被扫盘，导致各种高级权限令牌泄漏。

后续，黑客便顺利通过了各种安全审查，长驱直入GitHub内部搬空了代码库。

此次事件令人深省：

只需要一台员工电脑上的一个编辑器扩展，就可以让全球最重视代码安全的平台之一，也被撕开一条口子。

更关键的是，这不是孤例。

过去一年，TeamPCP这类攻击组织已经把目标放在开源生态和开发者工具链上。

各种npm包、浏览器扩展、编辑器扩展等等，正在越来越频繁地成为攻击入口。

但是，很多团队对线上服务器、云权限、代码仓库有监控，却对其内部开发者本机装了什么扩展、跑了什么MCP、接了哪些Agent，几乎没有可见性。

甚至可能开发者自己本人也不清楚。

我们真的了解自己的开发环境吗？

过去的开发环境相对简单。一个IDE，一个Git，一个Node或Python，再加上一些常见命令行工具。

我们都大致知道自己的电脑上装了什么，也知道这些工具大概能做什么。

但现在不一样了。

电脑里，Claude Code、Cursor、Codex、MCP Server、各种浏览器AI插件、各种编辑器扩展，应有尽有。

它们拥有文件权限、终端权限、浏览器权限，甚至可以通过MCP接入GitHub、数据库、云服务和内部系统。

同时，越来越多原本没有完整计算机专业背景的人，也开始通过AI写代码、改项目、跑脚本、接MCP。

这些事本身当然是好事。各种工具提高了我们的工作效率，AI也降低了开发门槛。

但问题也随之出现了：

我们的开发环境变得更加复杂。几乎没人知道，自己本机到底挂了多少 Agent、MCP、扩展和权限。

而若是对自己的开发环境不清楚，自然被入侵的可能性也会增大。

Perplexity的解决方案

GitHub被黑之后的几天，Perplexity宣布开源Bumblebee，中文名大黄蜂。

当然，这里指的可不是变形金刚里的大黄蜂。

它是一个read-only inventory collector

翻译成人话就是：

一个只读的开发环境清点工具。

它主要扫描macOS和Linux开发者电脑上的包、扩展、开发工具元数据。

旨在解决一个重要的问题：

当某个安全公告说某个包、某个扩展、某个版本有风险时，哪些开发者机器上现在真的存在这个东西？

具体而言：

Bumblebee做的就是把分散在本机的各种依赖、扩展和配置，整理成结构化的NDJSON记录。

如果你再给它一份exposure catalog，也就是风险名单，它还能进一步标记命中的风险项。

你可以根据公开的供应链攻击活动记录，在风险名单进行添加信息，进而快速排查问题。

它强调read-only

也就是说，它不会执行npm ls、pip show、go list这类包管理器命令，也不读取源码文件。

只读取lockfile、包管理器安装元数据、扩展manifest，以及支持的MCP JSON配置。

这一点显得尤为重要。

因为如果一个安全工具为了检查风险，自己先开始执行命令、读源码、扫浏览器隐私数据，那它本身就会变成新的风险。

Bumblebee的使用

#

https://github.com/perplexityai/bumblebee/tree/main

我们可以从上述地址下载源码。

#

进入项目根目录，输入下述命令，完成编译和其自带的selftest。

# 编译go build ./cmd/bumblebee# 查看版本./bumblebee version# 内置自测./bumblebee selftest

接着就可以正式使用了。

Bumblebee有三种模式：

baseline模式适合做日常轻量扫描：它主要扫默认开发环境位置，比如用户工具链、编辑器扩展、浏览器扩展、MCP 配置等。

project模式扫你指定的项目目录。比如某个代码仓库、某个工作区。

deep模式更适合专项排查：扫你指定的大范围目录。比如整个Home目录。

只需执行：

bumblebee scan --profile 模式 --output file --output-file 输出文件

我在自己的电脑上进行了baseline扫描，结果一共输出了几百条package记录。

每条package记录包含生态系统、包名、版本、路径、来源文件、置信度等字段。

这些记录清晰地为我展示了当前的开发环境。

你以为自己只是装了Cursor、Claude、几个命令行工具。但实际环境里还有大量扩展、依赖、配置和插件。

它们分散在不同目录里，开发者很难关注到。

我还发现，Bumblebee对所获取的信息有脱敏处理。

如果MCP配置里有类似：

https://[email protected]/private/path?x=1

输出里只会保留：

https://example.com

token、路径、query、fragment都会被丢弃。

可见其对于敏感信息的处理十分有效，进一步增强了安全性。

此外，Bumblebee还可以根据用户提供的exposure catalog，也就是风险清单，来判断是否开发环境是否存在风险。

#

用户只需提供JSON文件列出受危害包，Bumblebee就可以自动标记匹配项并附置信度评级。

这个风险清单可以由你自己维护，随时根据新的安全风险消息来更新。

你也可以直接使用官方仓库里提供的threat_intel目录，里面是一些随时更新的已知供应链攻击或高风险组件的规则。

Bumblebee值得一用吗？

一眼看去，似乎Bumblebee的功能并不是那么强大，无法处理漏洞，只是做简单排查。

但我认为，Bumblebee的真正重要的地方在于：

让开发者开始看清自己的AI开发环境，去关注每一个细小的漏洞。

很多安全问题，并不是突然爆发的。

它们往往来自一个没人注意的插件、一条遗忘的配置，或者一次默认开放的权限。

安全的第一步，往往不是修复，而是先看见。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：仙人甲 路人甲 路人甲《Github被黑后，我尝试了Perplexity的AI开发风险扫描器》