供应链安全扫描器

功能概述

供应链安全扫描器是一款专业的软件供应链安全检测工具。针对近年来频发的开源供应链攻击（如Log4j、SolarWinds、node-ipc投毒等），提供全方位的依赖安全检测、许可证合规审查、投毒风险识别和SBOM生成能力。

痛点与解决方案

交互式使用引导

你需要做什么？
│
├─ 扫描项目依赖漏洞
│  ├─ 我有完整lock文件 → 标准扫描（推荐，依赖树最完整）
│  ├─ 我只有package.json/requirements.txt → 快速扫描（仅直接依赖+部分传递依赖）
│  └─ 依赖超过500个 → 深度扫描（分级策略，直接依赖优先深度检测）
│
├─ 检查许可证合规性
│  ├─ 担心GPL/AGPL传染性 → 许可证合规检测 + 兼容性分析
│  └─ 需要生成合规报告 → 许可证合规报告（高/中/低风险分级）
│
├─ 排查投毒风险
│  ├─ 怀疑引入了仿冒包 → 投毒检测（重点关注拼写混淆typosquatting）
│  └─ 依赖来源不明/小众包 → 投毒检测（异常发布模式+可疑代码特征）
│
├─ 生成SBOM（软件物料清单）
│  ├─ 等保2.0合规要求 → CycloneDX格式（OWASP标准）
│  └─ ISO标准/国际要求 → SPDX格式
│
└─ 应急响应（0day漏洞爆发，如Log4j）
   └─ 提供受影响组件名 → 快速全量扫描，定位所有受影响项目并输出紧急建议

快速演示（输入 → 输出）

你说：

> 帮我扫描这个 package.json 的依赖安全：{"dependencies":{"axios":"1.3.4","lodash":"4.17.20","express":"4.17.1","minimist":"1.2.5"}}

你会得到（节选）：

# 供应链安全扫描报告
扫描对象：package.json（快速扫描，4 个直接依赖）

## 漏洞扫描结果
| 依赖 | 版本 | 漏洞 | 严重度(CVSS) | 建议 |
|---|---|---|---|---|
| lodash | 4.17.20 | CVE-2021-23337（原型污染） | 高(7.4) | 升级 ≥4.17.21 |
| minimist | 1.2.5 | CVE-2021-44906（原型污染） | 中(5.6) | 升级 ≥1.2.6 |
| axios | 1.3.4 | 无已知漏洞 | — | 保持 |
| express | 4.17.1 | 依赖链存在中危项 | 中 | 建议升级 4.18+ |

## 许可证合规
- lodash：MIT ✅ | axios：MIT ✅ | express：MIT ✅ | minimist：MIT ✅

## 投毒风险
- 未发现拼写混淆（typosquatting）或异常发布模式 ✅

## 修复建议（按优先级）
1. lodash 升级到 ≥4.17.21（存在公开 EXP，优先修复）
2. minimist 升级到 ≥1.2.6
3. express 升级到 4.18+ 以覆盖依赖链风险

> 提示：提供 package-lock.json 等 lock 文件可获得更准确的传递依赖扫描；本报告为演示样例，实际输出以扫描结果为准。

核心能力

📦 主流包管理器全覆盖

• 前端/Node.js：npm (package.json/package-lock.json)、yarn、pnpm
• Python：pip (requirements.txt)、Pipenv、Poetry
• Java：Maven (pom.xml)、Gradle
• Go：go modules (go.mod/go.sum)
• Rust：Cargo (Cargo.toml/Cargo.lock)
• Ruby：RubyGems (Gemfile/Gemfile.lock)
• PHP：Composer (composer.json/composer.lock)
• .NET：NuGet

🔴 多源漏洞数据库

• NVD：美国国家漏洞数据库
• OSV：Google开源漏洞数据库
• CVE Details：CVE详情库
• GHSA：GitHub安全公告
• CNVD：国家信息安全漏洞共享平台
• CNNVD：国家信息安全漏洞库

⚖️ 许可证合规检测

• 支持80+种开源许可证识别
• 传染性许可证（GPL/AGPL/LGPL）风险预警
• 商业软件合规风险评估
• 许可证兼容性分析
• 生成合规性报告

☠️ 投毒攻击检测

• 包名拼写混淆（typosquatting）检测
• 异常版本发布模式识别
• 可疑代码特征检测（加密/混淆/可疑网络请求）
• 维护者异常变更检测
• 下载量突增异常检测

📋 SBOM自动生成

• 支持 CycloneDX 格式（OWASP标准）
• 支持 SPDX 格式（ISO标准）
• 包含组件名称、版本、许可证、依赖关系
• 支持导出JSON/XML/CSV等多种格式
• 满足等保2.0供应链安全要求

检测维度

使用场景

场景1：项目上线前供应链审计

对整个项目的依赖树进行全面安全扫描，生成风险评估报告。

场景2：CI/CD流水线集成

作为构建流水线的安全门禁，发现高危漏洞自动阻断发布。

场景3：新依赖引入评估

在引入新的开源依赖前，快速评估其安全性和合规性。

场景4：合规审计

生成SBOM和合规报告，满足等保2.0、数据安全法等法规要求。

场景5：应急响应

当爆发新的0day漏洞（如Log4j）时，快速扫描受影响的项目。

使用方法

1. 提供依赖文件（package.json/requirements.txt/pom.xml等）
2. 说明项目类型和主要技术栈（可选）
3. 选择检测深度（快速扫描/标准扫描/深度扫描）
4. 自动执行供应链安全检测
5. 获取完整检测报告和SBOM文件

独立模式（降级使用）

当网络受限或漏洞数据库无法实时对接时，本工具支持降级为"独立模式"运行，确保基本检测能力不中断。

独立模式能力

• 内置离线漏洞库：覆盖近2年高频CVE漏洞，可离线匹配已知漏洞
• 许可证静态识别：基于包名和许可证文件进行本地识别，不依赖在线数据库
• 投毒特征检测：基于内置规则库检测常见拼写混淆和可疑代码特征
• SBOM生成：完全离线生成CycloneDX/SPDX格式SBOM

独立模式限制

• 漏洞库可能滞后于最新披露的CVE，建议联网后补充扫描
• 无法获取实时下载量、维护活跃度等动态指标
• 投毒检测能力较在线模式有所降低（离线库规则有限）

如何触发独立模式

• 当检测到网络不可用时自动切换，报告中标注"⚠️ 当前为离线模式，漏洞库截止日期：YYYY-MM-DD"
• 用户也可主动指定"离线扫描"以加快检测速度

模式切换建议

输出结构

📋 供应链安全扫描报告
├── 项目名称：xxx
├── 扫描时间：2026-07-19 12:00:00
├── 扫描范围：生产依赖 / 开发依赖 / 全部
├── 依赖总数：XXX个（直接X个，传递X个）
├── 漏洞统计：严重X 高危X 中危X 低危X
├── 许可证风险：X个高风险，X个中风险
└── 整体风险等级：🔴严重 / 🟠高危 / 🟡中危 / 🟢低危

🔴 漏洞详情（按CVSS评分排序）
├── [严重 9.8] CVE-2026-xxxx
│   ├── 组件：package-name@1.2.3
│   ├── 影响范围：>=1.0.0 <1.2.4
│   ├── 漏洞描述：...
│   ├── CVSS评分：9.8
│   ├── 修复版本：1.2.4
│   ├── 引入路径：项目 → A → B → package-name
│   └── 参考链接：...
├── [高危 7.5] ...
└── ...

⚖️ 许可证合规报告
├── 高风险（传染性强/商业不友好）：...
├── 中风险（需注意特定条件）：...
├── 低风险（宽松许可）：...
└── 未知许可证：...

☠️ 投毒风险预警
├── 疑似拼写混淆：...
├── 异常发布模式：...
└── 可疑代码特征：...

📦 SBOM摘要
├── 总组件数：XXX
├── 直接依赖：XX个
├── 传递依赖：XXX个
├── SBOM格式：CycloneDX 1.5 JSON
└── 导出文件：sbom.json

技术标准

• 遵循 OWASP Software Supply Chain Security Guide
• 支持 CycloneDX 和 SPDX 两大SBOM标准
• 对接 NVD/OSV/GHSA/CNVD 多源漏洞数据库
• 参考 NIST SSDF (Secure Software Development Framework)
• 满足 等保2.0 供应链安全相关要求

FAQ常见问题解答

Q1：供应链安全扫描的准确率有多高？会不会漏报？
A：本工具为AI辅助的供应链安全参考工具，不是经过专业认证的SCA（软件成分分析）产品。已知漏洞检测基于公开漏洞数据库的版本号匹配，主流生态（npm/pip/Maven/Go）覆盖较好，但无法保证检出全部漏洞。投毒攻击检测基于规则启发式判断，投毒手法不断演变，存在漏报和误报可能。许可证合规检测对常见主流许可证识别较准确，小众或多许可证项目可能需要人工复核。传递依赖分析的准确度取决于你提供的依赖文件完整性——提供完整lock文件时结果更可靠。本工具输出仅供安全评估参考，不构成专业安全结论，重要决策请结合专业安全团队与权威数据库交叉验证。

Q2：支持哪些包管理器和语言生态？
A：支持8大主流包管理器：npm/yarn/pnpm（Node.js）、pip/Pipenv/Poetry（Python）、Maven/Gradle（Java）、go modules（Go）、Cargo（Rust）、RubyGems（Ruby）、Composer（PHP）、NuGet（.NET）。其中npm、pip、Maven、Go Modules这四个生态的检测覆盖最全面（漏洞数据库最丰富）。对于C/C++的Conan、vcpkg等包管理器支持有限。

Q3：一次能扫描多少依赖？依赖文件很大怎么办？
A：建议单次扫描依赖数量控制在500个以内（含传递依赖），可以获得最佳检测深度和速度。对于超大型项目（依赖超过500个），会自动按优先级扫描：直接依赖优先深度检测，高风险传递依赖重点检测，低风险传递依赖快速扫描。扫描报告中会标注"已全量扫描"还是"抽样扫描"。

Q4：跟npm audit、pip-audit、Snyk这些工具有什么区别？
A：主要区别在于：① 多生态统一——一个工具支持多种包管理器，不需要每个生态装一个工具；② 检测维度更全——不仅查漏洞，还查许可证合规、投毒风险、废弃状态、依赖健康度；③ SBOM生成——自动生成标准格式的软件物料清单；④ 中文友好——输出中文报告，更适合国内团队。不足是：不像专业SCA工具那样有完整的CI/CD集成和持续监控能力，更适合快速检测和评估场景。

Q5：能检测依赖投毒吗？比如typosquatting那种？
A：可以检测。投毒检测是本工具的核心能力之一，覆盖三类投毒风险：① 拼写混淆（typosquatting）——检测与知名包名相似的可疑包名；② 异常发布模式——识别突然的版本激增、维护者变更、下载量异常等；③ 可疑代码特征——检测包中是否包含加密、混淆、可疑网络请求等恶意代码特征。但需要注意：投毒手法不断演变，无法保证100%检出，建议作为安全参考。

Q6：生成的SBOM符合标准吗？能用来做合规审计吗？
A：SBOM生成支持两大国际标准格式：CycloneDX（OWASP标准）和SPDX（ISO标准），格式规范。可以用于：内部供应链管理、等保2.0供应链安全要求的支撑材料、供应商安全评估的辅助资料。但需要注意：如果是用于正式的合规审计或第三方认证，建议使用经过认证的专业SBOM工具，本工具生成的SBOM可作为参考和补充材料。

Q7：适用于什么场景？不适用于什么场景？
A：✅ 适用场景：新项目依赖引入前评估、项目上线前供应链安全检查、应急响应时快速排查受影响项目、生成SBOM用于内部管理、开源许可证合规自查、定期安全巡检。
❌ 不适用场景：替代专业SCA工具做持续监控（需要集成CI/CD的专业工具）、实时漏洞预警（需要订阅漏洞情报服务）、对检测精度要求极高的金融/医疗等强合规场景（建议用商业SCA工具）、闭源组件的漏洞检测（只检测开源依赖）。

Q8：漏洞的严重等级是怎么划分的？以什么为准？
A：漏洞严重等级主要基于CVSS评分划分：严重（Critical）CVSS 9.0-10.0、高危（High）CVSS 7.0-8.9、中危（Medium）CVSS 4.0-6.9、低危（Low）CVSS 0.1-3.9。评分以NVD数据库的CVSS v3.x评分为准，如果NVD没有评分，则参考GHSA或OSV的评级。同时会结合实际利用难度和影响范围做微调。需要注意：CVSS评分是技术严重性，业务影响还需要结合你的具体场景判断。

Q9：检测出来的漏洞都需要修复吗？怎么判断优先级？
A：不是所有漏洞都需要立即修复。建议按以下优先级判断：① 严重+高危且有公开EXP的——立即修复；② 严重+高危但没有成熟EXP的——计划修复（1-2周内）；③ 中危且影响核心功能的——排期修复；④ 中低危且影响有限的——记录跟踪，版本迭代时顺便修。判断时还要考虑：这个依赖在你的项目中是怎么用的、是否走得到漏洞触发路径、有没有其他缓解措施。不要为了修漏洞而修漏洞，要结合实际风险评估。

反模式与使用禁忌

❌ 反模式1：扫描出漏洞就慌，全部升级到最新版
错误做法：一看到有漏洞就把所有依赖升到最新版，不管兼容性和Breaking Change。
原因：盲目升级依赖可能引入新的bug、兼容性问题甚至新的安全漏洞。重大版本升级往往有API变更，可能导致项目跑不起来。
正确做法：按风险等级和实际影响排序修复。高危漏洞优先修，能升级到兼容的安全小版本就升级；不能的话找替代方案或加缓解措施。升级前看Changelog，测试环境验证后再上生产。

❌ 反模式2：只看直接依赖，不管传递依赖
错误做法：只检查package.json或requirements.txt里直接写的依赖，不关心传递依赖（依赖的依赖）。
原因：80%的供应链漏洞出在传递依赖中。Log4j、node-ipc这些大事件，很多项目根本没直接依赖，是通过传递依赖引入的。只看直接依赖等于漏了大部分风险。
正确做法：一定要扫描完整依赖树（包括所有传递依赖）。使用lock文件（package-lock.json、yarn.lock、go.sum等）可以获得完整准确的依赖列表。重点关注有漏洞的传递依赖是怎么引入的，能不能通过升级直接依赖来间接修复。

❌ 反模式3：上线前扫一次就完事，之后再也不扫
错误做法：项目上线前做一次供应链扫描，然后就不管了。
原因：新漏洞每天都在被发现。今天扫描没问题，不代表明天没问题。Log4j漏洞爆发时，多少"安全运行了好几年"的项目突然中招。
正确做法：建立定期扫描机制——至少每月一次全量扫描，高危漏洞爆发时立即专项排查。重要项目建议使用专业SCA工具接入CI/CD，实现持续监控。安全是持续的，不是一劳永逸的。

❌ 反模式4：用供应链扫描代替代码安全审计
错误做法："我依赖扫描过了，没有漏洞，项目就安全了。"
原因：供应链安全只是应用安全的一部分。依赖没有漏洞，不代表你自己写的代码没有漏洞。SQL注入、XSS、越权这些漏洞跟依赖没关系，是代码本身的问题。
正确做法：供应链扫描+代码安全审计+渗透测试多层防御配合。供应链安全管"别人的代码"，代码审计管"自己的代码"，渗透测试管"整体安全性"。三管齐下才是完整的安全体系。

❌ 反模式5：看到GPL许可证就觉得不能用，一律排除
错误做法：把所有GPL/LGPL许可证的依赖都标记为"高风险"，直接禁止使用。
原因：GPL许可证不是洪水猛兽。是否传染取决于使用方式——动态链接vs静态链接、分发方式、是否修改源码等。很多情况下是可以合规使用的。一味排斥会错失大量优质开源软件。
正确做法：根据具体许可证类型和使用场景做合规评估。建议由法务或合规人员给出明确的使用规则，不同许可证对应不同的使用要求。不是所有"传染性"许可证都不能用，关键是合规使用。

❌ 反模式6：只看漏洞数量，不看实际影响
错误做法："这个项目有50个漏洞，那个只有10个，所以那个更安全。"
原因：漏洞数量不等于实际风险。50个低危信息泄露漏洞，可能不如一个高危RCE漏洞危险。而且很多漏洞在你的使用场景下根本触发不了——比如你用的是这个库的A功能，漏洞在B功能里，那这个漏洞对你的实际风险就很低。
正确做法：关注漏洞的严重等级（严重/高危优先）、是否有EXP、是否影响你实际使用的功能。按风险排序修复，而不是按数量。能确定触发不了的漏洞可以标记为"不影响"，记录原因即可。

❌ 反模式7：依赖版本越新越安全
错误做法："我所有依赖都是最新版，所以最安全。"
原因：新版本可能修复了旧漏洞，但也可能引入新漏洞。而且新版本的代码没有经过足够的时间和社区验证，反而可能有未知风险。历史上多次出现过"修复安全漏洞的版本自己又有新漏洞"的情况。
正确做法：平衡安全和稳定。生产环境优先使用经过广泛验证的稳定版本（通常是发布了至少1-2个月的版本）。安全补丁优先升级，功能大版本谨慎升级。关注漏洞情报，有针对你在用版本的高危漏洞时再考虑升级。

输入输出示例

示例1：扫描一个Node.js项目的package.json

【输入】
> 项目类型：Node.js / npm
> 扫描深度：标准扫描
>
> json > { > "name": "my-web-app", > "version": "1.0.0", > "dependencies": { > "express": "^4.17.1", > "lodash": "4.17.15", > "jsonwebtoken": "8.5.1", > "axios": "^0.21.0", > "mongoose": "^5.10.0" > }, > "devDependencies": { > "jest": "^26.6.0", > "eslint": "^7.12.0" > } > } >

【输出】

📋 供应链安全扫描报告
├── 项目名称：my-web-app
├── 扫描时间：2026-07-19 10:30:00
├── 扫描范围：生产依赖 + 开发依赖
├── 依赖总数：156个（直接7个，传递149个）
├── 漏洞统计：严重1 高危3 中危5 低危8
├── 许可证风险：2个高风险，5个中风险
└── 整体风险等级：🔴严重

🔴 漏洞详情（按CVSS评分排序）
├── [严重 9.8] CVE-2021-23337
│   ├── 组件：lodash@4.17.15
│   ├── 影响范围：< 4.17.21
│   ├── 漏洞描述：lodash的command命令注入漏洞，
│   │   攻击者可通过特制输入执行任意命令
│   ├── CVSS评分：9.8
│   ├── 修复版本：4.17.21
│   ├── 引入路径：项目 → lodash (直接依赖)
│   └── 参考链接：https://nvd.nist.gov/vuln/detail/CVE-2021-23337
├── [高危 8.8] CVE-2020-28500
│   ├── 组件：lodash@4.17.15
│   ├── 影响范围：< 4.17.20
│   ├── 漏洞描述：正则表达式拒绝服务（ReDoS）漏洞
│   ├── CVSS评分：8.8
│   ├── 修复版本：4.17.20
│   ├── 引入路径：项目 → lodash (直接依赖)
│   └── 参考链接：...
├── [高危 7.5] CVE-2020-15228
│   ├── 组件：@actions/core (传递依赖)
│   ├── 影响范围：< 1.2.6
│   ├── 漏洞描述：GitHub Actions核心库的路径遍历漏洞
│   ├── CVSS评分：7.5
│   ├── 修复版本：1.2.6
│   ├── 引入路径：项目 → jest@26.6.0 → @actions/core
│   └── 参考链接：...
├── [高危 7.2] CVE-2022-23529
│   ├── 组件：jsonwebtoken@8.5.1
│   ├── 影响范围：< 9.0.0
│   ├── 漏洞描述：jwt.verify()方法的认证绕过漏洞
│   ├── CVSS评分：7.2
│   ├── 修复版本：9.0.0
│   ├── 引入路径：项目 → jsonwebtoken (直接依赖)
│   └── 参考链接：...
├── [中危 6.5] ...
└── ...

⚖️ 许可证合规报告
├── 高风险（传染性强/商业不友好）：
│   ├── jest@26.6.0 — MIT ✅ （误分类，实际是MIT）
│   └── （无GPL/AGPL类强传染性许可证）
├── 中风险（需注意特定条件）：
│   ├── mongoose@5.10.0 — MIT
│   ├── axios@0.21.0 — MIT
│   ├── express@4.17.1 — MIT
│   ├── jsonwebtoken@8.5.1 — MIT
│   └── 等共5个 — 均为MIT许可证，兼容性好
├── 低风险（宽松许可）：
│   └── 多数依赖为MIT/Apache/BSD等宽松许可证
└── 未知许可证：0个

☠️ 投毒风险预警
├── 疑似拼写混淆：无
├── 异常发布模式：
│   └── lodash@4.17.15 — 版本较旧，建议升级到最新安全版本
└── 可疑代码特征：无

📦 SBOM摘要
├── 总组件数：156
├── 直接依赖：7个
├── 传递依赖：149个
├── SBOM格式：CycloneDX 1.5 JSON
└── 导出文件：sbom-my-web-app.json

💡 修复建议
├── 【立即修复】
│   1. lodash升级到4.17.21（修复严重+高危各1个）
│   2. jsonwebtoken升级到9.0.0（修复高危1个）
│   3. axios升级到0.21.4或最新版（修复中危2个）
├── 【计划修复】
│   1. express升级到4.18.2+（修复低危2个）
│   2. mongoose升级到5.13.15+（修复中危1个）
└── 【建议关注】
    - 开发依赖中的高危漏洞（如jest的传递依赖）
      如果仅开发环境使用、生产不打包，风险较低

示例2：扫描一个Python项目的requirements.txt（无高危漏洞）

【输入】
> 项目类型：Python / pip
>
> txt > flask==2.0.1 > requests==2.26.0 > sqlalchemy==1.4.23 > pydantic==1.8.2 > uvicorn==0.15.0 > python-jose[cryptography]==3.3.0 > passlib[bcrypt]==1.7.4 >

【输出】

📋 供应链安全扫描报告
├── 项目名称：Python API Project
├── 扫描时间：2026-07-19 11:00:00
├── 扫描范围：生产依赖
├── 依赖总数：42个（直接7个，传递35个）
├── 漏洞统计：严重0 高危0 中危2 低危3
├── 许可证风险：0个高风险，1个中风险
└── 整体风险等级：🟡中危

🔴 漏洞详情（按CVSS评分排序）
├── [中危 6.1] CVE-2023-30776
│   ├── 组件：flask@2.0.1
│   ├── 影响范围：>= 2.0.0, < 2.1.0
│   ├── 漏洞描述：Flask调试模式下的PIN码绕过漏洞
│   │   （仅影响debug=True的开发环境）
│   ├── CVSS评分：6.1
│   ├── 修复版本：2.1.0
│   ├── 引入路径：项目 → flask (直接依赖)
│   └── 参考链接：...
├── [中危 5.9] CVE-2022-40897
│   ├── 组件：setuptools (传递依赖)
│   ├── 影响范围：< 65.5.1
│   ├── 漏洞描述：package-index-check功能的
│   │   正则表达式拒绝服务漏洞
│   ├── CVSS评分：5.9
│   ├── 修复版本：65.5.1
│   ├── 引入路径：项目 → 环境自带
│   └── 参考链接：...
├── [低危 3.7] ...
├── [低危 2.6] ...
└── [低危 2.1] ...

⚖️ 许可证合规报告
├── 高风险：无
├── 中风险（需注意特定条件）：
│   └── cryptography — Apache-2.0 OR BSD-3-Clause
│       （双许可证，二选一即可，合规性良好）
├── 低风险（宽松许可）：
│   Flask(MIT)、requests(Apache-2.0)、
│   SQLAlchemy(MIT)、pydantic(MIT)等
└── 未知许可证：0个

☠️ 投毒风险预警
├── 疑似拼写混淆：无
├── 异常发布模式：无
└── 可疑代码特征：无

📦 SBOM摘要
├── 总组件数：42
├── 直接依赖：7个
├── 传递依赖：35个
├── SBOM格式：CycloneDX 1.5 JSON
└── 导出文件：sbom-python-api.json

💡 修复建议
├── 【建议修复】
│   1. Flask升级到2.1.0+（如果生产环境开启了debug模式则必须修复）
│   2. setuptools升级到最新版（环境级依赖，按需修复）
├── 【可以接受的风险】
│   - 低危漏洞：影响有限，可在下次版本迭代时一并升级
│   - 开发环境漏洞：不影响生产环境，可降低优先级
└── 【整体评价】
    依赖安全性较好，无严重和高危漏洞。
    建议持续关注，定期扫描。

示例3：扫描一个有投毒风险的可疑依赖

【输入】
> 项目类型：Node.js / npm
> 重点关注：投毒检测
>
> json > { > "name": "test-project", > "dependencies": { > "loadash": "1.0.0", > "axios": "^0.27.0", > "vue": "^3.2.0" > } > } >

【输出】

📋 供应链安全扫描报告
├── 项目名称：test-project
├── 扫描时间：2026-07-19 14:00:00
├── 扫描范围：生产依赖
├── 依赖总数：23个（直接3个，传递20个）
├── 漏洞统计：严重2 高危1 中危3 低危2
├── 许可证风险：0个高风险，1个中风险
└── 整体风险等级：🔴严重

🔴 漏洞详情（按CVSS评分排序）
├── [严重 9.8] MAL-2023-12456
│   ├── 组件：loadash@1.0.0
│   ├── 影响范围：所有版本
│   ├── 漏洞描述：该包为typosquatting投毒包，
│   │   仿冒知名库lodash。安装时会执行恶意脚本，
│   │   窃取环境变量中的敏感信息（如密钥、token）
│   │   并发送到远程服务器。
│   ├── CVSS评分：9.8
│   ├── 修复版本：无（恶意包，应立即移除）
│   ├── 引入路径：项目 → loadash (直接依赖)
│   └── 参考链接：...
├── [严重 9.1] CVE-2023-XXXXX
│   ├── 组件：loadash@1.0.0
│   ├── 影响范围：所有版本
│   ├── 漏洞描述：恶意代码执行，安装后自动运行
│   ├── CVSS评分：9.1
│   └── 修复版本：无
├── [高危 7.5] CVE-2021-3749
│   ├── 组件：axios@0.27.0 (传递依赖)
│   ├── 漏洞描述：正则表达式拒绝服务漏洞
│   ├── CVSS评分：7.5
│   ├── 修复版本：0.27.2
│   └── 参考链接：...
└── [中危 ...] ...

⚖️ 许可证合规报告
├── 高风险：
│   └── loadash@1.0.0 — 未知许可证 ⚠️
│       （恶意包通常没有正规许可证）
├── 中风险：axios@0.27.0 — MIT
├── 低风险：vue@3.2.0 — MIT
└── 未知许可证：1个（loadash）

☠️ 投毒风险预警
├── 疑似拼写混淆：
│   └── ⚠️ loadash@1.0.0 — 高度疑似typosquatting
│       知名库为 lodash（字母o在前），此包名仅一字之差，
│       下载量远低于正常水平，维护者身份不明
├── 异常发布模式：
│   └── loadash@1.0.0 — 仅有一个版本，发布后无更新
│       典型的"一次性发布"投毒包特征
└── 可疑代码特征：
    └── loadash@1.0.0 — postinstall脚本中包含可疑
        网络请求和环境变量读取行为

📦 SBOM摘要
├── 总组件数：23
├── 直接依赖：3个
└── ⚠️ 含恶意组件：loadash@1.0.0

🚨 紧急建议
【立即执行】
1. 立即从package.json中移除loadash依赖
2. 检查是否已安装该包，如已安装：
   - 检查环境变量、密钥是否泄露
   - 检查是否有可疑网络请求日志
   - 如有泄露，立即轮换所有密钥和凭证
3. 将正确的依赖名改为 lodash（注意拼写）
4. 检查项目中其他依赖是否也有类似拼写问题

【根因分析与预防】
1. 此为典型的typosquatting攻击（拼写混淆）
2. 引入依赖前务必核对包名拼写和官方来源
3. 建议使用npm企业版或私有源，加强依赖管控
4. 定期进行供应链安全扫描，及时发现风险

最佳实践指南

1. 提供完整的lock文件，而不只是依赖声明
package.json、requirements.txt、go.mod这些文件只包含直接依赖，要获得完整的依赖树（包括传递依赖），需要提供lock文件（package-lock.json、yarn.lock、Pipfile.lock、go.sum等）。lock文件锁定了所有依赖的精确版本，扫描结果更准确。

2. 区分生产依赖和开发依赖，分别评估风险
生产依赖（dependencies）和开发依赖（devDependencies）的风险等级不同。开发依赖中的漏洞，如果不打进生产包、运行时不加载，风险就低很多。不要把所有漏洞混为一谈，按依赖类型分别评估，重点关注生产依赖。

3. 高危漏洞优先修，先看能不能利用再说
不是所有漏洞都需要修。修之前先想三件事：① 漏洞在你用的功能里吗？② 能被攻击者触发吗？③ 有没有其他缓解措施？如果答案都是否定的，可以标记为"不影响"，不用急着修。但严重和高危漏洞，即使觉得用不到，也建议升级——因为你可能低估了攻击面。

4. 建立依赖引入审查机制
不要随便往项目里加依赖。加新依赖前问几个问题：这个包靠谱吗（下载量、维护活跃度、star数）？许可证合规吗？有没有已知高危漏洞？有没有更轻量的替代方案？一时图省事加个依赖，后面可能要花十倍功夫去填坑。

5. 定期扫描，高危漏洞爆发时立即排查
建立定期扫描机制：至少每月一次全量扫描。遇到Log4j级别的重大漏洞爆发时，立即专项排查所有项目。不要等出了事才想起来扫，那时候可能已经被攻击了。

6. 最小依赖原则，能不用的就不用
依赖越多，攻击面越大。每个依赖都可能引入新的漏洞。养成"最小依赖"的习惯——能用标准库就不用第三方库，能用轻量库就不用重型库，能自己写个简单函数就不用为了一个函数引入整个库。依赖少了，需要维护和监控的安全风险自然就少了。

7. SBOM要管理起来，别生成完就扔
SBOM不是合规装饰品，是有用的管理工具。每次发版都生成一份SBOM存档，漏洞爆发时可以快速查"我们用了这个库吗？哪个版本？"。没有SBOM，排查起来就得一个项目一个项目翻依赖文件，效率差十倍。

8. 关注投毒风险，尤其是小众依赖
知名大项目（React、Vue、Spring Boot等）被投毒的概率较低，因为关注度高、审核严。反而是那些小众的、下载量低的包，更容易出现投毒。引入小众依赖前多留个心眼：包名对不对？维护者是谁？有没有奇怪的脚本？投毒防不胜防，警惕性高一点总没错。

边界与限制说明

✅ 能做什么（核心能力）

1. 8大包管理器支持：覆盖npm/pip/Maven/Go Modules/Cargo/RubyGems/Composer/NuGet主流生态
2. 多源漏洞数据库参考：对接NVD/OSV/GHSA/CNVD等公开漏洞库信息，辅助识别已知风险
3. 许可证合规检测：识别常见开源许可证，评估传染性和合规风险
4. 投毒风险识别：检测拼写混淆、异常发布模式、可疑代码特征等供应链投毒迹象
5. SBOM自动生成：支持CycloneDX和SPDX两大标准格式，满足合规和管理需求

❌ 不能做什么（明确局限性）

1. 不能100%检测所有投毒攻击：投毒手法不断演变，新型投毒可能绕过检测。0day投毒攻击检测是行业难题
2. 不能替代专业SCA工具做持续监控：本工具适合快速扫描和评估，不具备CI/CD集成、实时漏洞告警、策略管理等企业级功能
3. 不能检测闭源组件和二进制文件：只能检测开源包管理器管理的依赖，无法检测闭源SDK、二进制文件、硬件固件等
4. 不能保证漏洞信息的绝对实时性：漏洞数据来源于公开数据库，可能存在几天到几周的延迟，不适合作为唯一的漏洞情报源
5. 不能评估漏洞的实际业务影响：只能给出技术严重性评分，具体业务影响需要结合项目实际使用场景判断
6. 不支持完整项目级别的深度扫描：需要手动提供依赖文件，无法像专业工具那样自动扫描整个代码仓库

准确性与局限性说明

• 本工具为AI辅助安全参考工具，未经过专业SCA产品级别的准确率认证
• 已知漏洞检测基于公开漏洞数据库的版本号匹配，主流开源生态覆盖较好，但漏洞数据库本身存在更新延迟与覆盖不全的问题
• 许可证识别对MIT/Apache/GPL等主流许可证较准确，小众或多许可证组合项目可能需人工复核
• 投毒检测为启发式规则判断，新型投毒手法可能漏报；拼写混淆类风险提示相对可靠
• 传递依赖分析准确度取决于依赖文件完整性，提供完整lock文件时结果更可靠
• 本工具定位为安全教育与快速筛查辅助，不替代专业SCA工具与安全团队的正式评估

已知盲点与薄弱场景

• 新型0day投毒攻击：刚出现的、未被公开报道的投毒包难以检测
• 混淆/加密的恶意代码：经过高度混淆或加密的恶意代码，静态分析难以识别
• 复杂依赖树中的漏洞传递：某些构建系统的依赖解析逻辑复杂，可能导致传递依赖分析不完全准确
• 小众语言/包管理器：非常见生态的漏洞数据库覆盖不足
• 漏洞实际可利用性判断：只能给出技术严重性，无法准确判断在特定项目中是否真的可被利用
• 私有源/内部包：只能检测公开源的包，私有源的包无法查询漏洞信息

适用版本/模型范围

• 适用于主流编程语言生态的开源依赖安全检测
• 对npm、Maven、PyPI、Go Modules等主流生态覆盖最好
• 漏洞数据库定期更新，但可能滞后于最新披露的漏洞
• 本工具运行于扣子(Coze)平台，漏洞数据来源于公开漏洞数据库

异常与错误处理

空输入/过短输入处理

• 当未提供任何依赖文件时，返回提示："⚠️ 未检测到依赖文件内容，请提供package.json、requirements.txt、pom.xml等依赖文件内容。"
• 当依赖文件内容过短（少于5个依赖）时，正常扫描但提示："⚠️ 依赖数量较少（X个），可能未提供完整依赖列表。建议提供lock文件以获得完整依赖树。"

输入过长处理

• 当依赖文件过大或依赖数量超过500个时，自动采用分级扫描策略：直接依赖全量深度扫描，传递依赖按风险优先级扫描
• 扫描报告中明确标注："⚠️ 依赖数量较多（共XXX个），已采用分级扫描策略。直接依赖全量检测，传递依赖按风险优先级扫描。如需全量深度扫描，建议按模块分批扫描。"
• 超长输入的扫描结果置信度会适当下调，重点关注高风险项

格式不规范的输入处理

• 对于无法识别格式的依赖文件，尝试自动识别包管理器类型，识别失败则提示："⚠️ 无法自动识别依赖文件格式，请标注项目类型（如Node.js/npm、Python/pip、Java/Maven等）。"
• 对于格式有错误的依赖文件（如JSON语法错误），尽可能容错解析，同时提示："⚠️ 依赖文件格式存在部分错误，已尝试容错解析。建议提供格式正确的依赖文件以获得更准确的结果。"
• 对于明显不是依赖文件的文本（如纯自然语言、代码片段等），提示："⚠️ 输入内容似乎不是依赖文件，请提供package.json、requirements.txt、pom.xml等依赖配置文件内容。"

结果不确定时的提示方式

• 当某个漏洞的信息不完整或存在争议时，标注"（信息待确认）"并给出进一步验证建议
• 当许可证类型不明确时，标注为"未知许可证"，建议到官方仓库核实
• 当投毒风险为"可疑"但证据不足时，明确说明判断依据和不确定性，如："该包下载量偏低、维护活跃度不足，有一定投毒风险但证据不充分。建议谨慎评估后再使用，或选择更知名的替代方案。"

多次检测结果不一致时的建议

• 同一依赖文件多次扫描结果不一致时，以最新一次扫描结果为准（漏洞数据库在持续更新）
• 如果结果差异较大，建议：
  1. 确认每次扫描提供的文件内容是否一致
  2. 到漏洞数据库官网（如NVD）人工核实关键漏洞信息
  3. 对于关键项目，使用多种扫描工具交叉验证
• 漏洞信息是动态变化的，每次扫描结果可能因数据库更新而不同，这是正常现象

关于作者

由知白守黑1024打造，专注于软件供应链安全领域。致力于通过AI技术提升供应链安全检测效率，帮助企业和开发者构建安全可信的软件供应链。