文章总结： 这篇文章介绍了墨菲SCA平台在企业中的落地实践，包括建立安全基线和动态策略、实现自动化扫描和工单创建、确保组件识别准确率等关键环节。作者分享了如何通过API集成实现SCA与DevOps流程的融合，以及如何处理例外情况。文章提供了具体的技术实现细节，对类似企业的SCA实施具有参考价值。 综合评分： 89 文章分类： 安全建设,应用安全,漏洞分析,安全运营,安全工具

墨菲SCA落地实践

原创

楼兰2333

楼兰学习网络安全

2025年12月19日 20:35 北京

一、背景

① 2024年，我们做了一次存量治理，针对当时全量的组件，人工研判出30+个必修组件，如fastjson、log4j-core，构建引入则整改。

这份清单我称之为我们SCA的安全基线。

② 2025年，由于旧的SCA平台技术落后，我们通过调研、测评最终引入了墨菲SCA。

③ 我们公司只有我一个应用安全，现在规划、设计、开发都是我，运营提效对我来说至关重要。

二、目标

① 支持线上分支全量扫描、研发自助扫描、DevOps流水线自动触发扫描

② 支持自动创建漏洞工单

③ 支持自动复查自动关闭工单

④ 兼容安全基线的同时，可以及时关注到新的安全风险

三、安全标准

需要先介绍一下目前我们SCA的运营标准，方便大家理解：

3.1 漏洞判定标准

策略1：安全基线，命中公司SCA必修组件的安全基线时，即使是构建引入也认为需要整改

策略2：动态策略，同时满足如下条件时认为是“漏洞”，需要人工二次判定：

• 存在RCE漏洞
• POC已公开
• 代码中引入了漏洞函数
• 存在NVD评级是严重级别或者高危级别的漏洞

3.2 漏洞处置标准

流水线扫描结果的处理规则：

① 告警通知：

识别到存在待整改的组件时，通过 IM 机器人通知研发

• 命中安全基线 → 标记为 “必需修复”
• 命中动态策略 → 标记为 “推荐修复”

② 生产环境额外处理：

• 命中安全基线 → 自动生成安全工单
• 命中动态策略 → 由工程师二次研判后再处理

四、业务流程

AppSec平台是我们自研的平台，其中一个定位是接收所有漏洞渠道反馈过来的漏洞，安全人员在上面做判定，对于需要整改的漏洞聚合成安全工单，发给工单平台。

五、部分落地细节

目标中的里面提到的事项，已经全部落地，下面对部分细节进行分享，其他方面感兴趣的细节欢迎与我交流。

5.1 创建扫描任务

这个很简单，直接调用墨菲SCA的API即可：

创建GitLab扫描任务（POST /platform3/v31/detect/gitlab）

因为我们有海外业务，有两个代码仓库、两个Maven私服，所以额外加了根据Git地址选择对应配置的逻辑。

• team_config_id：对应代码仓库的配置信息
• maven_settings_id：对应Maven私服的配置信息
• project_name：是扫描任务的名称，也是项目的名称，墨菲SCA会把相同名称的任务聚合到同一个项目
• projects_name：是项目组的名称

5.2 区分业务场景

根据 Git 地址和触发源生成标准化的扫描任务名称

格式：{场景}_{代码仓库}_{project_id}_{project_name}，示例：国内_流水线构建测试阶段_23_crmapi

这是我们整个SDL流程共用的一个机制，包括SAST扫描；目前预定义了下面几种类型

 classSdlScene(Enum):
    # 触发扫描动作的场景类型
    SEC="安全发起"
    DEV="研发发起"
    BUILD="流水线构建阶段"
    DEPLOY="流水线部署阶段"
    BUILDTEST="流水线构建测试阶段"
    DEPLOYTEST="流水线部署测试阶段"
    BUILDPROD="流水线构建生产阶段"
    DEPLOYPROD="流水线部署生产阶段"
    DISTRIBUTION="软件分发"

classSdlRepo(Enum):
    # 代码仓库类型
    CN="国内"
     SG="国际化"

在收到扫描完成的回调时，先解析扫描任务的名称，再按照场景选择不同的处置动作。

5.3 同时校验安全基线跟动态策略

墨菲SCA平台有一个自定义组件策略的功能，目前我们的必修组件清单是配置在了这个地方

在回调数据中，可以通过comp_info_list[].detection_strategy_is_mark这个字段判断命中了自定义组件策略的打标签动作。

至于动态策略的判定，也都可以在回调数据中找到：

• comp_info_list[].is_poc：是否有POC
• comp_info_list[].is_rce：是否存在RCE漏洞
• comp_info_list[].is_triggers：是否调用漏洞函数
• comp_info_list[].critical_num：NVD评级是严重级别的漏洞数
• comp_info_list[].high_num：NVD评级是高危级别的漏洞数

5.4 动态策略命中的这部分如何运营

基线中的必修组件都是我人工判定过的确有风险的，并且经过了我们24年存量治理，是大家认可的标准；但是动态策略命中的这部分，需要重新二次判定。

以com.h2database:h2这个组件为例，用来链接数据库，当jdbc的url可以控制，那么存在命令执行漏洞；满足我的动态检测策略，但是这个值通常是写死的，所以我将这个组件做了加白处理。

当判定风险较高时，我会将他加入到动态策略的黑名单，后续同时命中动态策略、动态策略黑名单的组件，可以跳过人工研判，自动创建工单。

5.5 构建安全工单

安全工单的用户群体主要是业务研发，业务研发主要关注：什么项目、有什么问题、怎么改。

在SCA的工单中，引入路径这个信息很重要，因为一个代码工程可能包含很多个模块，会增加研发排查的时间。

至于详情链接，最好不需要额外登录，或者接入统一认证，节约研发时间。

在墨菲SCA发过来的回调数据基础上，再结合下面两个墨菲SCA的API可以拿到永久有效的分享链接、引用路径：

• 创建安全问题分享链接（GET /platform3/v31/security/{security_id}/share-report）
• 获取组件引用路径(POST /platform3/v31/project/history/{subtask_id}/component-path)

5.6 确保组件识别的准确率是100%

自动告警、自动创建工单的前提是组件的识别准确率是100%。

墨菲SCA会优先尝试通过构建来获取组件清单，这种方式拿到的组件清单是100%准确率，所以我们的自动化流程只针对构建成功的这部分任务，失败的部分记录下来，让厂商逐个解决他们。

我统计了一下历史日志，目前的构建失败率大概在5%以内，是一个可以接受的值。

在墨菲的回调数据中，有一个subtask_info.scan_warnings字段，为空说明一切正常；目前的自动化流程中，收到回调数据后，我会先去识别这个值，不为空时，阻断后续流程，记录日志并发出告警提醒。

5.7 所有的例外管理

| 名单 | 实体 | 用途 | 存放的位置 | | — | — | — | — | | 安全基线黑名单 | 组件+版本范围 | 命中则自动创建工单 | 墨菲SCA平台 | | 安全基线白名单 | Git地址+组件+版本 | 命中则跳过安全基线的检测 | 应用安全平台 | | 动态策略黑名单 | 组件名 | 同时命中动态策略+黑名单，自动创建工单 | 应用安全平台 | | 动态策略白名单 | 组件名 | 命中则跳过动态策略的检测 | 应用安全平台 |

安全基线白名单必要性：我们有个项目二开了fastjson 1.2.63版本，升级会有兼容性问题，QA的回归成本很大，因此用了缓解方案来修复，这时我就需要将这个组件加入到白名单了。墨菲SCA平台不支持单个项目的白名单，我将它做到了我们自研的应用安全平台。

六、26年的规划

在三方组件安全这一块（不含三方软件）要做到事情不太多，会尝试在DevOps平台、研发协作平台、代码仓库、IDE等位置更前置的识别问题、提醒研发。

指的一提的是墨菲SCA的扫描速度很快，扫描周期绝大部分在30~60秒之间，为后续的安全左移提供无限可能。

我做了一个知识星球，用来记录我对企业安全努力的痕迹，欢迎大家加入！

查看原文：《墨菲SCA落地实践》