SBOM 漏洞扫描器
上传锁定文件或 SBOM，对照已知漏洞检查每一个固定版本 — 本地解析，对照 OSV 数据库匹配。
锁定文件是构建实际安装版本的精确清单 — 而每一个固定版本，都是一次押注：押注自你固定它以来，还没有人发现其中的漏洞。本扫描器读取这份清单（package-lock.json、requirements.txt、go.mod，或 CycloneDX / SPDX 格式的 SBOM），只把名称与版本发送给公开的 OSV.dev 漏洞数据库，报告哪些软件包存在已知漏洞、严重程度如何、哪个版本修复了每个漏洞，以及其中是否有 CVE 列入 CISA 已知被利用漏洞清单。配套指南你的锁定文件是否藏着漏洞？解释了扫描结果能证明什么、不能证明什么。如果扫描标记了某个 CVE，批量 CVE 分流台可以把它放进利用背景中去看。
最后更新:
你的锁定文件或 SBOM
支持：package-lock.json、requirements.txt、go.mod、CycloneDX JSON、SPDX JSON。文件大小上限 5 MB。
格式会根据文件名和内容自动识别；你也可以在下方自行选择。
🔒 锁定文件在浏览器内解析，永不上传。只有软件包名称和版本会发送给 OSV.dev；只有 CVE 编号会发送给本站的检查器，用于查询 KEV 标志。
扫描结果
尚未扫描。请在上方上传或粘贴锁定文件或 SBOM，然后点击“扫描漏洞”。
未发现已知漏洞
扫描的版本均未在 OSV 数据库中匹配到漏洞。这意味着还没有人报告过这些精确版本存在漏洞 — 并不保证代码就是安全的。未报告的漏洞、恶意软件包和仿冒包是这项检查看不到的；文章中解释了这条边界。
你的锁定文件永不离开本页
解析完全在浏览器内进行：你上传的文件 — 或粘贴的文本 — 都在本地读取，绝不上传到任何地方。只有提取出的软件包名称和版本会被发送出去，发给公开的 OSV.dev 漏洞数据库（无需账号、无需密钥），由它对照已知漏洞进行匹配。匹配结果中的 CVE 编号随后会发送给本站自己的检查器，用于查询 CISA KEV。除此之外没有任何内容离开本页：没有文件内容，没有路径，没有项目名称。
扫描上限
每次最多扫描 500 个软件包 — 超出的部分会列为未扫描。最多获取 200 条漏洞详情。结果来自 OSV 数据库，针对文件中记录的精确版本；数据库从未见过的软件包版本不会返回匹配，这与“安全无虞”不是一回事。
如实说明的局限
“未发现漏洞”是指在 OSV 数据库中，这些精确版本没有记录在案的漏洞。这并不意味着代码安全：尚未有人报告的漏洞、恶意软件包、仿冒名称和被投毒的发布版本，在版本匹配检查面前都是隐形的。
匹配是精确到版本的。如果你的文件固定的是版本范围而非精确版本，它会被跳过并如实列出 — 扫描器不会猜测你实际安装的是哪个版本。同样，扫描器无法映射其生态系统的软件包也会列为已跳过，绝不会悄悄丢弃。
KEV 标志来自对本站自有检查器的一次查询（CISA KEV 数据，每日刷新）。如果该查询失败或被限流，扫描仍会完成 — KEV 列只会显示“unknown”，而不会阻塞你的结果。
为什么固定版本就是攻击面
锁定文件之所以存在，是因为“最新版”不是一个版本号。它记录构建实际安装的精确依赖树，让每台机器、每次部署都得到相同的代码。这种确定性也正是锁定文件可以被扫描的原因：漏洞数据库以精确的软件包和版本为键，固定版本一次查询即可判定，而浮动范围则做不到。因此扫描结果的好坏取决于文件本身 — 提交锁定文件、保持更新，扫描器才能如实告诉你，你交付的是什么。
这项检查本身是有意收窄的。OSV.dev 汇总了 GitHub 安全公告、NVD 和各语言生态的漏洞记录，并对照你的版本进行匹配。它做不到的是评判代码：一个没有任何已知 CVE 的软件包，仍可能是恶意的、已被放弃的，或是你本想安装的那个包的仿冒品。版本匹配是一道快速而廉价的首层过滤 — 它能抓住你忘了升级的那个 lodash — 而不是一次安全审计。
为什么 KEV 标志比高 CVSS 分数更重要
CVSS 分数衡量的是漏洞一旦被利用会有多严重。CISA 已知被利用漏洞（KEV）目录衡量的则是另一件事：它是否正在野外被实际利用。一个中等严重程度、但列入 KEV 清单的 CVE，值得本周就打补丁；一个严重程度为危急、但还没有人武器化的 CVE，往往可以等到下一次计划升级。这就是为什么本扫描器把 KEV 的行单独打上标记，也是为什么结果按最严重程度优先排序 — 但最先要处理的是带 KEV 标记的那一个。
修复版本本身也有风险。漏洞的修复通常是一个小版本或补丁版本，但“已在 4.17.21 中修复”也可能意味着会破坏构建的行为变更，而且有些漏洞根本还没有修复版本 — 扫描器会如实说明，而不会凭空编一个。先修 KEV 项目，再修已有公开修复版本的危急项，其余的排进计划；固定新版本、提交锁定文件、重新扫描。同样的循环也属于 CI，在每次拉取请求时运行，而不是一个季度跑一次。
此 SBOM 中的许可证
这里列出的许可证仅来自 SBOM 自身携带的许可证字段。锁定文件（package-lock.json、requirements.txt、go.mod）不携带许可证数据，因此不会显示任何内容 — 本页不会逐个软件包去查询许可证，因为没有哪个公开数据库能可靠地提供这些信息。
锁定文件与 SBOM 术语，一一说清
Lockfile. 记录构建安装的每一个软件包精确版本的文件 — npm 的 package-lock.json、Python 用 == 固定的 requirements.txt、Go 的 go.mod/go.sum — 让安装可以复现。
SBOM. 软件物料清单（Software Bill of Materials）：一份软件中所有组件的机器可读清单，通常采用 CycloneDX 或 SPDX 格式。它是把锁定文件推广到整个供应链。
OSV.dev. Google 的公开漏洞数据库，汇总 GitHub、NVD 和各语言生态的安全公告，可按精确的软件包名称、生态系统和版本查询。
GHSA. GitHub 安全公告编号（GHSA-xxxx-xxxx-xxxx）。OSV 中大多数 npm、PyPI 和 Go 漏洞都有一个，通常还伴随一个 CVE 编号。
CVE. 通用漏洞披露（Common Vulnerabilities and Exposures）：共享的编号体系（CVE-YYYY-NNNNN），让每个数据库、扫描器和厂商都能谈论同一个漏洞。
CVSS. 通用漏洞评分系统（Common Vulnerability Scoring System）：0–10 分，衡量漏洞一旦被利用会有多严重。9.0 及以上为 CRITICAL，7.0 及以上为 HIGH，4.0 及以上为 MEDIUM，4.0 以下为 LOW。
KEV. CISA 已知被利用漏洞（Known Exploited Vulnerabilities）目录：已确认在野外被利用的漏洞，每个都有修复截止日期。KEV 标志意味着“立即打补丁”，无论 CVSS 怎么说。
Fixed version. 漏洞不再存在的第一个软件包版本，取自安全公告中受影响范围的事件记录。有些漏洞目前还没有发布修复版本。
Purl. 软件包 URL（pkg:npm/[email protected]）：用生态系统和版本命名软件包的标准方式。SBOM 携带 purl，扫描器据此知道组件属于哪个生态系统。
常见问题
我的锁定文件会离开浏览器吗？
不会。文件在本地解析，永不上传。只有提取出的软件包名称和版本会发送给公开漏洞数据库 OSV.dev，只有匹配结果中的 CVE 编号会发送给本站自己的检查器，用于查询 KEV。文件内容、路径和项目名称永不离开本页。
为什么某个软件包被列为“已跳过”？
有三个原因：该行不是精确固定（像 ~= 或 >= 这样的范围、-r 引用、replace 指令），生态系统无法映射到 OSV.dev 支持的生态，或者扫描触及了 500 个软件包的上限。被跳过的条目总会连同原因一起列出 — 没有任何内容会被悄悄丢弃。
“未发现漏洞” — 我就安全了吗？
不一定。这只意味着在 OSV 数据库中，这些精确版本没有报告在案的漏洞。未报告的漏洞、恶意或仿冒软件包、被投毒的发布版本，都不会出现在任何漏洞数据库中。请把扫描当作首层过滤，而不是安全合格证。
应该先修什么？
先处理带 KEV 标记的 — 这些漏洞正在被利用，CISA 会为每个设定截止日期。然后是已有公开修复版本的 CRITICAL 和 HIGH 行，从应用程序实际导入的软件包开始。可以用本站的批量 CVE 分流台，了解每个 CVE 背后的利用背景。
某个漏洞没有修复版本，怎么办？
先检查是否存在安全公告尚未记录的更新版本 — 安全公告往往滞后于发布。如果确实没有修复办法，可以选择移除该依赖、替换它，或者缓解易受攻击的代码路径（例如不再把不受信任的输入传给受影响的函数），并关注安全公告的更新。做过任何改动后重新扫描。