供应链安全扫描器

先说清楚它解决什么问题

Log4j、SolarWinds、node-ipc 这一类攻击之后，出问题的往往不是你自己写的代码，而是你拉下来就用的开源包。实际排查时最常见的几个盲区：

• 只检查 package.json 里显式声明的依赖，传递依赖（依赖的依赖）完全没看——而多数供应链漏洞恰恰藏在那里；
• 引入了拼写相近的仿冒包（typosquatting）而不自知；
• 开源许可证里带了传染性条款（GPL/AGPL/LGPL），能不能用、怎么用没人评估过；
• 合规审计需要 SBOM，靠人工整理依赖清单耗时且容易漏；
• 扫出来一堆 CVE，没人告诉你该先修哪个、哪个其实触发不了。

它是怎么工作的

多生态统一入口：覆盖 npm/yarn/pnpm、pip/Pipenv/Poetry、Maven/Gradle、Go modules、Cargo、RubyGems、Composer、NuGet 八类包管理器的依赖声明与 lock 文件。

检测链路：

• 已知漏洞匹配：对接 NVD、OSV、GHSA、CNVD、CNNVD 等多源漏洞库，按 lock 文件锁定的精确版本号做匹配，宣称已知漏洞覆盖率 99%；
• 传递依赖分析：基于 package-lock.json、go.sum 这类 lock 文件还原完整依赖树，传递依赖覆盖率约 95%；
• 投毒风险检测：包名拼写混淆识别、异常版本发布模式、可疑代码特征（加密/混淆/可疑网络请求）、维护者异常变更、下载量突增；
• 许可证合规：识别 80+ 种许可证，对传染性条款做风险预警，支持兼容性分析；
• SBOM 生成：输出 CycloneDX（OWASP）或 SPDX（ISO）格式，可导出 JSON/XML/CSV，参考 NIST SSDF 与等保 2.0 相关要求。

修复排序：按 CVSS 评分分级（严重/高危/中危/低危），结合公开 EXP 可用性给出优先级建议，而不是简单按漏洞数量排序。

离线降级：网络不可用时自动切到独立模式，用内置近两年高频 CVE 离线库匹配、本地识别许可证、离线生成 SBOM，报告中会标注漏洞库截止日期。

适用边界与注意点

• 已知 CVE 匹配基于版本号，准确率高（95%–99%）；投毒检测只有 70%–85%，新型手法会漏报，应作为参考信号而不是结论；
• 不具备专业 SCA 工具的 CI/CD 集成、持续监控和策略管理能力，适合快速扫描与评估；
• 只检测开源包管理器管理的依赖，闭源 SDK、二进制文件、私有源内部包不在范围内；
• 漏洞数据来自公开库，可能存在几天到几周的滞后；
• 单次扫描建议控制在 500 个依赖以内（含传递依赖），超量会触发分级扫描策略；
• 它不管你自己代码里的 SQL 注入、XSS 这类问题，供应链扫描与代码审计是两层防御，不能互相替代。