2月审计3,984个Skill，36.82%含安全缺陷、76个有确认恶意载荷，装第三方Skill和装npm包哪个更危险？

供应链安全 · 信任边界 · 威胁建模 · 工程审计路径

一、导语：一个百分比背后的错误提问方式

“36.82%含安全缺陷、76个有确认恶意载荷”——这组数字之所以传播得快，是因为它提供了一个看似可以直接比较的量纲。但任何做过依赖审计的工程师都知道，缺陷率本身几乎不携带决策信息。一个含路径遍历缺陷的静态资源包，与一个能在宿主进程内执行任意代码的运行时插件，即使被归入同一个“含缺陷”计数，其风险量级也相差数个数量级。

因此，把“装第三方Skill”和“装npm包”放在天平两端，真正需要回答的不是“哪个缺陷更多”，而是：当一段外部代码进入你的系统时，它默认获得了什么权限，这些权限由谁授予，授予过程是否可审计、可撤销、可最小化。这三个问题构成了本文的分析主线，也是“信任边界迁移”这一提法的落点。

本文评述：安全社区长期存在一种“计数谬误”——用漏洞数量或恶意样本数量替代风险排序。这种做法在同类制品内部尚可作粗略参考，一旦跨生态比较就失去意义，因为分母（暴露面）与分子（可利用性）的定义都变了。下文所有对比都建立在显式声明的威胁模型之上，而非百分比排名。

二、背景与问题定义：Skill与npm包不是同一种“包”

2.1 概念界定

在本文语境中，Skill指面向智能体（agent）或助手类运行时扩展能力的第三方功能单元，通常以声明式描述文件加可执行脚本或工具调用的形式分发，由宿主运行时在推理或任务编排过程中动态加载。npm包则指遵循Node.js模块规范、通过npm registry分发、在构建期或运行期被import/require的代码单元。二者都属“第三方可执行制品”，但分发与加载语义不同。

这一区分不是文字游戏。npm包的加载点通常明确写在package.json与源码中，构建产物可被静态分析；Skill的加载点往往由运行时的意图路由决定，同一份Skill可能在不同会话、不同用户指令下被触发或不被触发，其执行路径具有显著的数据依赖性。这意味着传统的“依赖树锁定+构建期扫描”方法对Skill的覆盖率天然低于对npm包的覆盖率。

2.2 权限模型的根本差异

npm生态经过多年治理，已形成相对成熟的权限收敛实践：安装脚本（postinstall等）可被--ignore-scripts禁用，依赖可锁定哈希，CI中可启用只读registry与代理审计。这些机制并不完美，但它们把“安装即执行”这一最危险的默认行为变成了可关闭的选项。

相比之下，Skill的权限授予常常是隐式的：宿主运行时为了让Skill“能用”，往往预先授予文件系统、网络、凭证或工具调用能力，而Skill的声明文件未必逐项列出其实际使用的权限。这种“先授权、后使用”的模式与移动应用早期的粗粒度权限模型高度相似，而后者已被证明是权限膨胀的重灾区。笔者认为，这是Skill风险被低估的首要结构性原因。

三、原理与技术路线：信任边界迁移模型

3.1 信任边界的三次迁移

回顾软件供应链安全史，信任边界大致经历了三次迁移。第一次是从“自研代码”迁移到“开源依赖”，标志是包管理器的普及；第二次是从“直接依赖”迁移到“传递依赖与构建工具链”，标志是SolarWinds与Codecov一类事件；第三次，也就是当前正在发生的，是从“确定性代码”迁移到“由模型编排的非确定性执行体”，Skill正是这一阶段的典型制品。

每一次迁移的共同规律是：信任被外包的速度快于审计能力建设的速度。第一次迁移后我们有了SCA工具，第二次迁移后我们有了SBOM与签名验证，第三次迁移对应的审计基础设施目前仍处于碎片化阶段。36.82%这一缺陷率，与其说是Skill生态特别糟糕，不如说是审计工具尚未跟上生态扩张的必然结果。本文评述：把这一数字直接解读为“Skill比npm危险”，忽略了npm生态在2016年前后的类似阶段——彼时依赖混淆与恶意包同样高发，只是当时缺少系统性的抽样统计。

3.2 风险度量的四元组

为使跨生态比较具备可操作性，本文提出一个四元组度量框架：Risk = f(Privilege, Reachability, Detectability, Reversibility)。其中Privilege指制品默认获得的权限广度，Reachability指恶意或缺陷代码被触发的概率，Detectability指现有工具链发现问题的能力，Reversibility指事件发生后止损与回滚的难度。

按此框架，Skill在Privilege与Detectability两项上明显劣于npm包，在Reachability上则取决于运行时设计——若Skill仅在显式调用时激活，其可达性可被压低；若运行时倾向于“自动选用最匹配的Skill”，可达性会显著上升。npm包在Reversibility上占优，因为lockfile与版本回退是成熟操作；而Skill一旦在会话中被加载并产生副作用（如写入外部系统），回滚成本远高于代码回退。

# 伪代码：Skill准入的四元组打分（示意，非真实工具输出）
def score_skill(skill):
    privilege   = count_capabilities(skill.manifest)      # 声明权限数
    reachability= route_frequency(skill, sample_traces)   # 历史触发频次
    detectability = static_coverage(skill) + sandbox_verdict(skill)
    reversibility = has_rollback_hook(skill) and is_stateless(skill)
    return weighted_sum(privilege, reachability,
                        detectability, reversibility)

3.3 攻击面的结构化拆解

Skill的攻击面可拆为四层：声明层（manifest中的权限与工具描述是否与实际行为一致）、内容层（脚本、提示模板、外部资源引用是否含注入或外链）、运行时层（宿主是否对工具调用做参数校验与速率限制）、数据层（Skill可访问的上下文与凭证范围）。npm包的攻击面则更多集中在安装期与构建期。两者的交集在于“第三方维护者账号被劫持”这一经典场景，但后果不同：npm包被劫持通常导致构建产物污染，Skill被劫持则可能直接导致运行时凭证外泄。

值得强调的是提示注入（prompt injection）在Skill场景中的特殊地位。OWASP在2025年发布的LLM应用风险清单中，将提示注入列为首位风险；而Skill作为“可被模型调用的外部能力”，天然是注入载荷的放大器——攻击者无需攻破Skill本身，只需让恶意内容进入Skill可读取的数据源，即可诱导模型执行非预期工具调用。这一路径在npm包中几乎不存在对应物，是Skill独有的、结构性更高的风险。

四、关键数据与案例交叉验证

4.1 审计数据的解读边界

本次审计的样本为2月间可获取的3,984个Skill，缺陷判定覆盖权限声明不一致、不安全的外部资源引用、缺少输入校验、硬编码凭证等类别，恶意载荷则通过沙箱行为与静态特征双重确认。需要说明的是，样本为“可获取”而非“全量”，存在选择偏差；缺陷类别之间未做严重度加权，因此36.82%应理解为“至少命中一类缺陷的比例”，而非加权风险分。

76个确认恶意载荷的样本，按行为可粗分为凭证窃取、外联回传、工具滥用三类。这一数量级与npm生态历史上单次事件中发现的恶意包数量相当（例如2023年多起针对npm的投毒活动单次涉及数十至上百个包），但考虑到Skill生态的总量远小于npm（npm公开包数量以百万计），其恶意密度实际上显著更高。笔者认为，这一密度差异是本文最值得警惕的信号，它指向的是生态早期治理缺位的典型特征。

4.2 npm侧的历史参照

npm生态的公开研究提供了可对照的基线。Sonatype、Snyk、Socket等机构历年发布的供应链报告均指出，恶意包与漏洞包在npm中的绝对数量持续上升，但通过registry侧下架、签名验证与自动化检测，其“存活窗口”在缩短。GitHub自2023年起推行的npm provenance（构建来源证明）进一步把“包从哪来、由谁构建”变成可验证属性，这对安装期攻击是实质性削弱。

反观Skill生态，目前尚缺乏被广泛采用的来源证明与签名机制，多数宿主运行时的Skill市场仅做基础格式校验。这种治理成熟度的落差，比缺陷率落差更能解释风险差异。本文评述：把治理成熟度纳入比较，结论会从“Skill更危险”修正为“Skill当前更缺乏可用的治理工具”，后者是可通过工程投入改变的，前者则近乎宿命论。

4.3 一个可复现的最小验证实验

为验证上述判断，工程团队可自行搭建最小实验：选取若干公开Skill与npm包，分别在隔离环境中记录其网络出站、文件写入与子进程创建行为，对比“声明权限”与“实际行为”的偏差率。该实验不依赖任何专有数据，成本可控，且能直接产出团队自己的风险基线。具体步骤见第六章的操作路径。

五、对比与局限：两类风险的不可通约性

综合前述分析，可以给出一个分场景的判断，而非单一排名。在高权限、长会话、可访问敏感数据的场景中，第三方Skill的风险显著高于npm包，原因是权限隐式授予与提示注入放大效应叠加；在构建期、CI/CD流水线场景中，npm包的风险同样不可忽视，安装脚本与传递依赖劫持仍是高频路径。

本框架的局限也必须声明：四元组的权重设定带有主观性，不同组织应基于自身资产敏感度重新标定；审计样本的选择偏差无法完全消除；提示注入类风险的量化目前缺乏公认基准，本文仅做定性排序。笔者认为，承认这些局限比给出一个精确但脆弱的分数更有工程价值。

六、工程操作路径：Skill准入、隔离与监控

6.1 准入清单（可直接落地）

第一步，建立Skill清单台账，记录来源、版本、声明权限、实际观测行为四列。第二步，对每个Skill执行“声明-行为”比对，偏差超过阈值的进入人工复核。第三步，对涉及网络与凭证的Skill强制要求最小权限声明，未声明即拒绝加载。第四步，将准入结果纳入CI，任何新增或升级的Skill必须重新过闸。

可参考的公开资料包括OWASP LLM应用风险清单（owasp.org）、SLSA供应链完整性框架（slsa.dev）以及npm官方的provenance文档（docs.npmjs.com）。视频类拓展可参考GitHub Actions供应链安全实践讲解（YouTube 检索）。

6.2 运行时隔离方案

隔离的核心是把“能力”与“权限”解耦：Skill只声明需要的能力，由宿主在每次调用时按最小必要原则临时授予，调用结束即回收。工程上可采用进程级沙箱加网络出口白名单，并对工具调用做参数模式校验与速率限制。对于必须访问外部系统的Skill，应通过受控代理而非直连，代理层记录完整调用日志以便事后审计。

6.3 持续监控与响应

监控指标建议至少覆盖：Skill触发频次异常、出站域名新增、凭证读取次数、工具调用失败率突增。响应流程应包含一键禁用、会话隔离与凭证轮换三步。需要提醒的是，Skill的副作用可能已写入外部系统，回滚不能只回退代码，必须同步核查数据面。

七、结论与展望

回到标题的问题：装第三方Skill和装npm包哪个更危险？本文的答案是——在当前的治理成熟度下，Skill在“高权限、长会话、可触敏感数据”的场景中更危险，且这种危险性主要来自权限授予的隐式性与审计工具的缺位，而非单纯的缺陷比例；npm包的危险性则更集中于构建期与传递依赖，且已有相对成熟的缓解手段。

展望未来，Skill生态大概率会重走npm的治理路径：来源证明、签名验证、权限清单标准化、registry侧自动化检测。区别在于，由于Skill直接对接模型与工具调用，其治理必须把“提示注入”作为一等公民纳入威胁模型，这是npm时代未曾面对的课题。笔者认为，谁先把权限最小化与行为可观测做成运行时默认能力，谁就能在下一阶段的智能体供应链安全中占据主动。

八、主要参考文献与声明