过去一年，AI 对企业安全的影响已经不是“未来趋势”了。它已经开始进入企业内部真实的研发、办公、运维、安全运营流程里。

这段时间，我们和不少企业安全负责人、安全团队、行业里的朋友交流下来，发现大家对 AI 的态度其实很一致：

一方面，大家都觉得 AI 肯定会改变企业安全。

但另一方面，很多人也会有疑问：

这些问题，单靠一篇文章、一次直播，都很难讲清楚。

所以我们准备在 5月底，继续在上海组织第二场线下闭门交流。

这次和上一次有点不一样，就是除了墨菲安全之外，也会有几家单位一起参与支持，包括  (ISC)² 上海分会、超聚变数字技术股份有限公司、上海霞安信息科技有限公司 等伙伴，议题也会更丰富一些。

但整体想法还是和第一期一样，不做大而空的大会，还是希望把真正关心 AI 和企业安全的朋友聚在一起，围绕具体问题，聊深一些。

本次闭门沙龙，初步考虑会围绕下面几个议题展开：

这是我们认为最需要先聊清楚的一个问题。

AI 时代下，企业安全面临的挑战不只是“多了几个新的风险点”，而是很多原有的安全治理逻辑正在被重新拉扯。

这部分核心会讲两大部分：

这部分不会只讲概念，会尽量结合真实的产品实践和落地场景，把问题讲实。

2. 议题2：前沿科技企业在AI时代的企业安全实践及思考

这一部分会回到企业内部真实发生的场景里，看看安全团队在面对 AI 应用、AI 工具、AI Agent 时，具体是怎么判断、怎么治理、怎么落地的。

我们也希望通过这个议题能一起探讨一个现实的问题：

当 AI 已经进入企业内部，安全团队到底应该从哪里开始做？

这些问题可能每家公司阶段不同，答案也不完全一样。但正因为如此，更值得大家放在一起交流。

3. 议题3：AI 时代企业安全的工作方式和组织变革

如果说前两个议题更多是在聊风险和实践，那这个议题想聊的是更底层的变化：AI 会不会从根本上改变企业安全团队的工作方式？

过去很多企业安全团队的定位，多少有点像“守门员”。

但 AI 普及之后，这种工作方式可能会被挑战。

因为业务和研发的变化速度太快了，如果安全团队仍然只是在后面做审核、做卡点、做补救，可能很难跟上节奏。

所以这里就会引出几个很值得讨论的问题：

这些问题现在可能都还没有标准答案。

但越是没有标准答案，越适合放到线下闭门交流里聊。因为每家企业所处阶段不同，安全团队的规模不同，业务复杂度不同，能给出的判断也会不一样。

我们希望这个议题不只是聊趋势，而是能把大家的实践和思考放到一起，看看大家现在已经遇到了什么问题，正在尝试什么方法，以及对未来 1–3 年的企业安全组织变化有什么判断。

4. 议题4：AI 时代的勒索攻防博弈

勒索攻击一直是企业安全里非常现实、也非常难绕开的话题。

而 AI 的出现，也在改变攻防两端的效率和方式。

攻击者可能会借助 AI 做更高效的信息收集、钓鱼内容生成、漏洞利用辅助，甚至提升横向移动和攻击链构造的效率。

防守方也需要重新思考，如何在更短时间内发现异常、判断风险、完成响应。

这部分会由本次协办方  (ISC)² 上海分会主席 结合他的实践进行分享。

5. 议题5：AI 智能体原生操作系统安全能力探索

随着 AI Agent 的发展，智能体不再只是一个“问答工具”，而是逐渐开始具备任务执行、工具调用、流程编排和环境交互能力。

这意味着，未来 AI Agent 所运行的基础环境、操作系统、安全边界、权限控制、执行过程，都可能成为新的安全关注点。

围绕这个方向，本次也会设置一个关于 AI 智能体原生操作系统安全能力探索 的分享议题。

这部分会由协办单位 超聚变数字技术股份有限公司 结合自身实践进行分享。

如果你最近正在关注下面这些问题，那这场沙龙可能会比较适合你：

关于详细的议题、活动安排、地点等信息后续会更新发布在公众号。

感兴趣的朋友可以先扫码报名：

1. 第一章：漏洞情报与投毒情报的核心属性

漏洞情报对应已知可利用缺陷，投毒情报对应被注入恶意逻辑或仿冒的恶意组件。

投毒情报有几个区别于漏洞情报的独特属性：

• 生命周期短：恶意包从发布到下架可能仅有数小时；

• 无 CVE 覆盖

• 爆发节奏快：比如蠕虫化投毒可在 24 小时内波及上万仓库；

• 依赖独立感知体系：传统 SCA / WAF / SOC 普遍盲区；

判断一份情报是否好用，可从四个属性评估：

2. 第二章：为什么需要高质量情报

本章系统剖析上述六类企业痛点，提出情报驱动的主动治理范式：不再只盯着内部资产"已知有什么漏洞"，而是持续接入外部情报感知生态动向，前置发现风险，在漏洞被大范围传播前、投毒包尚未被广泛使用前完成排查处置。

高质量情报对应三个核心价值词：

3. 第三章：八个典型应用场景

覆盖从组件引入到应急响应的完整链路：

场景	核心价值
攻防演练	先于攻击方掌握供应链暴露面；演练前收敛高危资产
监管排查与合规自查	将两高一弱排查从"周"级压缩到"小时"级；构建可审计证据链
组件选型与准入	在成本最低的窗口阻断高风险组件；从"凭感觉"到"凭数据"
日常漏洞管理	降噪去误报；重构修复优先级；破解存量漏洞"修不动"困境
漏洞与投毒事件应急响应	首次预警 + 详细分析 + 排查脚本 + 持续更新；大幅压缩实际响应时间
出海与标准合规	支撑合规 SBOM 输出；满足 R155、欧盟 CRA 等法规要求
AI 供应链漏洞与投毒治理	填补传统情报体系对 MCP / Skill / 模型的盲区
作为数据底座增强安全工具链	横向增强 SCA / WAF / EDR / SIEM；从"人消费"延伸到"系统消费"

每个场景给出「场景特征 → 情报需求 → 应用方式 → 落地要点」的完整指引。

4. 第四章：五个值得关注的趋势

5. 情报体系的纵深演进：影响范围从产品级到函数级、处置上下文从"描述"到"可执行脚本"、攻击行为画像从"是否恶意"到意图分类与技战术映射。

墨菲安全在 20 余家头部互联网及金融、运营商、央国企行业数十家头部企业中积累了多年情报服务实践，指南内容直接来自这些头部企业在真实场景中遇到的问题。

而头部企业对时效、准确性、影响范围精度的严苛要求，也在持续驱动情报能力的打磨与迭代。

扫描图片末尾二维码，下载《漏洞及投毒情报应用实践指南 2026 版》完整版。

指南覆盖八个典型应用场景，每个场景给出情报需求与落地要点。

如果你的团队正在处理告警降噪、投毒感知、应急响应提速等问题，可以直接对照相关场景章节。

欢迎获取完整版内容。这里既有监管治理视角，也有金融行业一线安全运营的实战经验，分享给想把情报真正用起来的安全团队。

01.

概述

02.

攻击者近期持续针对性投毒，前日SAP旗下组件受影响

03.

投毒代码分析

04.

IOC

05.

处置建议

《安全度量最佳实践2026版》以企业真实落地路径为主线，围绕七大章节，系统回答“为什么做、怎么设计、如何落地、怎样持续做好”几个核心问题。

1. 第一章：企业安全度量现状与核心挑战

第一章首先回答“为什么现在必须做安全度量”。

从管理汇报、横向比较、治理成效、责任传导等多个维度切入，梳理了当前企业常见的几类典型痛点：

• 管理层看不懂技术风险；

• 安全团队难证明治理成效；

• 业务部门不知道风险来自哪里，也看不到任务处理对整体安全水位的改善作用；

同时，还给出了从初级统计型指标，到成熟风险指数体系的成熟度分层，为企业判断自身所处阶段提供参考。

2. 第二章：需求价值调研与现状评估

第二章聚焦“建设之前先把问题问清楚”。

本章提出，企业在启动安全度量建设前，应同时从管理层、安全部门、业务负责人和现状数据四个维度开展调研。

• 管理层关注是否能支撑决策与预算；

• 安全团队关注是否能支撑运营提效；

• 业务负责人关注责任是否明确、动作是否可执行；

只有把这些需求与现有资产、风险、组织、工单等数据现状一起盘清，后续的指标设计和平台建设才不会脱离真实场景。

3. 第三章：安全度量指标体系设计

第三章是全文的方法核心。

本章以 ESSF 企业安全治理框架为基础，进一步解释了安全度量为什么不是“随便设几个分”，而是要建立在统一对象、统一威胁、统一口径之上。

围绕 CSI、SAI、SII 三类核心指标，系统说明了指标的设计原则、解释逻辑、下钻路径以及口径治理方法，强调指标必须做到可解释、可复算、可对齐。避免企业陷入“每个部门都有一套算法、谁也不信谁结果”的局面。

4. 第四章：安全度量平台方案设计

第四章把方法论落到平台建设层面。

本章主要从数据接入、数据治理、业务与资产关系建模、指标计算、驾驶舱展示、权限角色设计、任务闭环和运营协同等多个方面，系统梳理了安全度量平台的建设思路。

其核心不是做一张大屏，而是建设一套可持续运行的治理工作台：既能向上呈现风险指数和趋势变化，也能向下支撑责任映射、任务派发、效果回算和日常运营。

5. 第五章：内部立项与高层汇报策略

第五章回答“怎么把这件事推动起来”。

在很多企业里，安全度量不是一个天然就会被批准的项目，它既涉及平台建设，也涉及跨部门协同和管理机制调整。

因此，本章专门给出了立项汇报的逻辑框架，帮助安全团队从风险现状、价值收益、同行对标、实施路径和资源投入等维度组织高层汇报内容，把技术问题转换成管理层能够理解和决策的语言。

6. 第六章：灰度试点与指标调优

第六章强调，安全度量不能一上来就全量铺开，而应先通过试点验证模型是否成立、数据是否可信、协同是否顺畅。

本章将试点分为范围选择、目标设定、实施步骤和输出物四个部分，建议企业在有限范围内先验证数据接入、指标解释、责任映射、任务闭环和用户使用体验，再根据试点结果持续优化口径和策略，为后续推广打基础。

7. 第七章：全面推广与常态化运营

第七章进一步回答“如何让它不止停留在试点”。

本章提出，安全度量建设要从专项项目走向常态化运营，必须建立分阶段推广路径、指标异常分析机制、数据质量巡检机制、规则与权重评估机制，以及稳定的任务闭环运营方式。

只有当风险识别、任务推动、结果回算和经验沉淀形成机制，安全度量平台才能真正成为企业的治理基础设施，而不是一次性上线的展示系统。

《安全度量最佳实践2026版》的价值，不只是给企业提供一套指标定义，更重要的是提供一条能够落地的建设路径。

首先，它帮助企业建立统一的安全度量语言。安全团队、管理层和业务部门终于可以围绕同一组指标讨论同一件事情，而不是各说各话。

其次，它让安全工作具备可视化、可比较、可追踪的表达方式。过去只能看到漏洞数量，现在可以看到整体安全水位、部门间差异、趋势变化和治理短板；过去只能派任务，现在可以看到任务处理后是否真的带来了分数改善和风险下降。

再次，它把安全责任与治理动作连接起来。风险不再只是挂在安全团队名下，而是能够沿着组织、业务、资产和负责人的链路逐层下钻，形成更清晰的责任映射和更具体的改进方向。

更重要的是，它为安全建设提供了从“方法”到“平台”再到“运营”的完整闭环。企业不必再把安全度量理解为一组静态报表，而是可以把它建设成支撑管理决策、业务协同和持续改进的长期机制。

本次最佳实践并非停留在抽象概念层面，而是结合互联网、智能制造、金融等行业的真实建设经验，对安全度量的落地路径进行了系统归纳。

报告中所依托的 ESSF 企业安全治理框架，由墨菲安全联合多家头部甲方企业共同建设。

其意义不仅在于提出一套指标体系，更在于为企业提供一套行业可对齐、组织可复用、管理层可理解的方法基础。

对于正在推进安全治理平台建设、需要强化管理汇报能力、或希望把安全运营从“经验驱动”走向“数据驱动”的企业来说，这份最佳实践都具有较强的参考价值。

企业安全建设正在从“看见问题”走向“量化风险”，从“专项治理”走向“持续运营”。

安全度量的意义，也不只是多一个分数，而是帮助企业建立一套真正能够被看见、被理解、被执行、被复盘的治理机制。

《安全度量最佳实践2026版》希望回答的，不只是“如何做一个安全度量平台”，更是“如何让安全工作真正进入企业管理语言、业务语言和持续改进机制”。

面向未来，墨菲安全也将继续围绕安全治理量化、企业级治理平台建设与实践方法沉淀，持续推动更多可落地的行业经验转化为企业可执行、可复用的最佳实践。

扫描图片末尾二维码，下载《安全度量最佳实践2026版》完整版。

欢迎获取完整版内容。安全度量，让每一项安全工作的价值被看见，让每一个安全问题的处置更高效。

Axios在js开发中使用广泛，基于墨菲安全1亿+组件知识库排查分析，发现NPM仓库最新版本依赖axios的组件超过17万，各个组件历史版本直接依赖axios的数量超过21万，如需解析直接依赖可参考列表进行排查（请复制下方链接至浏览器打开）：

https://s.murphysec.com/package/依赖axios的NPM组件列表-墨菲安全.csv

Openclaw中由于内置集成了line、slack插件，插件中依赖了axios受到影响，受影响的插件依赖如：

用户在受影响时间段（2026-03-31 08:21:58后）下载安装的openclaw，就可能受到影响。

同时GitHub中有近500万开源代码引用了axios。

投毒版本的 axios 包在投毒版本的依赖中引入具有后门的 plain-crypto-js 包：

axios包的 package.json 文件

当用户安装受影响版本的 axios 包时会安装 plain-crypto-js 包，plain-crypto-js 组件在安装时会执行恶意的 setup.js 文件。

plain-crypto-js包的 package.json 文件

setup.js 文件是经过混淆的RAT投放器，目的是根据系统下载并执行不同的后门程序，实现远程控制和信息窃取。

setup.js 中的混淆恶意代码

反混淆后的核心代码：

2-1、macOS系统

• 写入 AppleScript → 静默执行

• 连接 C2：http://sfrclak.com:8000/6202033

• 下载 macOS RAT 二进制：/Library/Caches/com.apple.act.mond

2-2、Windows系统

• 查找 PowerShell 路径

• 复制为持久化程序：%PROGRAMDATA%\wt.exe

• 写入并执行 VBScript

• curl 下载 PowerShell RAT：%TEMP%\6202033.ps1

2-3、Linux 攻击链

• 直接执行 shell 命令

• 连接 C2 下载 Python RAT：/tmp/ld.py

• 后台运行

外联地址：

• sfrclak.com

• 142.11.206.73

axios组件使用量较大，建议通过以下方式排查：

1. 排查是否有针对sfrclak.com、142.11.206.73的外联请求

2. 排查是否存在如下版本依赖，重点排查2026-03-31开始构建的项目：

组件名	版本
axios	1.14.1
axios	0.30.4
plain-crypto-js	4.2.1

PART 01

PART 02

PART 03

我们认为，AI 时代给安全产品带来的最大机会，不是让扫描更快，而是彻底改变产品和用户之间的交付关系：从交付信息，变成交付结论和行动方案。

所以，我们选择用 AI 原生的方式重新打造 SCA 产品的工作形态。

不是在原有界面上叠加一个 AI 对话框，而是让 AI 深入到产品的每一个环节：风险研判、优先级排序、修复方案生成、兼容性分析、处置闭环，全部由 AI 驱动。

具体来说，SCA 4.0 带来三个核心升级：

1. 用 AI 重构治理体验，让非安全专业的人也能直接处置安全问题；

2. 用 AI 重构成本结构，让每一个安全问题的处置成本降到最低；

3. 将检测能力延伸到 AI 生态，覆盖 Skills 等新型供应链威胁；

；

在绝大多数企业中，修复开源漏洞的最终执行者是研发工程师，不是安全团队。

但研发没有安全背景，他们打开扫描报告看到的是一堆专业术语，第一反应是"这跟我有什么关系"。

AI 原生 SCA 的设计逻辑就是：研发打开页面的那一刻，不需要理解任何安全概念，就能知道自己该做什么。

产品不再展示传统的漏洞列表，而是由 AI 直接告诉用户：这次扫描，你需要关注 3 件事，2 个组件有真实可利用的漏洞，建议立即处理；1 个许可证在你的分发场景下有合规风险；其余 239 个组件暂时不用管。

点进某个组件，AI 已经把处置方案准备好了：改哪个文件的哪一行，修复代码是什么，直接复制粘贴就行；哪几处调用可能受兼容性影响，AI 也已经标出了具体位置，告诉你哪里需要测试；改完之后推送代码触发流水线验证即可。

研发工程师不需要读 CVE 描述，不需要查依赖树，不需要找安全团队确认，自己就能完成修复。

同样，许可证合规的场景也是如此。

过去，法务收到一份技术语言写的许可证报告，根本无法判断风险。

现在 AI 会直接用法务能理解的语言告诉他：GPL-3.0 在你们的外部分发场景下会导致产品源代码必须开放，涉及 3 个组件，需要立即评估。同时给出替换组件、申请豁免、采购商业授权等多种处置方案。

让每个角色都能用自己理解的语言，完成自己职责范围内的安全工作。

安全治理的真正价值 = 它降低的风险 - 它付出的成本。

如果修一个漏洞，安全团队要花 2 小时研判，研发要花 1 天理解和修改，法务还要花半天确认合规，那这个治理体系的成本就太高了。

很多企业不是不想做安全治理，是做不起。

AI 原生的 SCA 重构了这个成本结构：

我们做了一个粗略的测算：在典型的流水线处置场景中，AI 原生的 SCA 可以将单个漏洞的处置时间从平均数小时缩短到十几分钟。

当修复一个漏洞的成本足够低的时候，安全治理才有可能真正被落地执行，而不是停留在报告里。

过去 SCA 关注的是开源组件的漏洞和许可证风险。

但今天，随着 AI Agent 在企业中的快速落地，一个全新的供应链安全威胁正在浮现：Skills、MCP Server、IDE 插件，这些 AI 生态中的第三方扩展，正在成为新的攻击入口。

今年 2 月，ClawHub 平台上超过 10%的 Skills 被发现植入了恶意代码。攻击者通过仿冒热门技能包，在 skill.md 中注入恶意提示词，诱导 AI Agent 下载执行后门程序。

类似的攻击手法也出现在 MCP Server 和 IDE 插件生态中。这不是未来的威胁，而是正在发生的事情。

SCA 4.0 版本已经将 Skills 安全检测纳入 SCA 产品能力。

我们通过云端情报匹配结合本地代码深度分析，覆盖从源码到制品的多种检测场景，并且能够低成本嵌入现有的开发流程。

我们持续监测 clawhub、skills.sh 等主流平台数十万 Skills，同时覆盖 MCP Server、IDE 插件等 AI 生态的投毒威胁情报，做到全覆盖、高准确、快响应。

墨菲安全 SCA 是一款在检测深度和准确性上持续打磨了多年的产品。

我们覆盖主流编程语言，支持从源码到二进制再到容器镜像的多种场景检测，在漏洞可达性分析、非升级修复、许可证合规治理等核心能力上保持行业领先。

今天我们选择用 AI 原生的方式重塑 SCA，不是对产品的包装，而是它的进化。

我们一直相信，检测能力是基础，治理能力才是产品的真正价值。

AI 让 SCA 从一个检测工具，变成了一个能帮用户把问题真正解决掉的治理伙伴。

墨菲安全 SCA 4.0 全新版本已正式发布。我们非常期待与更多企业一起验证和打磨全新的工作方式。

今天正式邀请大家一起来体验我们的 SCA 4.0版产品。

我们的团队会全程参与试用过程，提供支持，以下是扫描申请体验通道，期待各位朋友参与：

2024年开始，墨菲安全联合互联网、金融、智能制造、央国企等十数家头部企业开始研发一套全新的企业安全治理框架（ESSF），2025年正式发布上线。

ESSF框架定义了企业安全度量体系标准、资产及风险分类标准，是SGP平台实现科学安全度量体系的底层支撑框架。

这套框架是一套动态持续更新的开源框架，它不断适应企业技术栈和面向威胁场景的变化，同时接受来自行业企业的意见和建议持续迭代，这使得它持续保持客观和科学，这是SGP实现企业安全度量及高效的治理体系的基石。

SGP平台的核心价值在于两句话：

1. 让每一项安全工作的价值被看见

2. 让每一个安全问题的处置更高效

墨菲安全AI原生驱动的安全治理平台核心的产品能力模块包括：

让每一个企业的管理者（CEO/CTO/CIO/业务负责人/董事会）都能够用一个指标，清晰的了解整个公司及每个核心业务线、业务部门的安全水位，他们可以轻松的决策投入多少成本将风险收敛到什么水位，同时可以随时验收投入所产生的安全成果。

对于管理者来说，从来担心的都不是安全工作没做好，而是有多少风险看不清。

同时让每一个参与企业安全治理工作的业务部门研发、员工都能看到自己的每一项安全工作给企业的业务带来的安全水位的提升，感受到他们的工作所带来的价值。

而对于每一个安全从业者来说，最大的成就感和价值感莫过于自己的每一份努力被企业管理者及业务部门、同事们看见和认可。

任何一项工作的真正价值=它所创造的价值—它所需要付出的成本。

同样，如何建立一套让风险治理的成本远远小于风险发生时带来损失的治理能力体系，让安全治理体系（和安全部门的工作）真正有价值，是企业安全部门落地时应该核心考虑的问题。

这也是我认为今天AI时代给所有安全从业者带来的最大的机会。

所以，我们坚定的认为墨菲安全企业安全治理平台（SGP）选择用AI原生的方式打造，是面向AI时代企业安全体系建设的新范式。

通过SGP平台原生的墨思AI Agent能力，我们重构安全问题处置的六大核心环节，实现300倍的效率的提升。

这些都是AI时代，给企业安全治理效率带来的极大提升和极大的想象空间。

墨菲安全整个团队过去十多年的企业安全的从业生涯，我们经历过安全行业的萌芽、快速发展、近几年面临挑战、现在让人兴奋的AI时代。

我们一直希望有机会能够和所有的从业者们一起打造一款产品，能够帮助更多的企业和从业者，让安全工作的价值真正被认可和看见，让整个行业走向良性和健康的发展。

今天，我们看到了做这件事情最好的时代来了。

感谢那些从墨菲安全2020年开始启程到现在近6年的时间里，一直支持和信任我们的几百家企业的安全大佬们。

也感谢所有在这个过程中给予我们支持和建议的从业者同行们。

尤其感谢在ESSF治理框架研发以及SGP产品试点过程中给我们非常多好的建议的大佬们，感谢洲豪、书魁、竟松、月胜、斯诺、为舟、小哥、文瑞、煜昆、棋琛、汪昱、大磊、圣哥、刘扬、鸡总、安康、小宝等等大佬。

其实我们在2025年中就正式上线了这个产品，但考虑到这是对于我们来说非常重要的一个产品，更是对于我们的企业客户来说非常重要的产品，同时，我们又知道这是一个底层逻辑和实现非常复杂的产品。

我们希望充分打磨和验证之后再面向大家发布。其实这个过程我跟很多朋友都分享过，大家一直在等我们发布。

所以，今天正式邀请大家一起来体验我们的这款全新的AI原生的安全治理平台产品。

所有通过这个通道申请适用的朋友我都会全程参与整个试用过程，并提供支持，以下是扫描申请体验通道，期待各位朋友参与：

3. 风险防不住——0day和投毒攻击的时间差

今天的企业面临的开源风险，已经不再只是传统 CVE 漏洞问题。

一方面，0-day 漏洞往往在漏洞库更新前存在 2-7 天的信息滞后；另一方面，供应链投毒攻击根本不依赖 CVE 编号，完全可以绕过以漏洞库为核心的传统检测体系。

而在真正发生新漏洞或投毒事件时，很多企业没有 SBOM 数据、没有统一资产底账、没有实时情报联动，依然要靠人工去盘查，响应速度天然慢半拍。

这就是为什么很多企业在事后复盘时都会发现：问题不是不知道风险严重，而是在风险真正来临时，没有足够快、足够准、足够体系化的响应能力。

正是基于上述真实痛点，墨菲安全联合中国电信研究院，正式发布《开源安全治理最佳实践2026版》，围绕七大章节，系统回答"为什么做、做什么、怎么做、如何持续做好"四个核心问题。

1. 第一章：全球及中国企业开源安全治理现状分析

本章从全球与中国企业的实践现状出发，系统梳理了当前开源治理面临的四类核心挑战：

• 一是投毒攻击呈现更强定向化与规模化趋势。文中指出，2025 年已监测到 59,000 余个恶意组件，攻击者正更加主动地利用生态链条实施渗透。

• 二是组件漏洞长期积累，漏洞数据每年新增约 42 万条，企业面临"已知风险发现不全、发现后治理不及时"的双重压力。

• 三是许可证合规问题不容忽视，53% 的代码库存在许可证冲突风险，合规治理已成为企业开源管理的重要组成部分。

• 四是大模型应用引入新的攻击面，企业在使用 AI 开发工具和开源模型时，也需同步关注依赖安全、模型来源可信性与使用边界。

这一章的核心价值，在于帮助企业管理层和技术团队形成统一认知：开源安全治理已经不是"可选优化项"，而是面向未来的软件安全基础能力。

2. 第二章：需求价值调研与现状评估

第二章强调，企业推动开源治理，首先要回答"为什么现在必须做"。

在方法上，本章提出了一套系统化调研框架，包括管理层访谈、历史事件回溯、行业对标分析、合规要求梳理等，帮助企业全面识别自身痛点与治理短板，为后续立项与实施打下基础。它解决的核心问题是，如何把技术风险翻译成管理层听得懂、愿意支持、愿意投入的业务语言。

3. 第三章：挑战分析及技术方案选型

本章聚焦技术落地中的关键难题，对方案选型逻辑进行了清晰归纳，提出了多个关键能力方向，包括：

• 面向复杂组件识别场景的代码指纹技术；

• 面向研发效率的增量扫描与分层治理机制；

• 面向高时效风险的实时情报体系；

• 面向投毒攻击防控的私有源网关与组件准入能力。

这一章的价值不在于给出唯一答案，而在于帮助企业建立一套与自身研发模式、技术栈和组织成熟度相匹配的选型思路。

4. 第四章：内部立项与高层汇报策略

本章从组织推动视角出发，回答企业"如何把这件事做成"。

给出了较为完整的立项与汇报框架，包括风险现状说明、收益价值界定、同行实践对标、实施路径规划和资源投入分析等内容，帮助企业形成15-20页的高质量汇报材料。清晰阐释"如果不做会有什么风险、做了之后会带来什么收益、为什么现在要启动"，帮助安全团队有效推动项目立项。

对于很多安全负责人来说，这一章尤其重要。因为治理项目推进的关键，很多时候并不只是技术方案是否成熟，而是是否能够让组织看到风险、理解收益、形成共识，让老板愿意拍板支持。

5. 第五章：灰度试点与策略调优

任何治理体系如果没有经过试点验证，很容易在全面推广阶段遭遇阻力。

因此，本章把试点拆分为前、中、后三个阶段，系统覆盖：

• 试点前明确目标范围、责任分工与评价标准；

• 试点中围绕存量风险检测与治理、增量风险识别与卡位、组件准入管控等开展策略落地；

• 试点后对问题进行归因复盘，持续优化治理规则和协作机制；

它强调的不是"一次性上线全部能力"，而是用灰度试点跑通闭环、沉淀经验、验证价值，再逐步放大。

6. 第六章：全面推广与流程嵌入

治理体系真正成熟的标志，不是试点成功，而是能否嵌入日常流程、变成组织惯性。本章重点回答了"如何从试点走向常态化"。

围绕全面推广阶段的关键动作进行设计，包括分阶段扩大覆盖范围、建立应急响应机制、规范例外审批流程、推动常态化复盘改进等，帮助企业把开源安全治理从"项目动作"沉淀为"组织能力"。

7. 第七章：持续运营

开源安全治理绝不是一次性工程，而是一项需要长期运营的能力建设。

本章从长期运营视角出发，构建了开源治理的持续演进框架。按照"系统上线 1-2 周 → 试点验证 3-4 周 → 全面推广 → 常态化运营"四阶段路径推进，配套 KPI 指标体系和组织架构设计，帮助企业把治理工作真正转化为可持续运行的机制。

归根结底，这份最佳实践要解决的，是很多企业过去一直难以回答的那个问题：开源安全治理到底该从哪里开始，又该如何持续做下去。

具体而言，它将帮助企业逐步建立五项核心能力：

这份最佳实践的形成，深度融合了多方能力与经验：

• 墨菲安全过去 5 年在数百家企业落地开源安全治理的实战积累；

• 中国电信研究院的权威研究；

• 小米、百度、京东、金山云、瑞幸、联合汽车电子等企业专家的专业支持；

这意味着，它不是纸上谈兵的理论集，也不是单一厂商视角下的"方法建议"，而是结合多行业、多组织、多场景的共同实践沉淀，它来自真实问题，也服务真实问题。

• 对企业安全负责人来说，它可以作为内部推动治理建设的参考框架；

• 对 DevSecOps 团队来说，它可以作为流程嵌入与能力建设的落地指南；

• 对研发负责人和信息安全管理者来说，它也能够帮助建立跨部门协同的共同语言。

开源，已成为数字经济时代的软件底座。

谁能更早建立软件成分视图、更快识别和处置风险、把治理嵌入研发和交付体系，谁就能在未来的软件竞争中建立更稳固的安全底座。

墨菲安全将持续联合产业伙伴，在开源安全治理、软件供应链风险防控、企业级最佳实践建设等方向深化合作，推动更多研究成果转化为行业可落地的方法体系，帮助更多企业把"知道要做"真正变成"知道怎么做、并且做得成"。

扫描图片末尾二维码，下载《开源安全治理最佳实践2026版》完整版。

如果您正在推动企业开源安全治理体系建设，或正在寻找一套兼顾专业性、实用性与可落地性的实施参考，欢迎获取完整版内容，进一步了解开源安全治理从认知、立项、试点到运营的完整方法路径。

以 OpenCode、OpenClaw 等为代表的高自主性 AI Agent，已经被广泛部署在用户本地环境中，并通过 Skill 或插件机制接入操作系统、开发工具及第三方服务。

Agent 在运行过程中通常会持续持有用户配置的上下文信息、访问凭据和执行权限，用于完成自动化任务。

在实际使用场景中，这类 Agent 通常可以直接执行命令、读写本地文件、发起网络请求，并与加密钱包、交易平台、企业系统等高价值目标建立连接。

随着 Agent 能力与权限的不断增加，其实际执行行为越来越依赖输入内容与扩展机制的具体执行路径，提示词输入与 Skill 执行逻辑逐渐成为影响 Agent 行为的关键控制面。

在 OpenClaw 的实际使用中，Agent 常被配置为自动读取邮件、消息或文件内容，并根据解析结果触发后续操作。

这类输入通常来自不受信任的外部来源，但在处理流程中会被直接纳入 Agent 的执行判断。

已有研究者披露OpenClaw在办公场景中存在数据泄漏风险，通过恶意邮件即可窃取敏感信息：攻击者向 OpenClaw 发送了一封包含提示词注入内容的邮件，随后触发 Agent 执行邮件检查流程。Agent 在处理该输入时执行了注入指令，并将运行环境中的私钥信息外传给攻击者，整个过程发生在 Agent 的正常执行链路内，如下图：

（https://x.com/Mkukkk/status/2015951362270310879）

在这种架构下，提示词与执行逻辑处于同一决策层级。

只要输入内容未与指令语义进行隔离，外部文本即可直接驱动 Agent 行为，构成对其执行过程的实质性接管。

ClawHub是openclaw提供的skill仓库，目前提供了近3000个skill，由于其管理较为松散，任意用户都可以发布自己的skill到公共仓库，在最近几天大量用户在其GitHub仓库中反馈发现恶意的被投毒skill。

通过分析我们发现ClawHub中约有10%的Skill存在恶意或可疑行为，用户直接信任将面临很高的数据泄漏及权限获取风险。

Skill 通常与 Agent 主体处于同一信任边界，继承其文件访问、网络请求与命令执行能力。

Skill 进入执行链路后，风险来源不止于 Skill 代码本体，还包括文档引导的操作步骤与外部依赖的可执行载荷，常见的风险类型如下：

样本中大量恶意行为写在文档“前置条件 / 安装步骤”里，常见形态为 Base64 解码后直接交给 shell 执行：

解码后的内容通常表现为从外部地址拉取并执行攻击者可控的恶意脚本：

ClawHub 平台发现恶意 Skill zaycv/clawhub，通过 Base64 混淆命令分发并执行远程脚本：

恶意 Skill zaycv/clawhub 分发远程执行载荷

macOS 链路中出现了稳定的“临时目录落地 → 去隔离 → 赋权 → 执行”结构：

该执行链路的关键特征包括移除隔离属性（xattr -c）并直接运行二进制载荷。载荷通常以通用 Mach-O 形式出现，具备信息窃取能力，目标涵盖浏览器数据、系统凭据及开发环境相关密钥。

示例：攻击者伪装 PDF 处理类 AI Skill，通过混淆安装指令诱导用户执行远程脚本，在 macOS 与 Windows 环境中分发并运行恶意程序。

“PDF Actions” 恶意 Skill 投放活动

部分 Skill 在功能代码中埋入命令执行点，触发路径位于正常业务流程内。典型形态为在业务函数里调用系统命令，从远端拉取并执行：

远端返回内容中可包含反向连接指令，用于建立持久的远程控制通道。

样本中存在直接读取 Agent 配置或上下文文件并外传的实现方式，代码形态通常为读取固定路径并向外部 webhook 发送。这类逻辑不依赖复杂投放链路，执行短、触发直接，目标集中在密钥、Token 与运行上下文，示例：

Skill 扩展机制把执行权限外放给第三方交付物。文档引导步骤、功能代码与外部载荷共同构成可执行链路，其中任一环节被投毒，恶意逻辑即可进入 Agent 的正常执行路径并继承其访问权限与持续运行条件。

在企业环境中，AI Agent 应被视为具备持续执行能力的高权限自动化系统，其风险不在模型输出本身，而在输入内容与扩展机制对执行行为的实际控制。防范重点可围绕以下三个方面展开：

针对提示词注入类风险，核心在于切断“外部内容 → 执行动作”的直接映射关系。来自邮件、消息、网页或文件的内容应统一视为不可信输入，仅用于信息处理，不应直接触发工具调用、命令执行或敏感数据读取。

企业侧应对涉及文件访问、网络外发、密钥读取等高风险操作设置明确的执行闸门，通过策略校验或人工确认介入，避免单条输入内容即可驱动完整执行链路。同时，应禁止 Agent 在无策略授权的情况下返回或外传密钥、Token、配置文件等敏感信息。

在OpenClaw文档中也针对skills的风险作出了提示，第三方Skill 应当默认不可信。安装与使用前需要阅读审查，需要覆盖 Skill 代码、文档中的执行指引以及其依赖的外部资源，避免通过“前置步骤”“辅助工具”等形式引入未受控的执行逻辑。

在运行时应尽可能在沙箱环境中，避免密钥泄漏到提示词或日志中。

即使输入与 Skill 均被滥用，风险也应被限制在可控范围内。Agent 的运行环境需要与企业核心系统、密钥存储及源码目录进行隔离，避免默认继承完整访问权限。

在实际部署中，应通过最小权限配置、运行隔离与出网限制，控制 Agent 能访问的数据与可到达的网络范围。同时保留关键执行行为的审计记录，以便在发生异常时能够快速定位、隔离并吊销受影响的凭据。

这件事情对企业的潜在威胁正在被很多企业远远低估，很多企业可能觉得是针对web3的，跟自己没关系。

但是一定要看到这次事件背后，是多么低成本的大规模高威胁的攻击路径呀，今天是web3，明天就不会是其他行业和企业吗？

墨菲安全实验室在2025年9月8日21:13分开始，检测到NPM仓库中，多个周下载量过亿的热门组件被投毒，攻击者通过发送钓鱼邮件，窃取了qix开发者的NPM账号进行投毒。关于该投毒事件的具体详情，可见上篇文章qix开发者账号泄漏导致NPM仓库超大规模投毒。

此次NPM仓库超大规模劫持投毒事件，手法简单粗暴，影响面极大，涉及9个周下载量过亿的开源组件被投毒。

根源竟然就是多个NPM生态开发者账号被钓鱼劫持，继而开始发布新版本，对web3行业开发者进行针对性的投毒攻击。

如此简单粗暴的攻击方式，却能控制使用量巨大的开源组件，并带来如此大规模的攻击影响。

试想，如果这次事件是针对你所在的大型企业，不管是窃取数据还是加密勒索，都将会给任何一家企业带来系统性的风险。

所以，此次攻击事件案例非常值得所有的企业重新认识开源软件供应链所带来的潜在威胁，并思考如何建立体系化的防护能力。

在持续的监测中我们发现，在第二天的9月9日9:13分，还发布了使用相同手法的投毒包duckdb，意味着攻击还在持续，后续可能还会有其他开发者受影响，此类钓鱼攻击手法可能成为NPM生态的长期威胁。

DuckDB开发者发布公告

duckdb开发者收到仿冒NPM官方钓鱼邮件

被投毒的duckdb相关组件包括：

组件名	版本
@duckdb/duckdb-wasm	1.29.2
@duckdb/node-api	1.3.3
@duckdb/node-bindings	1.3.3
duckdb	1.3.3

根据收到钓鱼邮件的开发者反馈，攻击者可能通过爬取NPM仓库中的开发者账号、邮箱后，发送大量钓鱼邮件，邮件内容为要求开发者更新双因素认证信息。

当开发者点击链接后，则进入仿冒的NPM官网（实际域名为 npmjs.help），其界面和操作与真正的 npmjs 官网一致。

受害开发者使用用户名和密码登录，并完成了双因素认证后，会被静默添加一个新的API token。

在操作过程中，由于所有请求被转发到了npmjs官网，用户看起来其信息、设置等均与 npmjs.com 网站完美一致，不容易怀疑。

在通过钓鱼获得API token之后，攻击者则挑选时机发布投毒包。

在目标代码包中，攻击者通过添加混淆后的恶意代码，隐藏真实意图。

当前发现的恶意代码相同，会劫持浏览器钱包（如 MetaMask）的网络请求（fetch 和 XMLHttpRequest），拦截 ETH、BTC、SOL、TRX 等加密货币交易，替换目标钱包地址，从而窃取数字货币。

但随着近期攻击行为的披露，后续投毒代码可能快速变种。

混淆后的恶意代码

从这次的攻击手法来看，并没有用太复杂高深的手法，轻易就能劫持数亿下载量的开源组件进行投毒，这意味着任何一个大型企业随时都可能面临大规模的攻击事件。

墨菲安全实验室每周检测发现数百起投毒事件，背后体现出当前包括NPM在内的开源生态安全仍然脆弱，风险还将持续相当长的一段时间。

从开源开发者的身份来看，热门组件的开发者容易成为攻击目标，近年来攻击者关注其开源项目、GitHub action中的漏洞，通过钓鱼、社会工程等方式以窃取账号/token为目标实施针对性攻击。

作为分发渠道的NPM及下游的镜像站，相比于多年以前的安全水位有所提升，但大部分开源社区的松散性导致安全治理仍面临很大挑战。

虽然npm audit实现了对部分已知公开风险组件的提示，但下游使用组件的开发者仍然缺少及时的风险感知能力，层出不穷的投毒随时可能影响各类开发者。

在企业安全治理角度，从员工办公终端、代码仓库、CICD到线上服务器，各个环节想要感知、响应投毒事件，依赖于系统性安全能力建设，多种安全能力联动。

在开源组件引入环节，应该建立企业内部的开源组件准入准出机制，目前墨菲安全帮助众多头部企业建立了私有源安全网关的防护能力，可以第一时间阻挡投毒组件的引入，比如本次超大规模npm组件投毒事件，墨菲安全实验室在2025年9月8日21:13分左右，第一时间就检测到了此次投毒事件的发生。

在代码开发和发布环节，可以引入软件成分分析（SCA）进行持续的代码投毒风险检测，并在发布流水线设置发布门禁，有效防止开源组件投毒风险发布至线上，影响线上用户。

此外，可订阅商业版的开源组件投毒情报，便于第一感知类似的风险并启动应急处置，及时止损。

当然，具备应急排查的能力前提是有SCA，能够前置构建企业内部开源组件资产库。不然有情报也没法排查，包括本次事件的情报在内，墨菲安全每周会为客户预警数百起，来自开源社区的投毒事件。

目前国内各行业的头部企业也均选择了墨菲安全的投毒情报作为安全防护的基础能力。

墨菲安全实验室在2025年9月8日21:13分开始，检测到NPM仓库中多个周下载量超千万的热门组件被投毒，这些组件均为qix开发者发布，可能由于其凭证泄漏导致账号被窃取。

从代码意图来看，投毒具有很强的针对性，是针对web3相关用户的大规模攻击。

⚠️墨菲安全已经支持检测，建议客户及时根据下方影响组件范围排查，临时降级止损。