文章总结： 文档分析了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开发风险扫描器》