Perplexity Bumblebee：无漏洞库的供应链扫描器设计思路

2026 年 5 月，Perplexity 开源了一个名为 Bumblebee 的小型 Go 二进制程序，并在几周内收获了数千个 GitHub star。从表面上看，这不过是今年各大 "AI 公司发布安全工具" 公告中的又一员。但仔细阅读其设计文档后会发现，Bumblebee 正在做一件几乎反主流的事：它是一款根本不附带漏洞数据库的供应链扫描器。不挂载 CVE 订阅、不内置恶意包列表、不声称"告诉你什么是危险的"。它扫描你的机器，精确告诉你安装了什么东西、在哪里，然后就此打住——等待你给它一份名单去比对。

这不是发布前忘了补上的功能限制，而是整套设计的核心前提。值得弄清楚其中的道理，因为这指出了当前开发者工具领域真正的缺口所在——缺口不在于漏洞数据库（这类数据早已商品化且供应充足），而是在于对大量开发机器上实际磁盘状况的快速、低摩擦的可见性，尤其是那些新出现的类别（MCP 服务器、AI 智能体技能、编辑器扩展），老牌扫描器从未为它们设计过探测能力。

Bumblebee 到底是什么

Bumblebee 是一款面向开发者端点的只读资产清单与暴露面匹配扫描器，由 Go 编写，零非标准库依赖，要求 Go 1.25+ 构建，使用 Apache License 2.0 授权。安装方式只需一条 go install 命令或下载静态二进制文件，运行后它会遍历文件系统，寻找包管理器元数据、锁文件、扩展清单和 MCP 配置文件——不执行任何操作、不联网获取威胁情报、无需提升权限。

它目前支持的生态包括：JavaScript 侧的 npm、pnpm、Yarn 和 Bun；Python 的 PyPI；Go modules；RubyGems；PHP 的 Composer；Homebrew；VS Code 及其他编辑器扩展；浏览器扩展；以及——考虑到其出品方——MCP（Model Context Protocol）服务器配置和 AI 智能体技能定义。

它的输出格式是换行分隔的 JSON（NDJSON）。这个细节说明白了 Bumblebee 真正面向的用户群体。NDJSON 不是你在终端里直接阅读的格式——它是那种你要用 jq 过滤、导入 SIEM、接进资产管理面板或事故响应时粘贴到表格里的格式。Bumblebee 被设计为流水线中的一个组件，而非独立的仪表盘产品。

工作机制

架构刻意收窄，而正是这个收窄带来了值得关注的有趣之处。

三种扫描模式。基线扫描（baseline）检查全局包根目录和已知工具链位置——成本足够低，可以通过 cron、launchd 或 MDM 推送脚本在整批机器上定时运行。项目扫描（project）针对配置好的开发目录，适合 CI 或特定仓库 checkout。深度扫描（deep）则遍历 $HOME 这样宽泛且明确的根目录——这是处理真实事故时才动用的选项，需要摸清某台机器触及过的所有痕迹，而非仅限常规可疑路径。

两条记录类型。每次扫描都会发出包记录（package records）——每发现一个组件就输出一行，包含生态、包名、版本、读取来源文件，以及置信度（high、medium 或 low，反映该元数据直接对应真实安装包还是推测得出）。当额外传入 --exposure-catalog 时，扫描器还会将每条包记录与目录交叉比对，为精确匹配（生态 + 包名 + 版本）或通配符（* 匹配该包所有版本）的条目发出发现记录（finding records）。

目录自备。这是关键。暴露面目录（exposure catalog）只是一个由运维人员提供的 JSON 文件——例如，从 GitHub Security Advisory、OSV.dev 订阅或内部事故通报（"我们刚发现 left-pad-plus@3.2.1 被入侵，请排查所有人"）中提取的包名及版本列表。Bumblebee 将目录视为可信的运维输入，对目录来源不做任何校验——其安全模型明确将目录完整性责任交给使用者，而非工具本身。

它读取元数据，不读取真相。Bumblebee 从不执行包管理器，也从不解析源代码——只是把锁文件和清单文件当作文本读取。这使得它可以在无沙箱环境下安全运行，但也意味着它会漏掉任何在认可的管理器账本之外安装的东西（手动引入的依赖、丢进 PATH 的二进制、全局安装而锁文件未跟踪的包）。

MCP 和智能体技能扫描目前仅支持 JSON。它读取 JSON 格式的 MCP 配置，但明确不解析 Codex 的 TOML 配置或 Continue 的 YAML 配置——如果你的团队标准化在这两者之一，这是一个现实缺口。它会解析 MCP 配置内部的 env 块（凭证常驻于此），但小心地从不将凭证值本身输出到记录中，只输出该块存在这一事实。

运行起来什么样

这个工作流刻意朴实无华。一次基线资产清单扫描只需一条命令，无需额外参数：

bumblebee scan --profile baseline --output inventory.ndjson

输出示例，每行一个 JSON 对象：

{"type":"package","ecosystem":"npm","name":"left-pad-plus","version":"3.2.1","source":"/home/dev/app/package-lock.json","confidence":"high"}
{"type":"package","ecosystem":"mcp","name":"internal-search-mcp","version":"0.4.0","source":"/home/dev/.config/mcp/servers.json","confidence":"Medium"}

要真正获得发现记录而不仅是资产清单，你需要编写（或获取）一个目录文件——一个扁平的 JSON 列表，每条记录包含 {ecosystem, name, version} 元组，来自一份公告、内部事故通报或转换后的 OSV/GHSA 订阅——然后传进去：

bumblebee scan --profile deep --exposure-catalog ./ir-2026-08.json --output findings.ndjson

此时匹配引擎启动，任何包记录的（生态、包名、版本）元组与目录条目精确匹配（或匹配 * 通配符）的都会被作为第二条独立的发现记录发出，并引用原始包记录。还有一个自带的 bumblebee selftest 命令专门用于验证集群部署后扫描器本身是否静默失效——值得注意，因为"扫描器运行了但没输出"和"扫描器正确地什么都没发现"在 NDJSON 里看起来完全一样，除非你先验证了二进制本身工作正常。

这套工作流单独拎出来没什么新奇的地方——很多工具都会读取锁文件并输出 JSON。真正值得注意的，是从"我们担心某个名字"到"列出所有装有它的机器"之间所需移动的零件少得多么离谱——这正是在事故响应的时效压力下你所需要的特性，没有人愿意在凌晨两点去排错扫描器自身的依赖链。

这里真正的新东西是什么

传统软件成分分析（SCA）工具——Snyk、Trivy、OSV-Scanner、Socket.dev——都围绕同一个核心循环构建：解析你的依赖树，将其与维护中的漏洞数据库（NVD、GHSA、OSV 或专有订阅）交叉比对，然后按严重性排列发现结果。这个循环成熟且有效。但它拓展到新软件类别的速度也很慢，因为在该循环产生任何输出之前，必须有人先为那个类别构建并维护一个漏洞数据库。

Bumblebee 通过完全不附带数据库把这个步骤彻底跳过了。它转而优化问题的另一半——发现环节——并覆盖了主流 SCA 工具基本忽略的表面区域：MCP 服务器、AI 智能体技能目录，以及驻留在开发者真实机器上、而不仅是在 package.json 里声明的那些编辑器/浏览器扩展。这是一种有意识的押注：在活跃事故期间，真正的瓶颈不是"我们知不知道这个包是坏的"（这类信息通常在几小时内就能从 GitHub 公告、供应商邮件或 Twitter 上得知），而是"我们的 400 台开发机器里眼下究竟哪些有它，好让我们开始修复"。在今天用 Snyk 或 Trivy 回答这第二个问题，意味着要么它们已经索引了你所担心的那个确切的生态，要么你就要在时间压力下写定制工具。

另一个转变在于"供应链"的定义边界。一两年前，这这个词指的是 npm 和 PyPI 包。MCP 服务器的大爆发——通过让配置文件指向一个 URL 来安装，通常没有 registry、没有代码审查、加载它们的 AI 智能体拥有直接文件系统和网络访问权限——以及"AI 智能体技能"作为一种可安装单元的并行崛起，创造了一个基本上未经审计的新型代码类别，运行在拥有开发者级信任的环境中。Perplexity 作为一家同时推出自家 AI 智能体产品的公司，相当于承认其自身的生态（以及所有人的 MCP 工具）已经跑在了为 npm 时代构建的审计工具前面。这才是这里更有意思的故事，而非"AI 公司发布了扫描器"。

为什么开发者真正应该关注

MCP/skills 的攻击面是真实存在的，而且目前缺乏工具支持。与 npm 包至少要经过注册表发布步骤不同，MCP 服务器通常只是"把这个 URL 加到配置文件里，然后重启编辑器"。目前还没有类似 npm audit 的 MCP 服务器审计工具，大多数现有的 SCA 产品也没有跟上。如果你的团队有开发者在从任意来源安装 MCP 服务器或 Agent 技能——而且如果你们使用 Claude Code、Cursor 或类似工具，你们的一些开发者几乎肯定正在这样做——除非有人自己动手搭建，否则你目前几乎无法了解整个团队实际配置了哪些 MCP。

它的部署成本确实很低。零依赖的静态 Go 二进制文件意味着不需要安装运行时、不需要处理 Python 虚拟环境冲突、不需要维护容器镜像。你可以通过 MDM 推送它、在 CI 的 shell 脚本中运行它，或者在事件响应时把它 scp 到某台机器上，几秒钟内就能得到结构化输出。这种运维上的简洁性在真正的紧急演练中比听起来更有价值——你最不想遇到的就是一个本身还需要 pip install 才能运行的扫描器。

它侧重于组合而非竞争。因为不附带漏洞数据库，Bumblebee 并不是要取代 Snyk 或 Dependabot 进行日常 CVE 分诊——它是在它们旁边作为一个快速、目录驱动的层面存在，工作是"我们有一份已知危险项的清单，告诉我们在哪里有它们"。这比其他大多数 SCA 营销承诺的职责范围更窄，但那些工具确实做不好这件事：把一份手写的或来自 advisory 的 IOC 清单，在几分钟内变成覆盖整个集群的答案。

设计上默认只读降低了采用门槛。需要提升权限或执行不受信任的包管理器命令的安全工具更难广泛推广，特别是人们都很保护自己的开发笔记本。只用调用者自身权限读取文件的工具更容易获得广泛推广的批准。

没有供应商锁定或席位定价需要谈判。Snyk 和类似平台按开发者或按扫描量计费，一旦发现、抑制策略和策略异常都存在于别人的仪表板中，你使用的每个月切换成本都在增加。Bumblebee 的全部状态就是一个你拥有的 JSON 目录文件和 NDJSON 输出——如果决定停用不需要导出任何东西，不存在只有在供应商产品内部才有的仪表板历史，也没有最低合同要求才能从一次事件响应运行中获得价值。对于安全相关的工具来说，这是一个更低门槛的方式来试用，然后在它最终是否能在你的技术栈中赢得永久位置之前做出决定。

事件响应分诊。供应链妥协被披露后（一个被入侵的 npm 维护者账户、一个被投毒的 MCP 服务器、一个恶意的 VS Code 扩展）。你用受影响的包/版本构建或接收一个暴露目录，通过现有的集群管理工具在受影响的机器上运行深度扫描，立即得到精确的命中/未命中答案的 NDJSON——而不是要求每个开发者手动检查。

定期基线卫生。安排对开发机器的基线扫描（Bumblebee 明确将调度留给操作者——cron、launchd、systemd 定时器或 MDM），并将包记录流馈送到现有可观测性系统中，独立于任何单一漏洞源，在整个组织范围内随时间构建实际上安装了什么的历史清单。

MCP/Agent 技能治理。即使没有暴露目录，仅仅为 Bumblebee 的包记录输出运行它，也能让你第一次真正了解配置在开发者机器上的 MCP 服务器和 Agent 技能——这是在你甚至能写出关于允许什么的合理政策之前的有用基础工作。

馈送到 SIEM 或数据湖。NDJSON 输出可以被任何理解结构化日志的东西轻松摄取，因此 Bumblebee 输出可以成为与其它端点遥测相关联的另一个信号源，而不是没人读的独立报告。

无需等待工具支持即可进行 vendor/advisory 交叉检查。当一个新的生态特有的 advisory 发布，而干流 SCA 厂商还没有为其建立索引时，你可以自己将 advisory 转换为目录 JSON 文件，并在当天得到答案。

收购前或合并前的尽职调查。因为不需要安装代理也不需要提升权限，深度扫描是一种低摩擦的方式，可以在两个工程组织合并其基础设施之前，获得代码库实际运行时依赖足迹的诚实清单——包括在任何地方都没有记录的 MCP 工具。

炒作没有告诉你的

开箱即用，它什么都找不到。因为没有捆绑漏洞数据库，在没有 --exposure-catalog 标志的情况下运行 Bumblebee 只会给你一个清单和零发现——仅此而已。我读到的每篇报道都将其包装为"供应链扫描器"，但没有突出说明：你，作为用户，全权负责 sourcing、构建和维护那些让它除了清单之外还有用的目录。这是一个与 Trivy 这类工具本质不同的价值主张，Trivy 从安装的那一刻起就有用。

仅支持 macOS 和 Linux。项目的当前范围中任何地方都没有提到 Windows 支持。对于拥有大量 Windows 开发机器的组织来说，这是一个真正的覆盖缺口，而不是一个脚注。

非 JSON 的 MCP 配置对它来说是不可见的。Codex 基于 TOML 的配置和 Continue 的 YAML 配置明确不受支持。如果你的组织 AI 工具组合偏向其中任一，Bumblebee 的 MCP 扫描能力比营销所暗示的（"覆盖 MCP 配置"）要弱得多。

置信度级别暗示了一个在任何地方都没有量化的真实误报/漏报权衡。包记录上的高/中/低置信度字段是对元数据仅扫描固有近似性的默认承认——来自模糊清单的低置信度推断可能在两个方向上都出错，公开文档中没有任何内容让你了解在实践中这种情况发生的频率。

暴露目录是一个未经身份验证的信任边界。项目自己的安全模型明确指出目录是受信任的操作员输入，没有内置完整性检查。对于一个范围如此狭窄的工具来说，这是一个合理的设计选择，但这确实意味着工具的实际安全价值取决于你组织 sourcing 和审查目录文件的过程——大多数团队还没有这个流程，因为直到现在才有了会消费这种目录的工具。

它是只读的，这也意味着它是被动的。Bumblebee 告诉你的是已经在磁盘上的东西。它不会做任何事情来首先防止安装恶意的 MCP 服务器或扩展，也不会在你有新东西出现的瞬间提醒你——你必须不断重新运行它。

阅读这个表格的诚实方式：Bumblebee 与其他三个工具在日常漏洞管理方面不属于同一竞争类别。它是一个更窄、更快的工具，做一件特定的工作——"给定一个名称，到处找它"——而这个工具恰好也覆盖了其他工具尚未触及的生态系统。

去掉"Perplexity 开源安全工具"的包装，剩下的东西是一个真正范围良好的基础设施：一个零依赖、只读的清单收集器，它诚实地说明自己是一个清单收集器，而不是过度销售自己是漏洞扫描器。这种克制是罕见的——这个领域的大多数工具都捆绑了一个平庸的、维护不完整的漏洞库，只是为了让演示中有红色的发现。Bumblebee 默认什么都不附带，这是一个可信的信号，表明团队优化的是工具的正确性和可信度，而不是让它立刻看起来令人印象深刻。

更有趣的潜台词是它对 Perplexity 自身风险模型的暗示。一家积极推出 AI 智能体产品——拥有自己的 MCP 集成和技能生态系统——的公司，在任何主要 SCA 厂商以同等深度做这件事之前，就构建并开源了这个用于审计该类别软件暴露面的工具。这是机构层面的深谋远虑还是对内部发生的特定事情的反应，在我找到的公开资料中没有说明，而且值得明确的是：没有事件被记录为直接触发因素——但时机恰好在 MCP 服务器采用规模已经超过了任何注册表目前所能管理的水平，这不是巧合。

对于我读到的报道，哪里是我会 push back 的：几篇文章将其描述为填补了 AI 工具的"SBOM 空白"，这夸大了它。SBOM 是一个声明性的、穷尽的清单；Bumblebee 是一个带有置信度评分推断的时间点文件系统采样。它更接近于带结构化输出的 find 命令和一个匹配层，而不是像 Syft 这样的真正 SBOM 生成器。如果你是在评估合规用例而不是运营用例，这个区别很重要。

我还要标记一个项目自身文档已经明确说明但报道中淡化了结构性风险：暴露目录信任边界意味着该工具的实用性完全取决于一个组织流程——即获取、验证和维护目录文件——而大多数团队目前并没有这个流程，因为此前并没有消费此类文件的工具。将扫描器开源并不会自动产生这个流程。如果一个团队采用 Bumblebee 期许拿到手就能防护，却从不养成向其投喂最新目录的习惯，那么从安全模型角度看，他们会因为"什么都没发现"而获得虚假的安全感——因为它根本不知道要查找什么。该工具对此是坦诚的；风险在于并非每个使用者都会足够仔细地阅读安全模型，从而注意到这一点。

谁应该现在就尝试，谁应该等待

如果你的团队正在为一批开发人员机器进行事件响应，且目前没有快速方式回答"谁安装了这个包/版本"，或者你想对团队工程组织中实际配置了哪些 MCP 服务器和 AI 智能体技能获得第一次诚实的清单——这个问题目前几乎没有人有好的答案——那就现在尝试。

如果你的组织大量使用 Windows，或者你的 AI 工具主要围绕 Codex 或 Continue 配置而非基于 JSON 的 MCP 设置构建——在（如果有）这些支持添加之前，你会得到实质性降低的覆盖率——那就等待。

如果你的实际需求是持续、自动更新的 CVE 覆盖和修复指导，就跳过它；这不是该工具的职责，更准确的心智模型是将其与 Snyk、Trivy 或 OSV-Scanner 配合使用，而不是替代它们。

你怎么看待刻意不内置威胁情报、将 IOCs 来源完全交给运营商的工县——对于快速、可信的事件响应工具来说，这是正确的权衡，还是只是把问题中最困难的部分转移到了没有成熟维护暴露目录流程的团队身上？

GitHub - perplexityai/bumblebee

bumblebee/SECURITY.md at main

Perplexity Open-Sources Bumblebee: A Read-Only Supply-Chain Scanner for Developer Endpoints - MarkTechPost

Perplexity's Bumblebee: a read-only supply-chain check for the developer laptop

Model Context Protocol