不了解内部安全假设
团队知道组件能做什么，却不清楚解析、权限、数据和危险能力采用了哪些默认边界。
USE CASE 03
依赖进入产品前，先看清源码里带来的安全风险
版本可用、社区活跃，并不等于适合直接进入生产环境。引入前扫描源码，识别高风险模块和影响路径，再决定接入范围、隔离方式、修复要求或替代方案。
WHY THIS MATTERS
为什么这个场景容易漏掉代码风险？
开源组件一旦进入业务调用链，后续升级、替换和应急处置的成本都会上升。安全判断不应只依赖版本号和公开 CVE，而应发生在技术选型与正式集成之前。
只看 CVE 容易遗漏
公开漏洞只能覆盖已知问题，无法解释当前版本和具体使用方式中的代码风险。
接入后替换成本更高
组件进入架构、数据和业务调用链后才发现问题，会同时影响功能、进度和维护计划。
COMMON RISKS
更值得优先检查的风险
不安全的输入处理
解析、反序列化、路径和文件操作没有正确限制来自业务侧的数据。
默认开放危险能力
网络请求、命令执行、动态加载或插件机制在默认配置下可以被外部触达。
敏感数据与凭据处理
日志、缓存、配置或外部传输链路暴露业务数据、密钥和令牌。
默认配置与集成边界
调试接口、管理入口或宽松权限在生产部署和二次封装后形成新的攻击面。
WHEN TO SCAN
把检查放在三个关键节点
技术选型与 PoC 阶段
在投入正式集成前先扫描候选版本，识别需要重点评估的模块。
二次开发或封装后
结合实际调用方式重新检查组件与业务代码之间的输入、权限和数据边界。
进入生产依赖清单前
确认高风险问题、部署限制和后续升级责任已经有明确处理结论。
HOW IT WORKS
从代码到可处理结果
获取待引入的完整源码
提交实际准备使用的版本，而不只依据项目名称或公开漏洞列表。
定位风险区域与路径
识别危险能力、高风险模块，以及它们是否会被真实业务入口触达。
评估接入方案
结合部署权限、业务暴露面和修复能力，决定接入、隔离、修复或替代。
判断是否引入当前组件
限定版本、权限和调用范围
决定修复、隔离或选择替代方案
FAQ
开源组件引入前检查常见问题
有 CVE 扫描还需要做源码扫描吗？+
需要互补。CVE 识别已公开问题，源码扫描帮助发现当前版本和具体使用上下文中的风险。
扫描结果能直接决定不接入吗？+
结果是决策依据之一，还要结合业务重要性、部署边界、维护活跃度和可缓解措施判断。
只扫描依赖包本身够吗？+
对核心依赖，建议同时扫描实际引入版本和二次封装代码，避免遗漏集成方式带来的风险。
NEXT USE CASE