背景
以 Xstream、Jackson、Fasjson 等为代表的 Jar 组件高危漏洞层出不穷，安全组每年 N 次推动业务线进行第三方 Jar 组件升级，每次升级动辄涉及成百上千个应用服务，给双方都带来了沉重的负担。为了降低安全组在 Jar 组件升级期间的工作量，同时尽量给业务线减负，Qunar 安全组在 Jar 组件自动化风险监测和升级上进行了大量实践，并总结形成了一套相对完善的解决方案。本主主要聊一下 Qunar 安全组在 Jar 组件自动化风险监测和升级方面的探索和实践。
流程介绍
Jar 组件风险监测和升级本质是由风险情报驱动的一个工作流，主要包括外部安全通告监控、Jar 组件资产收集、受影响资产分析、通知业务线升级等流程。在之前一段时期，Jar 组件漏洞升级依靠安全运营人员人工的方式来串联每个流程，这样效率低下，甚至容易出错。随着 SOAR（安全编排自动化与响应）近年来的备受关注，Qunar 安全组也在 SOAR 项目上进行了建设，依托 SOAR 对事件的整合和安全服务串联能力，我们针对 Jar 组件风险监测和升级场景进行了合理编排，达到了自动化的效果，极大提升了安全运营效率。除此之外基础架构的同事，提供了 TCDEV 自动升级服务，为业务线升级操作提供了极大便利。事件流程如下图所示：
技术实现
本部分主要介绍 SOAR 串联的每部分安全工具、服务的技术实现。
1. 安全通告监控
安全运营人员第一时间获取漏洞通告，对漏洞的评估研判、迅速响应和有序推动至关重要。早在19年，安全组借助应届生项目，实现了“安全漏洞智能感知系统”。系统主要功能为：\
- CVE、CNVD 以及知名厂商漏洞风险告警抓取
- 漏洞信息去重整合
- 对存在 POC 的漏洞抓取 POC
- 漏洞信息模糊匹配关联 Jar 组件资产库（SecDB），IM 预警安全运营人员
该系统关键点在于会通过模糊匹配的方式关联 Jar 组件资产库，关联到资产后 IM 发送预警信息给安全运营人员，进行进一步的风险评估以及后续的 Jar 组件升级流程。系统流程图如下：
漏洞感知平台，以 Xstream 为例抓取效果图：
2. Jar资产收集
安全资产收集是安全运营的必备基础能力之一，Qunar 安全组历来都把资产收集做到了业内最好的水准。当前我们采用以 HIDS 为主要平台，通过在 Agent 端调度资产收集插件的方式，高效的对主机的资产进行定时、实时的采集。Agent 调度示意图：
- 查找 cataline.base 列表
items=$(ps aux | grep catalina.base | grep -v grep)
- 获取 catalina.home、catalina.base 等路径信息
catalina_home=$(echo "$item" | tr ' ' '\n' | grep catalina.home | cut -d= -f2 | sort | uniq)
catalina_base=$(echo "$item" | tr ' ' '\n' | grep catalina.base | cut -d= -f2 | sort | uniq)
- 根据 server.xml 获取 以及 信息
- 根据 appBase 或者 docBase 定位 WEB-INF/lib 路径
- 枚举 WEB-INF/lib 路径下 Jar 包，提取每个 Jar 包的 pom.properties 信息，这样就可以进行资产收集了，例如：
jar_version=$(echo "$pom_properties" | grep -m 1 -E '^version=' | awk -F'=' '{print $NF}' | tr -d '\n\r')
jar_groupid=$(echo "$pom_properties" | grep -m 1 -E '^groupId=' | awk -F'=' '{print $NF}' | tr -d '\n\r')
jar_artifactid=$(echo "$pom_properties" | grep -m 1 -E '^artifactId=' | awk -F'=' '{print $NF}' | tr -d '\n\r')
通过以上手段的就可以获取主机上存活 Java 项目依赖的 Jar 包信息，一旦爆发漏洞根据以上信息，关联应用以及 Owner 快速响应。以 Xstream 为例，收集的资产信息如下：
3. SOAR
SOAR 全称 Security Orchestration, Automation and Response，即安全编排自动化与响应，该技术主要聚焦于安全运营领域。Qunar 安全组基于 StackStorm 工作流引擎二次开发打造了 SOAR 项目，安全组件和剧本通过 python 和 yaml 实现。在 Jar 组件自动化风险监测和升级场景中流程如下图所示：
① 安全通告监控服务发出预警信息后，需要人工干预。安全运营人员会研判是否启动升级流程，如果是，则填写配置漏洞信息，启动升级流程；否则，忽略该告警信息
② 启动升级流程后，首先需要关联信息生成受影响资产清单 a) 资产列表生成：根据配置的版本信息进行逻辑过滤，生成受影响资产的列表，同时标记内外网，以执行不同的优先级策略b) 关联 Appcode：通过 Portal API 获取受影响主机对应的 Appcodec) 关联 Owner：通过 Portal API 获取受影响主机对应的 Ownerd) 关联技术 TL：通过 ISAPI 员工信息关联 Owner 的技术 TL（技术 TL 充当安全对接人的角色，执行自上而下的漏洞升级推动工作）
③ 接下来会将资产清单提供给 tcdev，tcdev 会接管可自动化升级的应用，剩余部分继续由安全负责通知业务线技术 TL 升级
Xstream 漏洞升级示例，配置漏洞信息，启动自动关联信息升级通知流程：
Xstream 安全通知示例，通过内部 IM 通知技术 TL 执行升级任务：
4. TCDEV自动升级服务
一般的公司，将风险事件通知负责人后整个事件流程就结束了，然后执行周期性的通知升级。但是在 Qunar 内部，基于 TCDEV 开发的自动升级服务，可以极大解放业务线的风险组件升级压力。TCDEV 自动升级服务可以帮助业务线自动进行 Jar 组件升级，当前 50% 的应用可以自动化升级， 30% 的应用可以通过 TCDEV 提供的一键升级服务进行一键升级（需业务线开发评估风险），另外 20% 应用执行安全组传统的升级策略。TCDEV 自动升级详情如下：
- 应用已经升级 tcdev 4.x，且已接入灭霸自动化测试的应用，tcdev 接管升级，届时会联系业务确认（应用占比 50%）* 应用已升级 tcdev 4.x，但自动化测试未覆盖的应用，可在 portal 上点击 “tcbom升级” 快速完成（应用占比30%）\* 尚未升级 tcdev 4.x 的应用，建议手动升级 tcdev 至 4.0.x （应用占比20%）总结
–
以上就是 Jar 组件自动化风险监测和升级实践中涉及的方方面面。整体流程还有优化提升的空间，比如在漏洞评估和 TCDEV 自动升级服务还需要人工介入等。另外，TCDEV 自动升级服务价值极大，由于资料较少，没有触及原理实现，希望基础架构的同学可以写一篇文章介绍一下。由于水平有限，文章多有纰漏不足，也恳请大家指正。
