Bumblebee 和 npm audit、pip-audit 这些官方工具有什么区别？

切的问题不同。npm audit 和 pip-audit 基于 CVE 数据库做版本范围匹配——某个包的 1.0-2.3 版本有已知漏洞就全部标红，这在新蠕虫爆发初期会产生大量误报。Bumblebee 做精确版本匹配——只有 event-stream@3.3.6 这个被投毒的精确版本才告警，3.3.5 和 3.3.7 不受影响。而且 npm audit 必须执行 npm install 之后才能跑，Bumblebee 只读元数据文件不调用包管理器，扫描本身不会引入风险。另外 Bumblebee 覆盖了 MCP 配置和编辑器扩展，这是所有官方审计工具都没涉及的领域。

Bumblebee 的威胁情报数据从哪来？更新频率怎样？

威胁情报在项目仓库的 threat_intel/ 目录下，目前 8 个目录文件、654 条记录，覆盖 Mini Shai-Hulud、AntV、GemStuffer、Laravel Lang、node-ipc 凭证窃取、nx-console VS Code 入侵等已知攻击事件。数据来源是 Perplexity 安全团队手动策划加社区贡献。更新方式是跟随 Go 工具链——每次 go install 会拉取最新版本，威胁情报嵌入二进制文件中。目前没有独立的实时更新机制，这是一个局限。

MCP 配置扫描具体在扫什么？为什么说 MCP 是新的攻击面？

Bumblebee 会读取 Claude Desktop、Cursor、Gemini CLI 等工具的 MCP 配置文件，检查里面引用的 MCP Server 是否指向已知恶意包或被篡改的路径。MCP 是新的攻击面因为它给了 AI 助手执行能力——一个被投毒的 MCP Server 不仅能在你的机器上运行恶意代码，还能通过 AI 助手的工具调用链泄露环境变量、SSH 密钥、数据库凭证。传统供应链攻击影响的是代码执行环境，MCP 投毒影响的是 AI Agent 的决策链路，危害更隐蔽也更难检测。

Bumblebee 适合放到 CI/CD 里自动化运行吗？

完全适合，而且推荐。baseline profile 扫描全局包目录和工具链，适合在开发者机器上定期跑；project profile 扫描项目代码目录，适合放到 CI pipeline 里在 PR 合并前检查。由于 Bumblebee 是单静态二进制、零依赖，CI 里加一行 go install + bumblebee scan 就行，不需要额外装运行时。退出码非零表示发现威胁，可以直接接 CI 的 gate 判断。唯一要注意的是 CI 环境通常没有编辑器扩展和浏览器扩展，这些扫描项会自动跳过。

不支持 Windows 对企业用户影响大吗？有替代方案吗？

影响取决于团队构成。如果开发团队全用 macOS 或 Linux，没有影响。如果有 Windows 开发者，可以在 WSL2 里运行 Bumblebee 作为临时方案，但 WSL2 的包目录路径和原生 Windows 不同，需要手动指定扫描目录。企业级替代方案可以考虑 Socket.dev（商业产品，支持全平台）或 Snyk（专注 CVE 但覆盖 Windows）。Bumblebee 的 GitHub Issues 里已经有 Windows 支持的 feature request，社区呼声较高，预计后续版本会跟进。

Bumblebee 速评：Perplexity 开源的 AI 供应链安全扫描器值不值得用

💡 一句话总结：Bumblebee 回答的问题不是「我的依赖有没有已知漏洞」，而是「那个昨天刚爆出的恶意包，精确的那个版本，是不是就装在我这台机器上」。一周 1,450+ Stars 说明开发者社区等这个工具等了很久。

背景：为什么 2026 年供应链安全需要新工具

5 月 22 日，Perplexity AI 在 GitHub 上开源了 Bumblebee——一个专门扫描开发者机器上恶意依赖的 Go 工具。发布一周内拿到 1,450+ Stars，在 Hacker News 上引发了超过 200 条讨论。

为什么是现在？因为 2026 年的供应链攻击已经从「偶发事件」变成了「常态化战争」。

5 月 11 日的 TeamPCP 攻击是直接导火索。这是近年来规模最大的供应链投毒事件之一：攻击者在 npm 和 PyPI 上发布了 160+ 个恶意包，影响面包括 Mistral AI、UiPath 等知名公司，以及一个每周 1,200 万下载量的 React 工具库。这些包不是新注册的可疑名字——很多是通过 typosquatting（拼写劫持）或维护者账号泄露注入到已有热门包中的。

Sonatype 的 2026 Q1 报告给出了更触目惊心的数字：仅 Q1 就发现 21,764 个开源恶意包，其中 75% 针对 npm 生态。这意味着平均每天有 240+ 个恶意包被上传到公共注册表。

问题是，现有的安全工具并不擅长应对这种类型的攻击。

现有工具的盲区

npm audit、pip-audit、govulncheck——这些官方审计工具的设计目标是 CVE 扫描。它们的工作方式是：

读取依赖树
对照 CVE 数据库做版本范围匹配
报告哪些依赖有已知漏洞

这在应对传统安全漏洞时工作得很好。但供应链投毒攻击不一样——一个被投毒的包通常在发现后几小时内就被从注册表移除，CVE 分配可能要几天甚至几周。在这个时间差内，范围匹配扫描器要么查不到（CVE 还没发布），要么误报严重（版本范围太宽）。

Bumblebee 回答的是一个更精确的问题：某个被入侵的精确版本，是否安装在这台机器上。

不是「这个包的 1.0-2.3 有漏洞」，而是「[email protected] 这个被注入了 flatmap-stream 后门的精确版本，在不在你的 node_modules 里」。

三个核心设计原则

翻完 Bumblebee 的源码和文档，三个设计决策值得展开讲。

原则一：只读（Read-only）

Bumblebee 只读取元数据文件——package.json、package-lock.json、requirements.txt、go.sum、Gemfile.lock、composer.lock 等。它永远不修改任何文件，永远不写入任何东西。

这不是懒，是安全设计。在一个讨论供应链安全的工具里，如果工具本身需要写权限或修改系统状态，那就是在用一个潜在的攻击面来检测另一个攻击面。

原则二：零依赖（Zero dependencies）

整个项目用纯 Go 标准库实现，go.mod 里除了 Go 本身没有任何第三方依赖。编译产物是一个单静态二进制文件。

这意味着 Bumblebee 自身的攻击面为零。不存在「安全扫描工具的依赖被投毒」这种讽刺场景。对比一下——很多 Node.js 写的安全工具自己就有几十个依赖，谁来保证那些依赖是干净的？

从工程角度看，零依赖还有一个好处：你不需要为了装一个安全扫描器而先确认你的包管理器是安全的。下载二进制文件、放到 PATH 里、运行。没有 npm install，没有 pip install，没有依赖解析。

原则三：不执行包管理器

这是最反直觉但最重要的设计决策。

大多数依赖扫描工具的工作方式是调用包管理器获取依赖树——npm ls、pip list、bun pm ls。Bumblebee 永远不执行这些命令。

原因很直接：如果一个恶意包在安装时就执行了恶意代码（postinstall 脚本），那调用 npm ls 的过程可能就触发了攻击。Bumblebee 通过直接解析 lockfile 和元数据文件来获取依赖信息，绕过了这个风险。

⚠️ 这三个原则组合在一起的意思是：你可以在一台可能已经被入侵的机器上安全地运行 Bumblebee，因为它只读、不执行、不依赖任何可能被篡改的组件。这在事故响应（Incident Response）场景下极其重要。

生态覆盖：不只是包管理器

Bumblebee 的扫描范围比名字暗示的要广。它覆盖四层：

第一层：包管理器

包管理器	扫描目标	备注
npm	package-lock.json, node_modules	全球最大攻击面，75% 恶意包在这里
pnpm	pnpm-lock.yaml	硬链接结构，扫描路径不同
Yarn	yarn.lock	Classic 和 Berry 都支持
Bun	bun.lock（文本格式）	不支持 bun.lockb 二进制格式
PyPI	requirements.txt, Pipfile.lock, poetry.lock	覆盖主流 Python 包管理方案
Go modules	go.sum	精确到 commit hash
RubyGems	Gemfile.lock	Rails 生态
Composer	composer.lock	PHP/Laravel 生态

八大包管理器覆盖了绝大多数后端和前端开发场景。缺失的是 Cargo（Rust）和 Maven/Gradle（Java）——这两个生态的供应链攻击案例相对较少，但不是没有。

第二层：MCP 配置文件（首创）

这是 Bumblebee 最有前瞻性的部分。

Bumblebee 会扫描以下工具的 MCP 配置文件：

Claude Desktop：~/.config/claude/config.json 或 ~/Library/Application Support/Claude/claude_desktop_config.json
Cursor：.cursor/mcp.json
Gemini CLI：Gemini 的 MCP 配置路径

它检查配置中引用的 MCP Server 是否指向已知恶意包或被篡改的路径。

为什么这很重要？因为 MCP 配置是 2026 年最容易被忽视的攻击面。

一个被投毒的 npm 包最多在你的机器上执行恶意代码。但一个被投毒的 MCP Server 不仅能在你的机器上执行代码，还能通过 AI 助手的工具调用链做更多事情：

读取你的环境变量（API Key、数据库密码）
访问你的文件系统
发起网络请求泄露数据
更隐蔽的是——它能影响 AI 助手的行为，让 AI 在你不知情的情况下执行恶意操作

传统供应链攻击的检测相对成熟——进程监控、网络流量分析都能发现异常行为。但一个通过 MCP 协议与 AI 助手交互的恶意 Server，它的「恶意行为」表现为正常的工具调用，极难区分。

Bumblebee 是第一个把 MCP 配置文件当安全面来扫描的开源工具。

第三层：编辑器扩展

扫描 VS Code 等编辑器的已安装扩展列表，对照已知的恶意扩展数据库。2026 年已经出现过多起 VS Code 扩展被入侵的案例——比如 nx-console 扩展被注入后门，影响了数十万开发者。

第四层：浏览器扩展

扫描 Chrome、Firefox 等浏览器的扩展目录，检查是否安装了已知恶意扩展。浏览器扩展的权限模型比编辑器扩展更危险——一个恶意浏览器扩展可以读取所有网页内容、窃取 cookie 和 session token。

扫描 Profile：三级深度

Bumblebee 提供三个扫描 Profile，对应不同的使用场景：

baseline（默认）

bumblebee scan --profile baseline

扫描范围：

全局和用户级包目录（/usr/local/lib/node_modules、~/.local/lib/python*/site-packages 等）
语言工具链（Go 的 GOPATH/pkg/mod、Ruby 的 gem 目录等）
编辑器扩展
浏览器扩展
MCP 配置文件

适用场景：日常安全检查。建议每天或每次安装新工具后跑一次。

project

bumblebee scan --profile project --project-dirs ~/code,~/src

在 baseline 的基础上，额外扫描指定的开发目录。会递归遍历目录树，查找所有项目中的 lockfile 和 node_modules。

适用场景：CI/CD 流水线，PR 合并前检查。

deep

bumblebee scan --profile deep --project-dirs ~/

最彻底的扫描模式，通常在事故响应中使用。直接指定用户 home 目录作为扫描根，不遗漏任何角落。

适用场景：安全团队在确认受到攻击后的全面排查。日常开发不建议用——扫描时间会很长。

威胁情报：654 条精确记录

Bumblebee 的威胁情报存储在项目的 threat_intel/ 目录下，目前包含 8 个目录文件、654 条记录。

覆盖的已知攻击事件包括：

攻击事件	生态	影响
Mini Shai-Hulud	npm + PyPI	160+ 恶意包，TeamPCP 攻击
AntV 投毒	npm	数据可视化库被注入后门
GemStuffer	RubyGems	批量上传恶意 gem
Laravel Lang	Packagist/Composer	PHP 国际化包被入侵
node-ipc 凭证窃取	npm	知名包维护者主动植入恶意代码
nx-console VS Code 入侵	VS Code 扩展	编辑器扩展被注入后门

关键设计：所有记录都是精确版本匹配，不是版本范围。

这意味着如果 lodash 的某个版本被投毒（假设是 4.17.21-compromised），Bumblebee 只会标记这个精确版本，不会把 4.17.21 到 4.18.0 之间所有版本都标红。在新蠕虫爆发的混乱期，这种精确性能大幅减少误报，让安全团队把精力集中在真正的威胁上。

威胁情报的更新方式是跟随工具版本——每次 go install 会拉取包含最新威胁情报的二进制文件。目前没有独立的实时更新机制，这意味着在新攻击爆发后到 Bumblebee 发新版本之间会有一个空窗期。

安装与实操

环境要求

Go 1.25+（2026 年 5 月发布的最新稳定版）
macOS 或 Linux（不支持 Windows）

安装

go install github.com/perplexityai/bumblebee@latest

没有 npm install，没有 pip install，没有 Docker。一行命令，下载编译完成后得到一个约 12MB 的静态二进制文件。

基础扫描

# 默认 baseline 扫描
bumblebee scan --profile baseline

# 扫描项目目录
bumblebee scan --profile project --project-dirs ~/code

# 多个目录用逗号分隔
bumblebee scan --profile project --project-dirs ~/code,~/work,~/oss

输出示例

扫描结果会输出已检查的包数量、匹配的威胁数量和详细信息：

Bumblebee v0.1.0 — Supply Chain Security Scanner
=================================================

Profile: baseline
Scanning global packages...
  npm global: 47 packages checked
  PyPI user:  123 packages checked
  Go modules: 89 packages checked

Scanning editor extensions...
  VS Code: 34 extensions checked

Scanning browser extensions...
  Chrome: 12 extensions checked

Scanning MCP configurations...
  Claude Desktop: 3 servers checked
  Cursor: 1 server checked

Results:
  Packages scanned: 271
  Extensions scanned: 46
  MCP servers scanned: 4
  Threats found: 0

✓ No known threats detected.

如果发现威胁，输出会包含精确的包名、版本、威胁类别和建议的处理措施。退出码非零，可以直接接 CI 的 gate 判断。

放入 CI/CD

在 GitHub Actions 中使用：

- name: Install Bumblebee
  run: go install github.com/perplexityai/bumblebee@latest

- name: Scan dependencies
  run: bumblebee scan --profile project --project-dirs .

在 GitLab CI 中使用：

security-scan:
  image: golang:1.25
  script:
    - go install github.com/perplexityai/bumblebee@latest
    - bumblebee scan --profile project --project-dirs .

竞品对比

特性	Bumblebee	npm audit	Socket.dev	Snyk
匹配方式	精确版本	CVE 范围	行为分析	CVE 范围
是否执行包管理器	否	是	否	是
自身依赖数	0	N/A（内置）	多	多
MCP 配置扫描	是	否	否	否
编辑器扩展扫描	是	否	否	否
浏览器扩展扫描	是	否	否	否
跨生态覆盖	8 种包管理器	仅 npm	npm + PyPI	多语言
价格	免费开源	免费	免费+付费	免费+付费
Windows 支持	否	是	是	是
威胁情报来源	手动策划	NVD/GitHub Advisory	自有 ML 模型	Snyk DB

Bumblebee 的独特定位：它不是 npm audit 或 Snyk 的替代品，而是补充品。npm audit 告诉你「这个包有 CVE」，Snyk 帮你自动修复依赖版本，Socket.dev 用行为分析检测可疑包。Bumblebee 回答的问题比这些都更具体——「昨天爆出的那个投毒版本，在不在你的机器上」。

最佳实践是叠加使用：CI 里跑 npm audit + Bumblebee，前者覆盖已知 CVE，后者覆盖零日投毒。

局限性分析

Bumblebee 虽然设计精巧，但作为 v0.1 版本有几个明确的局限：

不支持 Windows

目前只支持 macOS 和 Linux。对于 Windows 开发者，WSL2 是一个临时方案，但 WSL2 的包目录路径和原生 Windows 不同，需要手动指定扫描目录。GitHub Issues 里已有 Windows 支持的 feature request。

不解析 Bun 二进制 lockfile

Bun 有两种 lockfile 格式：文本格式的 bun.lock（v1.2+ 引入）和二进制格式的 bun.lockb（默认）。Bumblebee 只支持文本格式。如果你的项目用的是 bun.lockb，需要先运行 bun install --save-text-lockfile 生成文本格式的 lockfile。

威胁情报无实时更新

654 条记录是静态嵌入二进制文件的，更新需要重新 go install。在新的大规模攻击爆发后，可能需要等 Perplexity 团队发版才能检测到新威胁。相比之下，Socket.dev 的 ML 模型可以实时检测未知威胁。

不替代行为分析

Bumblebee 的检测逻辑是已知威胁匹配——它只能发现已经被记录在威胁情报目录中的恶意包。对于全新的、还没有被发现的供应链攻击，它无法检测。这是精确匹配方案的固有限制。

缺少 Cargo 和 Maven/Gradle 支持

Rust 和 Java 生态暂未覆盖。虽然这两个生态的供应链攻击案例较少，但 Maven Central 的 typosquatting 问题一直存在，Cargo 社区也出现过恶意 crate。

适用场景建议

强烈推荐使用的场景

使用 AI 编码助手的开发者：如果你在用 Claude Desktop、Cursor、Gemini CLI 并配置了 MCP Server，Bumblebee 是目前唯一能扫描这些配置的开源工具
事故响应团队：deep profile 适合在确认攻击后快速排查受影响的机器
CI/CD 安全加固：project profile 可以在 PR 合并前检查新引入的依赖

可以考虑使用的场景

个人开发者：每周跑一次 baseline 扫描作为安全习惯
开源项目维护者：在 CI 中加一层检查，保护贡献者

暂时不适合的场景

Windows 环境：等官方支持或用 WSL2 过渡
需要实时威胁检测：考虑 Socket.dev 的付费方案
Rust/Java 项目：Bumblebee 暂不覆盖这两个生态

总结

Bumblebee 的核心价值可以用一句话概括：在供应链攻击爆发的第一个小时内，你能在 30 秒内知道自己有没有中招。

它不是万能的——654 条记录不可能覆盖所有威胁，不支持 Windows 限制了使用范围，没有实时更新意味着存在空窗期。但它的三个设计原则（只读、零依赖、不执行包管理器）让它成为目前最安全的安全扫描器——一个本身不会成为攻击面的安全工具。

MCP 配置扫描是最有前瞻性的部分。在 AI Agent 大规模铺开的 2026 年，MCP 配置文件正在成为新的 .env 文件——包含敏感路径和权限，但缺乏审计手段。Bumblebee 首创了这个检查维度。

安装只需一行命令，扫描只需 30 秒，不产生任何副作用。对于任何使用 AI 编码助手的开发者来说，没有理由不把它加到工具箱里。