5月25日消息,Perplexity AI 在 GitHub 上开源 Bumblebee——一款面向 macOS 和 Linux 的只读(read-only)开发者终端扫描器,专门用于检测开发者本机上是否安装了已知存在供应链投毒风险的包、扩展或 AI 工具配置。仓库地址 github.com/perplexityai/bumblebee,采用 Apache 2.0 许可证。Bumblebee 此前已在 Perplexity 内部用于保护搜索产品、Comet 浏览器和 Computer Agent 的开发环境,覆盖 8 大包管理器及主流 AI 编程工具配置文件,定位是填补 SBOM 与 EDR 之间长期被忽视的"开发者本机混乱状态"这一盲区。 8 大包管理器 + MCP 配置全覆盖
Bumblebee 的覆盖面针对当前供应链攻击的实际打击面设计。包管理器层覆盖 npm、pnpm、Yarn、Bun、PyPI、Go modules、RubyGems、Composer 共 8 个主流生态;AI 工具配置层覆盖 MCP(Model Context Protocol,包括 Claude Desktop、Cursor 等的 claude_desktop_config.json 等文件);编辑器扩展层覆盖 VS Code、Cursor、Windsurf、VSCodium;浏览器扩展层覆盖 Chromium 系列(Chrome、Edge、Arc 等)和 Firefox。 这套覆盖范围对应的是近期实际发生的攻击战役。Perplexity 在技术文档中明确点名"Mini Shai-Hulud 系列"——这一轮供应链攻击命中了 npm、PyPI、RubyGems、Go modules 和 Composer 等多个生态,波及 TanStack、SAP、Zapier 等公司。Bumblebee 要回答的是一个具体且紧迫的问题:当某个安全公告点名某个具体版本的包存在风险时,组织内到底哪些开发者机器上还装着它? 只读架构:拒绝执行任何 install 脚本
Bumblebee 的核心设计差异在于"绝对只读"。它不调用任何包管理器(npm/pip/bun 等命令一律不跑),不执行任何 install 或 postinstall 脚本,不读取源码,只读取锁文件、manifest 和元数据。这一约束直接回应了一类真实威胁:npm 等生态的恶意包通常依赖 postinstall 脚本触发,传统扫描器一旦在扫描过程中调用了包管理器或解析了某些工具,扫描行为本身就可能成为攻击触发点。
工程实现上同样克制。Bumblebee 用纯 Go 编写,零非标准库依赖,单二进制即可运行,安装命令仅为 go install github.com/perplexityai/bumblebee/cmd/bumblebee@latest。输出格式选用 NDJSON(每行一条 JSON 记录),便于脚本去重、聚合,诊断信息走 stderr 分离。工具本身是一次性扫描器(one-shot scanner),每次调用执行一次扫描就退出,调度交给 cron、launchd、systemd 或企业 MDM 工具自行编排。
三种扫描档位 + 与 Computer 联动响应
Bumblebee 提供三种扫描档位。baseline 用于日常轻量盘点,扫描全局/用户级包根目录、语言工具链、编辑器与浏览器扩展、MCP 配置;project 针对配置好的开发目录(如 ~/code、~/src)做项目级扫描;deep 用于事件响应阶段的深度扫描,由操作者指定根目录,典型场景是在主动应急时直接扫整个 $HOME。
更关键的是 Bumblebee 与 Perplexity Computer 的联动。Computer 是 Perplexity 的 AI Agent 工具,一旦发现新的供应链风险,可以自动触发 Bumblebee 的深度扫描,并生成结构化报告供安全团队处理。Perplexity CEO Aravind Srinivas 在发布时同步表态,要把 Perplexity Computer 这类 Agent 工具嵌入企业,必须持续投入安全工程,思路是把工具放进 Agent 沙箱,让安全工作流自主运行。Bumblebee 是这套"Agent + 自动安全工作流"思路的第一块拼图。
对位 SBOM 与 EDR:填补开发者本机这一空白
竞品定位上,Bumblebee 并不打算替代现有方案。SBOM(软件物料清单)管的是构建产物层面的成分清单,关注的是发布到生产环境的依赖快照;EDR(端点检测与响应)管的是运行时行为,关注的是进程、网络、文件系统的实时事件。两者中间夹着一大块没人系统管理的区域——开发者本机上散落的锁文件、未提交的实验依赖、随手装的编辑器扩展、各种 MCP 配置文件。这正是近一年供应链攻击的实际入口,也是 Bumblebee 的核心战场。
可比项目方面,开源生态里已有 OSV-Scanner(Google)、Trivy(Aqua Security)、Snyk CLI 等工具,但这些工具大多以构建产物或代码仓库为单位,针对个人开发机的全局态扫描不是核心场景;专门覆盖 MCP 配置和 AI 编辑器扩展的工具几乎没有。Bumblebee 的差异化不在算法,而在覆盖位置选得准——选了一个 AI 编程工具大规模铺开后才暴露出来的新攻击面。
局限与变数:一次性扫描,依赖暴露目录质量
需要保留几个变量。其一,Bumblebee 不做漏洞推断、不做 CVE 匹配,它的判断完全依赖外部传入的"暴露目录"(exposure catalog)文件——这意味着扫描结果的质量直接取决于运营方自己维护的威胁情报,工具本身不提供持续更新的官方目录。其二,只读设计放弃了主动检测能力,无法识别那些通过混淆或动态生成方式隐藏的恶意包。其三,平台仅限 macOS 和 Linux,Windows 开发者目前无法直接使用,社区已有用户在 X 上反馈这一限制。其四,作为一次性扫描器,定期化执行的运维成本由使用方自己承担,缺少官方推荐的调度模板。对小团队而言,从安装到接入工作流仍有一定门槛。