墨菲安全

墨菲安全面向软件供应链中的开源组件、漏洞和许可证风险，可从代码目录、二进制、依赖配置、代码仓库、制品库或现有组件清单接入。选型时应先用依赖已知的项目校准 SBOM，再判断告警是否真实进入业务调用链，最后才把规则放进 CI/CD 或组件下载路径。

检测入口由你手里现有的交付物决定

官方 CLI 文档区分 scan、binscan 和 dfscan：scan 从项目多类文件识别组件，binscan 面向二进制文件，dfscan 读取包管理和依赖配置。CLI 的源码检测文档列出 Java、JavaScript、Go、Python 等语言；已有 SBOM 可走组件清单接入，Nexus 则用于存量仓库制品检测。

先用已知项目校准 SBOM

1. 选择一个依赖清晰、包含直接和传递依赖的代表性项目。
2. 把扫描结果与锁定文件、构建产物和人工清单逐项对照。
3. 记录组件别名、版本误识别、嵌套 Jar 或复制源码等偏差。
4. 确认报告能导出组件、漏洞、依赖路径和修复版本，并分配责任人。

组件清单接入支持按自定义策略给命中组件打标签或设为缺陷组件。策略上线前要确认命名与版本能稳定匹配，否则同一组件的别名会造成漏报或重复告警。许可证结论还需结合修改、链接、分发和服务方式由合规人员复核。

可达性用于排序，不能替代漏洞修复判断

墨菲文档将“可触发漏洞”定义为先通过 SBOM 与漏洞库识别候选，再用静态代码分析判断缺陷函数是否被实际调用、参数是否可控。这个结果比只按组件版本更接近业务上下文，适合确定优先级；但动态加载、反射、配置分支和运行环境仍可能超出静态分析范围。

• 同时看漏洞严重度、可达性、资产重要性、暴露面和是否已有利用。
• “不可触发”需要保存分析依据，不等于永久接受风险。
• 升级后重新生成 SBOM，确认旧组件没有被其他制品继续引用。
• 高风险结果先在测试环境验证补丁和回滚，不直接修改生产依赖。

GitLab、Nexus 与流水线先审计再阻断

GitLab 接入可做全量检测，也可通过 WebHook 在代码更新时触发增量检测；Nexus 可按项目或仓库范围检查存量制品。正式接入前，用只读或最小权限账号限定仓库范围，令牌放入受控凭据系统，不写入仓库或普通构建日志。

第一阶段只生成报告和工单，观察误报、扫描时长与修复周期；稳定后再对明确的高风险策略启用合并或构建门禁，并准备例外审批和快速回退。这样 SCA 才从一份组件清单变成持续的供应链治理，而不是新的告警堆积。