depquiet：按可达性对 NPM/pip/Dependabot 告警做分类处置

穿透漏洞告警噪音，呈现真正的信号。

depquiet 会对你的 npm audit / pip-audit / trivy / grype / Dependabot / Snyk 告警做分类处置，告诉你哪些 CVE 才真正要紧——只需几秒，而不是几小时。它还可以直接用 OSV.dev API 扫描 lockfile——无需外部扫描器。

录像中的每一行都是真实的命令输出（制作方式见此处）。

同一次运行的文本版（可复现）：

$ npm audit --json | depquiet --stdin depquiet scan — npm（14 个包） ✅ 已过滤：13 条告警（45%） ├─ 13 条不可达——未被导入，无论直接还是通过父级 └─ 8 条仅 devDependency——永远不会进入生产环境 （一条告警可能匹配多个原因） ⚠️ 需复核：3 条告警 GHSA-pxg6-pf52-xh8x cookie 低危 无 EPSS ... 🔴 需要处理：13 条告警 • GHSA-9wv6-86v2-598j path-to-regexp 修复：将 express 更新到 4.22.3 经由 express → app.js path-to-regexp 输出回溯正则表达式 ... 总计：29 条告警——13 条可处理 | 3 条需复核 | 13 条已过滤

path-to-regexp 从未被应用直接导入，但 Express 在每次请求时都会调用它，因此 depquiet 保留了它。那 13 条被过滤的告警位于仅由构建工具引入的包中（eslint、nodemon、webpack-dev-middleware），或者应用声明了但从未导入的包中。

pip install depquiet pip-audit # pip-audit 是可选的；没有它，Python # 项目将通过 OSV.dev 扫描 cd your-project depquiet # 运行 npm audit / pip-audit，或通过 OSV.dev 扫描 lockfile npm audit --json | depquiet --stdin # 或对任意扫描器的输出做分类处置 depquiet explain GHSA-9wv6-86v2-598j # 为什么这条告警会得到这个判定？

适用于 npm、yarn、Python（uv、Poetry、pip-tools、Pipfile）、Rust、Ruby、PHP、.NET、Dart、Go 和 Maven 项目。在 CI 中，可使用 GitHub Action。

依赖扫描器会报告所有匹配版本范围的公告，无论你的应用是否能够触及易受攻击的代码：

结果是告警疲劳：团队要么花数小时分拣噪音，要么开始忽略告警，包括真实的告警。

depquiet 应用四个确定性过滤器，将信号与噪音分离：

在真实项目上的实测结果见基准测试。

depquiet 宁可放行一个误报，也不愿忽略一个真实漏洞：

depquiet 接受来自任何漏洞扫描器的输出——原生支持或通过 SARIF：

SARIF 解析器可处理来自 CodeQL、Semgrep、Trivy SARIF、Grype SARIF、Snyk SARIF、Checkmarx、Fortify 以及任何其他输出 SARIF v2.1.0 的工具的输出。CVE、包名、严重程度（CVSS 或基于级别）以及修复版本会自动从标准 SARIF 字段和常见扫描器特定属性中提取。

当没有扫描器输出被管道传入，且未检测到原生包管理器时，depquiet 会回退到通过 OSV.dev 进行 lockfile 扫描——OSV.dev 是 Google 的开放、免费漏洞数据库。只需在任何带 lockfile 的项目中运行 depquiet：

同一项目中的多个 lockfile 会被合并并去重。OSV.dev 批量 API 每次请求最多处理 1000 个包，因此即使是大型 monorepo 也只需一两次 HTTP 调用。使用 --offline 可完全跳过 OSV.dev 查询。

depquiet 可生成美国第 14028 号行政命令所要求的两种主要 SBOM 标准：

CycloneDX 1.5（OWASP 标准）

depquiet --sbom sbom.json # CycloneDX JSON depquiet --sbom sbom.xml # CycloneDX XML（自动检测） depquiet --sbom out.cdx --sbom-format xml

SPDX 2.3（ISO/IEC 5962:2021）

depquiet --sbom sbom.spdx.json # SPDX JSON（自动检测） depquiet --sbom out.spdx --sbom-format spdx

两种格式均包含完整的组件清单（带 Package URL（purl））、已知 CVE 的漏洞引用、depquiet 分类判定结果以及工具创建者元数据。CycloneDX 还会将判定结果映射到分析状态；SPDX 使用带 NVD 链接的 SECURITY 外部引用。

SBOM 输出可与其他所有标志配合使用——将 --sbom 与 --sarif 组合，可在一次运行中同时生成两者。

depquiet 可接收 CycloneDX 和 SPDX SBOM 作为输入，从而能够对来自供应商、容器镜像仓库或构建系统的第三方 SBOM 进行分类处置——无需原始 lockfile：

显式文件输入

depquiet --from-sbom vendor-sbom.cdx.json # CycloneDX 1.4/1.5 JSON depquiet --from-sbom vendor-sbom.spdx.json # SPDX 2.3 JSON

通过 stdin 管道传入（自动检测）

cat container-sbom.json | depquiet --stdin

两种运行模式：

所有标准 depquiet 标志均适用于 SBOM 输入：--epss-threshold、--kev、--sbom（重新导出）、--sarif、--html 等。

导入检测因语言而异：

Python——通过 ast.parse() 进行完整 AST 解析。从语法树中提取 import、from … import 和 import() 调用。不受注释、文档字符串和字符串字面量导致的误报影响。仅对解析失败的文件（Python 2、编码问题）回退到正则——保守策略：将无法解析的文件视为可能导入了该包。

JavaScript / TypeScript——注释剥离流水线 + 对实际导入语法做模式匹配。处理所有主要导入风格：

Go——在剥离注释后解析 import 语句。处理：

Rust——在剥离注释后解析 import 语句。处理：

Java / Kotlin——在剥离注释后解析 import 语句。处理：

C#——在剥离注释后解析 using 指令。处理：

PHP——在剥离注释后解析 use 语句。处理：

Ruby——在剥离注释后解析 require 语句。处理：

Swift——在剥离注释后解析 import 语句。处理：

Dart / Flutter——在剥离注释后解析 import 语句。处理：

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）