根据评选标准，“中国网安新势力30强”主要面向创新型企业，从资源支撑力、市场表现力和创新成长力三个维度，对企业综合能力进行评估。

其中，创新成长力关注企业在技术创新、商业模式、业务增长、市场拓展及人才发展等方面展现出的持续发展和进步能力。

连续三年入选，对墨菲安全而言，是行业对公司技术路线、产品化能力和客户价值的持续观察与认可。

过去几年，墨菲安全始终以软件供应链安全为核心切入点，在开源组件识别、漏洞可达性分析、许可证合规、漏洞及投毒情报等方向持续深耕，帮助企业把复杂的软件资产和供应链风险看清楚、管起来、落到处置闭环中。

随着 AI 应用快速融合进企业的数字化系统、开源生态、第三方软件，安全团队面对的风险形态也在变化。单一漏洞或单个组件背后的影响，往往会沿着资产、依赖、服务、责任人、业务影响和修复路径相互传导。

围绕这一变化，墨菲安全的能力也从软件供应链安全进一步延展到企业安全风险治理：通过 SCA、源安全网关、威胁情报、漏洞治理、安全度量以及企业安全风险治理决策平台 SGP 等能力，帮助企业建立更完整的风险视角。

近日，国内网络安全领域专业媒体与产业智库安全牛正式发布《中国网络安全行业全景图（第十三版）》与《AI+网络安全全景图（2026版）》。

本次全景图调研经过分析师多轮人工核验、复核与 AI 辅助统计分析相结合的方式完成，覆盖网络安全 17 个一级大类、122 个二级细分赛道。

凭借在传统网络安全领域的产品能力，以及在前沿 AI 安全领域的创新实力，墨菲安全同时入选两大全景图。

在《中国网络安全行业全景图（第十三版）》中，墨菲安全分别上榜 网络与通信安全 - 反恶意软件网关、软件供应链安全 - 软件成分分析、安全支撑技术与体系 - 威胁情报 多个赛道。

图片来源：安全牛《中国网络安全行业全景图（第十三版）》

8月8日，“AI时代企业安全治理”主题沙龙将在深圳开展，本次沙龙由深圳市网络与信息安全行业协会作为指导单位，由墨菲未来科技（北京）有限公司（简称“墨菲安全”）主办，安克创新科技股份有限公司协办。

沙龙将围绕AI进入企业之后的安全治理、内部实践、工作方式变化与Agent安全体系，进行4场主题分享和1场圆桌讨论。

今天，把大家比较关心的活动时间、地点、完整议程和参会安排，全都同步给大家。

本次闭门沙龙将安排在周六的下午，结束后有晚宴交流，具体安排如下：

1. 沙龙主题：AI时代企业安全治理

2. 沙龙时间：2026年8月8日（周六）14:00-18:00

3. 沙龙地点：深圳安克大楼（创业二路388号）

4. 详细地址：广东省深圳市宝安区新安街道雪花科创城创业二路388号

5. 沙龙形式：主题分享 + 圆桌讨论 + 晚宴交流

6. 沙龙议程：初步安排，时间段根据现场情况微调：

时间	地区	联系方式	分享人
13:30-14:00	30min	签到入场	/
14:00-14:05	5min	主持人开场及嘉宾介绍	周欣 墨菲安全COO
14:05-14:45	40min	议题1：《AI时代企业安全治理方案及落地实践》	欧阳强斌 墨菲安全联创&业务线负责人
14:45-15:25	40min	议题2：《安克AI安全实践》	陈智 安克创新AI安全负责人
15:25-16:05	40min	议题3：《AI赋能安全工作的思考》	lake2 某互联网公司 X 业务线安全负责人
16:05-16:25	20min	中场休息-茶歇	/
16:25-17:05	40min	议题4：《从单点防控到全局治理：Agent安全体系建设的思考与实践》	林道正 百度智能云云安全架构师
17:05-18:00	55min	圆桌讨论：《AI时代企业安全治理体系和组织的变革》	主持人： 章华鹏--墨菲安全创始人&CEO 4位嘉宾： 1. 职业欠钱--某互联网企业风控团队负责人 2. 徐浩冬--微众银行应用安全负责人 3. 沈海涛--OPPO 子午安全实验室负责人 4. 肖文棣--晨星中国业务信息安全官
18:00	/	晚宴	/

上周，我们发出了线下沙龙即将在深圳开展的预热和邀请8月深圳线下沙龙，继续聊AI和企业安全，收到了不少朋友的报名和咨询，也看到大家在报名备注里提到很多具体问题。

这些反馈也让我们更加确定：AI 和企业安全的讨论，已经进入了更具体的实践阶段。

当 AI 开始进入企业的研发、办公、生产和业务流程，安全团队面对的问题也在变化：

8月8日，我们将携手多位行业大佬，带着他们在实际业务中的实践和思考汇聚线下，也欢迎更多朋友在文末扫码报名本次沙龙活动。

目前，本次活动的嘉宾及议题已经初步拟定，也基本对应了大家关心的一些问题。

随着安全大模型、代码大模型和安全智能体的发展，模型是否具备真正可用的网络安全能力，正在成为一个越来越具体的问题。

尤其当行业开始关注 Mythos 等国际前沿安全模型时，很多国产大模型厂商也开始重新审视：如果模型要在网络安全领域具备专业能力，它到底应该学什么？

漏洞公告、CVE 编号、安全问答、攻防知识以及代码样本，都是模型进入网络安全领域的重要材料。

但一个真正可用的安全模型，不能只知道概念，它还需要：

这也是国产大模型厂商在建设网络安全能力时绕不开的问题：缺少高质量、结构化、贴近真实安全场景的数据，模型很难从“会回答安全问题”，走向“会做安全判断”。

墨菲安全作为业界领先的漏洞数据服务商，漏洞库涵盖超过50万条高质量漏洞数据，并持续沉淀 PoC、触发函数、利用条件、修复方案、修复 commit、投毒样本等安全数据能力。

我们希望把这些长期沉淀积累的数据，转化为大模型可学习、可评测、可落地的安全能力。

过去，很多通用大模型已经具备一定安全知识。它们可以解释常见漏洞类型、总结安全公告、回答一些基础攻防问题。

但当模型进入更专业的网络安全任务后，差距会很快显现出来。比如：

这些能力很难从通用语料里自然长出来。

网络安全是一个强上下文、强实践、强细节的领域。模型要在这个领域真正可用，需要见过足够多高质量的漏洞样本，理解漏洞从描述、成因、触发、利用到修复的完整链路。

所以，对于正在建设安全能力的国产大模型厂商来说，安全数据的价值就在这里。它补充的不只是知识量，更是模型面向真实、专业安全任务的能力底座。

很多模型训练团队会从 CVE、NVD、CNVD、GitHub 安全公告等公开数据开始。这些数据非常重要，是漏洞知识体系的基础。

但公开漏洞库通常更适合人去检索和阅读，并不是为模型训练准备的完整数据集。

一条漏洞记录往往会提供编号、描述、评分、影响范围和参考链接。

对于安全专家来说，这些信息足以作为入口，进而继续去查公告、看代码、找 PoC、读修复 commit，再结合经验判断漏洞是否可达、是否可利用、应该怎么修。

而模型训练是需要把这部分“专家会继续做的事”显性化，转化成可以学习、可以评测、可以复用的数据。

比如：

这些信息，才是模型从“背安全知识”走向“做安全判断”的关键。

如果缺少这类细粒度上下文，模型可能知道 Log4j、Fastjson、Spring、Tomcat 等组件出现过漏洞，但很难真正理解漏洞在工程代码里如何触发、如何验证、如何修复。

墨菲安全长期深耕软件供应链安全、漏洞治理与投毒情报场景，沉淀了面向企业安全治理、自动化分析和模型训练的漏洞数据能力。

目前，墨菲安全漏洞库已覆盖超过 50 万条高质量漏洞数据，并保持持续增长。数据来源覆盖 NVD、CNVD 等官方漏洞库，GitHub 等第三方漏洞来源，也包括在野漏洞、软件供应链投毒情报，以及墨菲安全自研分析和挖掘沉淀的数据。

相比普通漏洞列表，墨菲安全面向大模型训练、模型评测和自动化安全分析场景，提供的是结构化、细粒度、持续维护的数据体系。

每条漏洞数据除了包含漏洞编号、标题、描述、影响组件、影响版本、漏洞等级、CVSS 评分、参考链接等基础信息。还进一步提供 40+ 结构化字段，覆盖漏洞理解、漏洞验证、漏洞触发、漏洞利用条件、修复建议和修复代码等关键环节。

这些字段的价值，在于把漏洞从一段“可阅读的信息”，变成模型可以学习的结构化样本。

模型看到的内容，不再停留在“某组件存在一个远程代码执行漏洞”这一层，它还可以进一步学习：

这类数据更接近安全专家分析漏洞时真正使用的上下文，也更适合模型学习漏洞分析过程中的判断链路。

对于国产大模型厂商来说，高质量漏洞数据可以服务于多类能力建设。它既能用于基础模型的安全能力增强，也能用于安全垂直模型、安全智能体和模型评测体系。

大模型厂商的任务	需要的数据	墨菲安全可提供的价值
提升漏洞理解能力	漏洞成因、影响范围、风险边界	帮助模型理解漏洞从描述到影响的完整上下文
提升代码安全能力	触发类、触发函数、触发参数、修复 commit	帮助模型学习漏洞在真实代码中的表现方式
提升漏洞验证能力	PoC、利用条件、利用成本	帮助模型区分理论风险和真实可利用风险
生成修复建议	最小修复版本、缓解方案、修复步骤	让模型给出更贴近工程落地的处置建议
构建安全评测集	细粒度字段、标准化样本	支撑安全模型能力评测和能力对齐
训练供应链安全能力	投毒情报、恶意样本、风险标签	提升模型识别恶意组件和供应链攻击的能力

具体来看，这些数据可以支持模型在以下方向持续增强。

除了漏洞数据，墨菲安全还可以提供投毒情报及恶意样本相关数据。

随着开源生态、插件生态和 AI 工具链的发展，软件供应链投毒风险正在变得更加复杂。

NPM、PyPI 等开源组件，IDE 插件、浏览器插件，以及面向 Agent 的 Skill 等新型生态，都可能成为攻击入口。

大模型如果要具备更强的恶意代码分析、供应链攻击识别和投毒行为理解能力，仅靠传统漏洞数据是不够的。还需要看到真实的恶意样本、投毒行为、风险标签和分析结果。

这类数据可以帮助模型理解恶意代码如何伪装、投毒组件如何传播、供应链攻击如何影响开发者和企业环境，从而提升模型在软件供应链安全方向的能力。

在安全智能体场景中，这一点会变得更加重要。

未来，模型不仅要理解传统漏洞，也要理解开发者社交工程、开源包投毒、插件恶意行为、Agent 工具链滥用等新型风险。

墨菲安全在软件供应链安全和投毒情报方向的长期积累，可以为这些能力建设提供更贴近真实场景的数据基础。

大模型能力提升，离不开模型架构、算力和训练方法。但在网络安全这样高度专业、强上下文、强实践的领域，数据质量同样影响能力上限。

低质量、粗粒度、缺少上下文的数据，很容易让模型学会表面知识，却难以参与连续的安全分析任务。

真正适合安全能力建设的数据，需要满足几个条件：

这也是墨菲安全建设漏洞库和投毒情报能力的核心方向：围绕大模型训练、网络安全能力评测、自动化漏洞分析和企业安全治理，对漏洞数据进行持续整理、补充、分析和结构化，让安全数据能够真正进入模型能力建设流程。

今天，国产大模型厂商正在系统提升模型的网络安全能力。

如果模型要对标国际前沿安全模型，就需更要具备漏洞理解、代码风险分析、利用条件判断、修复建议生成和安全任务推理能力。

这些能力，离不开高质量漏洞数据和真实安全场景的长期积累。

墨菲安全希望把多年沉淀的漏洞库、投毒情报和结构化安全数据能力，服务于国产大模型厂商的网络安全能力建设。

如果你的团队正在建设安全垂直模型、安全智能体、网络安全能力评测体系，或希望提升基础模型在漏洞理解、漏洞分析、修复建议和恶意代码识别方面的表现，欢迎与墨菲安全交流。

过去几个月，我们陆续在北京、上海组织了线下闭门沙龙，每一场我们都收到来自各行业众多企业安全负责人/安全专家大佬的踊跃报名，围绕AI和安全的话题，结合大家面对的各种不同AI+企业安全场景进行了深度交流和研讨。

3月底，在北京办了第一场关于AI和企业安全的线下闭门沙龙，聊了 AI 对企业安全的冲击；

5月底，去到上海，和更多企业安全负责人、安全专家和行业伙伴们进一步讨论了 AI 时代企业安全面临的挑战、治理实践和组织变革。

每一场活动从报名到现场交流讨论都非常的热烈，可见关于AI 和 企业安全的话题大家都非常的关注。

不同企业引入AI的程度不同，遇到的问题不同，安全建设基础也不同。

面对各类场景，没有一套可以被所有企业直接照搬的标准答案，但是很多有价值的信息和想法都是在不断的交流和碰撞中获得启发。

过去也一直有广东的朋友在问什么时候去深圳办。

所以，第三站，我们来到了深圳。

这次我们依然邀请了来自科技、智能制造、金融等领域的安全大佬来到现场分享和讨论，同样准备了议题分享、圆桌讨论、晚宴等多种形式的活动。

希望继续把真正关心AI和安全的朋友们聚到线下，面对面坐下来聊聊已经遇到的问题、正在开展的实践，以及那些还没有明确答案的困惑。

欧盟《网络弹性法案》（Cyber Resilience Act，CRA）已经生效。

2026 年 9 月 11 日报告义务将率先适用，要求所有销往欧盟市场的含数字元素产品制造商的漏洞与安全事件连续性强制报告义务。

对智能制造企业来说，影响往往落在那些容易被忽略的软件部分：固件、嵌入式系统、通信模组、移动 App、云端接口、第三方 SDK、开源组件，以及供应商交付的软件包。

产品进入欧盟市场后，企业需要能说明这些数字部分如何被设计、验证、维护和修复。

事项	关键含义
监管对象	投放欧盟市场的带有数字元素的硬件、软件及单独投放市场的组件
关键时间	2026 年 9 月 11 日报告义务先适用，2027 年 12 月 11 日主要义务全面适用
准备重点	产品分类、技术文档、漏洞处理、SBOM/SCA、供应商交付件和版本证据链

过去很多企业谈 SCA，更像是在讨论一类检测工具。

但在汽车电子这类软件形态复杂、版本生命周期长、第三方依赖多、交付责任重的场景里，真正的问题从来不是“扫不扫”，而是组件安全治理能不能真正进入研发、构建、发布、部署和漏洞响应流程。

我们在推进 SCA 建设时，选择的并不是单点补工具，而是围绕代码仓、发布流水线、镜像仓、私有组件库、存量系统和漏洞应急，逐步搭建一套覆盖开发到运营阶段的组件安全管理体系。

它的价值不只体现在平时的漏洞发现，更体现在高危漏洞爆发时，能不能快速圈定影响面、明确责任边界、推动修复闭环。

6 月底，很多企业安全团队都会迎来一场不太轻松的会——年中总结汇报。

上半年做了什么？下半年预算怎么规划？这些问题都要在这场汇报里向老板讲明白。

汇报的 PPT 往往准备了大量数据：发现了多少漏洞、关闭了多少工单、拦截了多少攻击、建设了多少能力、跟进了多少情报、推动了多少整改......

这些工作都很重要，也投入了不少精力。

但真正到了汇报现场，管理层关注的并不是这些过程数据本身，他更想问的是：

相信很多安全负责人都经历过类似场景。前面几十页汇报内容都讲得很详细，到最后总结却只能归纳一句：总体可控，但仍存在一定风险。

这句话不能算错，但它就像行业里的一句标准答案。稳妥，正确，但没用。

因为它无法说明风险变化情况，也难以解释安全团队上半年的哪些投入产生了什么效果和价值，更无法为后续的预算规划和治理优先级提供直观的依据。

很多企业并不缺数据：漏洞数据有、告警数据有、工单数据有、扫描结果有、资产清单也不止一份。

真正困难的是，如何把这些专业数据转化成管理层、业务部门和安全团队都能够理解的语言。因为不同角色关注的问题并不一样：

如果没有统一语言，这些问题就会变成各说各话：

最后，大量的安全工作又回到靠人解释、靠人推动、靠人背锅。

这也是为什么很多安全团队常面临的困境：明明做了很多工作，但还是被看作是成本中心，价值很难清晰地展示出来。

并不是因为安全不重要，只是缺少一套能持续衡量、能被横向比较以及对外表达的管理方式。

一场真正能被老板认可的年中汇报，至少要回答清楚这五个问题：

如果这几个问题回答不清，这场年中汇报最后就很容易陷入“做了很多但说不清价值”的尴尬局面。

墨菲安全SGP是 AI 原生的安全治理平台，它基于企业安全治理框架 (ESSF)，通过持续度量与治理分析，帮助企业建立统一的安全评价体系，实现科学度量和高效治理。

它所解决的核心问题，就是把复杂的安全数据，转化成管理层、业务负责人和安全团队都能理解的共同语言。

在 SGP 里，企业安全状态不再是“整体可控”的模糊判断，它会被拆解成三个维度进行持续观察和衡量：

指标	回答的问题	作用
CSI	现在整体安全水位怎么样？	把企业、组织、业务或应用的安全状态量化成可比较、可追踪的结果
SAI	该覆盖的安全能力有没有覆盖到位？	让能力建设从“有没有”变成“覆盖了多少、盲区在哪里”
SII	已经发现的问题有没有被有效处理？	让处置动作不只停留在关工单，而是体现到安全状态的改善上

这三项指标都采用分值形式呈现，分数越高代表状态越好。

• CSI（Cyber Security Index）

CSI 解决的是“我们现在到底有多安全”？它不只是统计漏洞数量，还会综合考虑资产情况、风险暴露程度、安全能力覆盖情况以及治理效果，形成能够反映整体安全状态的综合评分。

CSI安全分 驾驶舱图

• SAI（Security Ability Index）

SAI 解决的是“安全能力建设是否覆盖到位”？它关注的不只是企业是否采购或部署了相关安全产品，更关注这些能力是否真正覆盖到了应覆盖的资产和场景，以及覆盖盲区在哪里。

SAI安全能力覆盖得分 驾驶舱图

• SII（Security Improvement Index）

SII 解决的是“治理工作是否产生了改善”？它关注的不仅是关闭了多少工单、处理了多少问题，更关注这些治理动作是否推动了安全状态的持续提升和改善。

SII安全问题处置得分 驾驶舱图

当安全状态能够被拆解和量化之后，安全汇报也就从专业判断变成了经营判断，具备了更强的管理价值。

管理层能够清楚看到：

这时候才能真正支撑管理者去做资源投入和安全治理的决策。

很多人提到“安全量化”，首先想到的是“数据大屏、各种图表、颜色、趋势线”等等。

但对于企业来说，展示形式并不重要，重要的是这些结果是否足够可信、是否能够支撑决策。

这个过程中，真正的难点往往出现在更基础的层面：

如果这些基础问题没有解决，再丰富的看板也很难发挥真正价值。

因此，墨菲安全SGP首先构建的是一套统一的数据底座。

平台以应用为核心，把组织、业务系统、负责人、代码仓库、主机、域名、制品、镜像、软件成分和各类安全问题关联起来，建立完整的治理关系图谱。

当安全治理的“分母”被明确讲清楚之后，企业才具备开展安全量化、趋势分析和价值评估的基础。

SGP 资产管理模块

在这个过程中，AI承担的更多是治理效率放大器的角色。

它不是独立展示的一个功能模块，或者用来“讲故事”的一个摆设。它是真正深入到安全度量和治理流程中，帮助企业处理过去需要大量人工完成的工作。比如：

也就是说，对于业务负责人而言，可以更清晰地理解：

对于安全团队来说，也能够减少大量沟通和协调成本，把更多精力投入到治理工作本身上去。

最终，安全工作的投入、过程和结果能够形成更加完整的价值链路，并沉淀为持续可追踪的安全状态变化。

当这些问题能够被持续量化、持续跟踪和持续验证时，安全治理才能真正进入可衡量、可管理、可优化的新阶段。

这也是墨菲安全SGP希望帮助企业实现的目标：让每一项安全工作的价值被看见， 让每一个安全问题的处置更高效。

如果你也正在准备年中安全汇报，或者正面临类似的问题：

墨菲安全现面向企业免费提供一次安全水平度量评估，帮助企业从资产管理、风险治理、漏洞管理等多个维度，了解当前的安全状态。扫码申请还可免费领取《安全度量最佳实践》，作为企业建设安全度量体系的重要参考。

今天（6 月 18 日），国家安全部微信公众号发文提醒警惕软件“供应链投毒”，再次把软件供应链安全问题推到企业和公众面前。

文章中提到，国家网络安全通报中心监测发现，近期集中爆发多起供应链投毒攻击事件，涉及开源软件仓库和商用工具两大核心供应链场景。

而且相关“供应链投毒”事件呈现出攻击隐蔽性强、影响范围广、危害程度高、传播速度快等共性特征，可造成凭据窃取、远程代码执行、敏感数据泄露等严重后果。

国家安全部发文

这不是一次普通的安全提醒。

过去，很多企业把供应链投毒理解成“开发者不小心装了一个恶意包”、“某个开源组件出了问题”。

但从国家层面的连续预警来看，供应链投毒已经不只是研发侧的局部风险，而是可能从开发终端、代码仓库、制品库、CI/CD 流水线一路传导到生产系统、核心业务和下游客户的系统性风险。

它的本质是：攻击者不再只攻击你的系统，而是攻击你信任的软件来源、开发流程和交付链条。

一旦上游被污染，下游就会被动中招。

国家安全部文章中提到，软件供应链投毒是一种典型的“上游污染、下游传导”模式。攻击者通过劫持开发者官方账号、篡改开源代码仓库源码、污染软件安装包与发布版本等方式，将恶意程序植入软件中。随着软件发布和更新，这些恶意逻辑会被输送到大量终端和业务系统中。

对企业来说，这类风险最麻烦的地方，不在于“有没有恶意代码”这个判断本身，而在于它会同时击穿多条传统防线。

• 第一，传播范围难以控制。

  一个基础组件可能被数以万计的软件依赖。只要某个核心组件、插件或开发工具被污染，风险就会沿着依赖链向下游扩散。企业即便没有直接安装恶意包，也可能因为某个间接依赖、某次构建、某个供应商交付版本而受到影响。

• 第二，攻击对象直指高价值凭据。

  开发环境、构建平台、服务器里往往保存着 GitHub Token、npm Token、云服务密钥、SSH 私钥、数据库连接串、Kubernetes 凭据等敏感信息。供应链投毒一旦进入这些环境，攻击者拿到的不是单台机器的权限，而可能是进入企业内网和发布链路的“钥匙”。

• 第三，修复周期长、责任链条复杂。

  普通漏洞往往可以通过升级补丁解决；但投毒事件要先确认毒源、影响版本、传播路径，再排查哪些项目、镜像、制品、环境、终端曾经拉取或执行过相关组件，最后还要完成凭据轮换、环境清理和版本回滚。对大型企业来说，这不是一次简单的漏洞修复，而是一场供应链级别的应急响应。

这也是为什么，国家安全部在防护建议中特别强调了“守好入口关”、“管住依赖链”、“看紧运行端”、“厘清责任方”。

这些要求落到企业内部，最终指向的是同一件事：企业必须建立可持续的软件供应链风险感知、检测和阻断能力。

墨菲安全自 2022 年开始提供供应链投毒情报服务，是国内较早将投毒情报产品化、服务化的供应链安全厂商之一，已服务上百家互联网、金融、智能制造等行业头部客户。

在真实客户场景中，我们看到的变化非常明显：

• 过去企业更关注“有没有高危漏洞”；现在，越来越多安全团队开始问：“有没有投毒包正在被我们的研发、构建、制品或终端使用？”

• 过去企业主要担心生产环境被攻击；现在，攻击者已经把目标前移到开发者终端、代码仓库、CI/CD 流水线、插件生态和 AI 工具链。

• 过去企业以为中央仓库下架恶意包就够了；现在，很多投毒包从发布到被下架之间，已经完成下载、构建、执行、外联和凭据窃取。

对企业来说，真正关键的不是“官方最终有没有处理”，而是你能不能在自己的供应链里第一时间发现、定位并阻断。

根据墨菲安全研究院此前发布的《2025 年软件供应链投毒风险研究报告》，2025 年全年，墨菲安全识别到的投毒包总量突破 59,000 个，相比 2024 年增长超过 50%，日均新增投毒包超过 200 个。其中，NPM 仓库仍是投毒重灾区，占比超过 87%；与此同时，攻击目标正在从传统组件仓库向 IDE 插件、浏览器扩展、GitHub Action、AI 工具链等新型生态加速蔓延。

这组数据说明，投毒不是小概率黑天鹅，而是每天都在发生的灰犀牛。

更值得警惕的是攻击方式的演变：

从 2025 年到 2026 年，墨菲安全持续跟踪并公开预警多起投毒事件。

以下事件也说明，供应链投毒正在从单点恶意包，演进为批量化、蠕虫化、跨生态联动的攻击模式。

时间	事件	风险要点	参考链接
2026年6月	AI Agent 开发框架 Mastra 被投毒	攻击者通过在受影响组件的依赖链中引入恶意包实施攻击，当开发者环境或 CI/CD 流程安装了相关版本，恶意链路就会自动触发：一阶段样本负责下载并执行二阶段后门载荷，随后在本机建立持久化、回传主机信息，并等待远程控制指令下发。	AI Agent 开发框架 Mastra 被投毒，周下载量超百万
2026年5月	AntV 生态组件 Mini Shai-Hulud npm 蠕虫式投毒	涉及多个常用前端可视化组件，风险可通过企业前端工程和构建流程向下游传导	Mini Shai-Hulud｜微软 durabletask SDK 被投毒，下载量超百万
2026年5月	TanStack 等组件 Mini Shai-Hulud npm 蠕虫式投毒	蠕虫式传播手法继续扩散，影响前端与 AI/机器学习相关开发者、开源维护者及企业研发人员	Mini Shai-Hulud 蠕虫式投毒继续扩散，TanStack、Mistral、Squawk 等生态受影响，周下载量超千万
2026年3月	Axios 组件供应链投毒事件	攻击者劫持维护者账号发布恶意版本，借助高下载量基础组件放大影响，可能导致远控、凭据窃取和内网横向移动	NPM热门HTTP请求库 Axios 被投毒，攻击者植入后门
2025年11月	asyncapi 等组件 Shai-Hulud 蠕虫式投毒事件	数小时内多个 NPM 组件被相同方式投毒，恶意代码下载 TruffleHog 扫描本机凭据，波及大量 GitHub 仓库	SHA1HULUD蠕虫再现：超300NPM包被投毒、 2万仓库信息被窃取
2025年9月	qix开发者账号泄漏导致NPM仓库超大规模投毒事件	受影响投毒组件被植入恶意的混淆代码 index.js 文件，该恶意代码会劫持浏览器钱包和网络请求，拦截 ETH、BTC、SOL、TRX 等加密货币交易，通过替换目标地址将资金转移至攻击者钱包	qix开发者账号泄漏导致NPM仓库超大规模投毒

除了上述大规模事件，墨菲安全曾经还首发和披露多起针对国内企业与开发者生态的投毒攻击，包括：

• 2023 年 8 月，发现首起针对国内金融企业的开源组件投毒攻击事件；

• 2023 年 10 月，发现针对腾讯云 / 阿里云 / AWS 的 SDK 仿冒投毒攻击事件；

• 持续发现大量 NPM、浏览器插件、IDE 插件、AI 生态相关投毒样本。

这些事件共同指向一个结论：供应链投毒的应对窗口非常短，企业不能等“事件上新闻”以后再开始排查。

如果一个恶意包已经进入构建流程，安全团队晚一天知道，可能就意味着多一批制品被构建、多一批镜像被发布、多一批凭据需要轮换、多一批环境需要排查。

国家安全部文章提出的防护建议，落到企业实践中，可以拆成三个能力层次。

墨菲安全“供应链投毒治理”方案

在墨菲安全此前发布的《漏洞及投毒情报应用实践指南 2026 版》中，将漏洞与投毒情报的落地场景拆解为多个典型应用，包括资产监管排查、组件选型与准入、日常漏洞管理、修复优先级重构、漏洞与投毒事件应急响应、出海与标准合规支撑、AI 供应链漏洞与投毒治理，以及作为数据底座增强 SCA / WAF / EDR / SIEM 等安全工具链。

这背后的核心观点是：情报不能停留在“人看公告”的阶段，而要进入系统、流程和工具。

在投毒治理中，情报至少要服务四类动作：

如果情报只能以文章、群消息、PDF 的形式存在，它对企业的帮助就会被响应链路拖慢。

真正有效的投毒情报，应该能被 SCA、私有源网关、CI/CD、SIEM、SOAR、终端安全平台直接消费，成为企业安全运营的一部分。

供应链投毒不是某一次事件，也不是某一种语言生态的问题。

它已经覆盖 NPM、PyPI、Maven 等开源仓库，延伸到 GitHub Action、IDE 插件、浏览器扩展、AI Agent、MCP / Skills 等新型软件供应链场景。对企业来说，只要仍在使用开源组件、第三方工具、外部插件、AI 开发生态，就不可能完全绕开这类风险。

区别只在于：

国家安全部这次预警，真正提醒企业的不是“某几个包有风险”，而是：软件供应链已经成为攻击者高频利用的入口，企业必须把它纳入持续化、体系化治理。

墨菲安全建议企业优先完成三件事：

当投毒攻击正在以日均数百个恶意包的速度出现，企业需要的不是又一次事后复盘，而是一套能真正跑起来的供应链投毒治理能力。

如果你的团队正在评估 npm、PyPI、Maven、GitHub、IDE/浏览器插件或 AI 生态相关供应链风险，

欢迎联系墨菲安全，预约一次系统性的供应链投毒风险排查交流。不要等恶意包进入构建流水线，才开始寻找它从哪里来。

过去企业谈开源安全，大多关注组件漏洞。

但近年来，随着供应链攻击不断升级，开源风险的边界已经明显扩大。恶意投毒、插件生态以及 AI 开发工具扩展等新场景，正在成为新的风险入口。

对出海智能制造企业来说，这个问题比互联网软件更复杂。一个产品背后，往往同时涉及固件、嵌入式软件、云平台、App、第三方 SDK 和供应商交付件，链条长、版本多、生命周期也更长。

一旦出问题，影响的不只是研发效率，更可能波及客户交付、渠道上架、海外审计，甚至带来召回与品牌风险。

更关键的是，海外监管和客户要求正在同步收紧。SBOM、开源许可证合规、漏洞响应、供应商交付安全，正从“最佳实践”逐步变成“市场准入要求”。

很多企业真正的难点，不是缺一套扫描工具，而是回答不了几个现实问题：

• 产品里到底用了什么开源组件？

• 高危漏洞影响哪些版本和客户？

• 供应商交付件是否可追溯？

• 客户或监管问询时，能不能快速拿出证据？