# 主机扫描CVE组件版本漏洞
# 案例
客户新版本上线前对产品服务器主机进行了开源组件版本漏洞扫描，发现部分漏洞需要安全处理。
# 案例说明
此类扫描主要涉及开源组件（产品接入了很多开源组件）版本漏洞，以及开源中间件（如MySQL数据库、Nginx、Redis、Tomcat等）。
较新版本开源组件jar版本漏洞扫描属于客户常见安全检测行为，通常安全团队会根据实际情况评估修复方法，如无法修复会进行无攻击风险的说明。如果是发版几年的产品，安全团队只维护高危漏洞，其余不存在攻击场景的不做修复。
总体原则：项目组先处理完已知、明确的问题，再将不明确的问题提交安全单支持。
# 处置方法
1、首先项目组进行报告的检查和分析：检查主机扫描文档是否齐全，至少需要包含：漏洞名称、当前版本、建议升级版本、文件具体应用路径，每一项都非常关键缺一不可，如缺失需要让客户补齐：
- 漏洞名称：能明确当前问题具体是什么组件引发，如果是Nginx、Redis等开源组件，由负责部署的运维直接按要求升级版本到安全基线即可
- 当前版本、建议升级版本：属于检测基线，理论需要将开源组件升级到基线要求之上，否则复测也不通过
- 应用路径：非常关键，这个决定了开源组件漏洞具体归属哪个产品，有些是V5、有些是Elasticsearch、有些是S1，有些是数科、文档通、融云，项目上需要根据路径来判断问题交给谁处理
2、项目先预处理：针对那些能处理的内容，项目组自行完成处理，不能处理再上报，方法包括并不仅限于：
2-1、MySQL、Nginx、Redis等开源组件谁部署谁处理，自行升级
2-2、操作系统OS本身漏洞谁维护谁处理
2-3、联系客开复查下，是否存在客开新增的开源组件，客开组件自行处理
2-4、一些备份文件、S1等辅助工具，可以在检查期间直接移除，即可扫描通过
2-5、使用公司协同CoMi - “安全智能客服” 智能体 搜索核对问题是否属于已知漏洞，是否有处置方案
2-6、结合 安全中心补丁通报 (opens new window) 寻找是否有契合的第三方安全补丁，针对问题进行处置
3、以上完成后，针对已处理问题进行标记，再检查剩余点，将剩余问题提交安全单由安全老师研判。
4、安全针对开源组件处理原则：能升级出包解决的会尽量出包解决，如不能出包解决的会判断当前漏洞在产品中是否使用/是否会被利用，如果不会利用会出具不被利用的说明，项目组以此做依据给客户陈述反馈。 如果漏洞会被利用，安全团队一定会处置（比如近几年闹的最凶的fastjson、xstream、log4j问题都及时处置）。
其它情况：如客户的版本过低，比如V7.x还在上报开源jar漏洞，除非明确高危问题，其余问题安全有权力拒绝：产品发版时没有相关漏洞，并且该漏洞在产品中不会被利用。如客户要处理，建议升级产品到最新稳定版本。
