Databricks 用领域知识注入提升 LLM 对 npm 二进制恶意包的检测
Databricks 提出在推理阶段注入领域知识，提升 LLM 对 npm 包内嵌二进制恶意载荷的检测能力。其扫描器自 2025 年 11 月起收集样本，在 11,413 个经 OSV 核验的包版本中，3.8%（432 个）捆绑二进制，这类包无法得出明确恶意结论的比例为 14.4%，是纯源码包 6.2% 的两倍多。团队用五种 .node 载荷测试九款模型，并设计能力画像作为加权条件编码恶意技术。
Databricks：Blog·2026-10-16 23:37· 2 小时前AI 评分47
填补二进制盲区：面向 npm 包 LLM 恶意软件分诊的领域知识注入
AI 导读
Databricks 提出在推理阶段注入领域知识，以提升 LLM 对 npm 包内嵌二进制恶意载荷的检测能力。其扫描器自 2025 年 11 月起收集样本，在 11,413 个经 OSV 核验的包版本中，3.8%（432 个）捆绑二进制，这类包无法得出明确恶意结论的比例为 14.4%，是纯源码包 6.2% 的两倍多。团队用五种 .node 载荷测试九款模型，并设计能力画像作为加权条件编码恶意技术。
正文
Introduction
针对包注册表的供应链攻击在数量和复杂程度上都在增长 [1]。公开研究经常观察到各类威胁行为者向 npm 注册表部署恶意软件，从垃圾邮件活动 [2] 到 DPRK 恶意软件的持续扩散 [3, 4, 5]，再到 2025 年和 2026 年影响重大的 TeamPCP [6, 7]，其中 DPRK 和 TeamPCP 行为者有着成功攻陷广泛使用的开源项目以最大化下游覆盖范围的记录 [8]。
为了直接研究这一问题，我们自 2025 年 11 月起一直在收集 npm 恶意软件样本，并观察到，在我们扫描并通过 OSV npm 恶意软件公告 [9] 核实的 11,413 个包版本中，npm 注册表上的大多数恶意软件将载荷隐藏在包源码中或从外部服务器获取，占已核实数据集的 96.2%。其余 3.8%，即 432 个包版本，捆绑了二进制文件。尽管数量不多，但它们在分诊过程中可能带来不成比例的风险。一个经过剥离、不透明的二进制文件不携带任何可供工具读取的源码，却可以嵌套在干净的源码和元数据伪装之下，并可能使 LLM 倾向于判定为良性。
我们评估了一组 LLM 如何在不同混淆和模糊程度下对精心构造的二进制载荷进行推理，识别出该攻击向量特有的失败模式，并通过一种专门构建、成本高效的领域知识编码方式加以弥补，从而同时提升经济型和前沿模型的检测质量。
Background
为支持更广泛的研究社区，我们构建了一个扫描器，实时监控 npm 注册表，并在 LLM 分诊前运行静态阶段：对 tarball 使用 YARA [10]，对 JavaScript 和元数据使用 Semgrep [11] 及 npm 注册表 API，并对编译产物运行二进制分析模块。它将输出组装成结构化提示，LLM 返回带有推理的判定，并可在最多三轮中请求额外文件。
我们的分析发现，捆绑二进制的包既是该流水线中最罕见的，也是最难分诊的。分发恶意 JavaScript 的攻击者可以假定目标已具备执行载荷所需的运行时，而二进制文件则必须针对一系列目标机器进行编译。在 OSV 确认的 npm 恶意软件中，携带二进制的包未能得出明确恶意判定的频率是纯源码包的两倍多（14.4% 对 6.2%）。
此前的工作在专家编写的数据上对开源模型进行指令微调，将知识固化到权重中 [12]。这条路线无法覆盖闭源托管模型，而且随着威胁形势变化需要重新训练。我们采取相反的方法，在推理时提供专业知识，即在模型推理之前将预先计算好的静态证据放入提示中。
Experimental Design
Objective
我们评估 LLM 能否检测出隐藏在预编译二进制文件中的恶意逻辑，而这些二进制文件位于其他方面干净的软件包中。第二个问题是，检测失败是系统性的还是随机的。第三，编码二进制问题的领域知识能否提高检测准确率。
对抗性载荷
我们构建了五种载荷类型（表 1）的原生 Node.js 插件（.node 文件），涵盖常见的供应链攻击模式。导入范围从可辩护的（fopen、connect、gethostname）到极少合法的（带 dup2 的 execve），每个软件包都将二进制文件包装在专业的 package.json、README、JavaScript 绑定和 binding.gyp 中。
sysmon 窃取器跨越了一条混淆阶梯，从可读的基线到剥离符号并对字符串进行 XOR 编码的加固构建，而其他四种类型则出现在单一的混淆级别。我们特意选择单字节 XOR，因为与 RC4 等更强的密码不同，它不会在反汇编中留下可供模型捕捉的结构标记。
该集合反映了收集到的恶意软件。在 OSV 确认的附带二进制文件的 npm 软件包中，格式为 PE、ELF（全部剥离）和 Mach-O，行为涵盖凭据和环境窃取、持久化、数据外泄和 C2、主机侦察以及投放器。
表 1. 对抗性载荷类型及其导入特征。
| 软件包 | 类型 | 关键导入 | 模糊性 |
|---|---|---|---|
| sysmon-native | 凭据窃取器 | fopen、connect、send、gethostname | 高 |
| buildchain-native | 投放器/后门 | execve、connect、chmod、socket、fwrite | 低 |
| netpulse-native | 反向 shell | execve、dup2、connect、socket | 低 |
| hashworker-native | 加密货币挖矿存根 | pthread_create、connect、send、recv | 中 |
| taskd-native | 持久化 | system、fopen、fwrite、chmod | 中 |
测试的模型
我们评估了来自七个提供商的九个模型（表 2）：七个团队会在其代码库中实际运行的预算模型，其中四个是开放权重模型，以及两个能力更强的基线模型，作为更高价位下的行为基线参考。我们还运行了 Claude Opus 4.6，这是最昂贵的模型，仅作为成本参考。
表 2. 评估的模型及其角色。
| 模型 | 提供商 | 角色 | 类型 |
|---|---|---|---|
| Claude Haiku 4.5 | Anthropic | 预算 | 专有 |
| Google Gemini 3.5 Flash | 预算 | 专有 | |
| Gemma 3 12B | 预算 | 开放权重 | |
| GPT-5.4-nano | OpenAI | 预算 | 专有 |
| Qwen3-Next 80B | Alibaba | 预算 | 开放权重 |
| GLM 5.3 Flash | Zhipu | 预算 | 开放权重 |
| Llama 3.1 8B | Meta | 预算 | 开放权重 |
| Claude Sonnet 4.6 | Anthropic | 基线行为 | 专有 |
| Kimi K3 | Moonshot | 基线行为 | 开放权重 |
| Claude Opus 4.6 | Anthropic | 成本基线 | 专有 |
为了隔离特征，每个载荷对每个模型扫描两次，一次不带特征，一次带特征。两次运行的提示、上下文和二进制分析完全相同。推理设置在所有模型和两种条件下保持不变：温度 0，全程使用相同的系统和分析提示，输出上限为 8192 个 token。
能力特征架构
能力特征是一种声明式剧本，将一种恶意技术（如凭据收集或持久化）编码为扫描器静态证据上的一组加权条件。这些特征涵盖 npm 和 PyPI 中的源代码和二进制技术。
图 1 展示了特征如何进入扫描：
- 静态阶段从软件包中提取证据。
- 每个配置文件都会根据其可疑、恶意和关键阈值对该证据进行评分，这一评分标准独立于模型自身的判定。
- 当达到某个阈值时，引擎会在模型推理之前向提示中注入一段结构化摘要（约1,800个token），同时注入静态和元数据分析器阶段发现的任何结果。
- 模型基于综合证据形成自己的判定，并且在本实验中，可以完全覆盖触发配置文件的判定。
图1. 带有能力配置文件的扫描流水线。
结果
每个模型都针对全部十个载荷进行了扫描。我们将HIGHLY_SUSPICIOUS或MALICIOUS计为检测成功；对已知恶意载荷给出SUSPICIOUS或BENIGN则计为失败。失败分析集中在七模型预算层级（70次模型-载荷测试）；两个基线（20次测试）仅作为参考上限，单独报告。
无能力配置文件
在没有配置文件的情况下，预算层级在70次测试中失败了35次（50%），其中20次完全为良性，并且在51次（73%）中未达到恶意标准。两个行为基线在升级阈值上均未失败，仅有一次未达到恶意标准（Sonnet，sysmon v3）。在预算层级内，失败遵循不同且可重复的模型特定模式（表3），而非随机错误；仅Gemini在检测上与基线持平，尽管其推理是虚构的而非真正的分析。完整的判定和置信度矩阵见附录（表A1）。
有能力配置文件
启用配置文件后，35次无配置文件检测失败中有32次（91%）恢复为检测成功，并且没有任何模型对任何载荷返回良性判定。所有在没有配置文件时失败的模型在启用配置文件后都达到了完全检测，除了GPT-5.4-nano，其三次残余失败在三个载荷上仍停留在可疑。在整个可负担层级中，升级阈值上的失败从50%降至4%（70次中3次），恶意标准上的失败从73%降至34%。
表3. 各模型检测率（对已知恶意载荷给出高度可疑或以上判定）在无能力配置文件和有能力配置文件下的对比。
| 模型 | 无配置文件 | 有配置文件 |
|---|---|---|
| GPT-5.4-nano | 0/10 | 7/10 |
| Qwen3-Next 80B | 1/10 | 10/10 |
| Llama 3.1 8B | 4/10 | 10/10 |
| Gemma 3 12B | 5/10 | 10/10 |
| Claude Haiku 4.5 | 6/10 | 10/10 |
| GLM 5.3 Flash | 9/10 | 10/10 |
| Gemini 3.5 Flash | 10/10 | 10/10 |
| Claude Sonnet 4.6 | 10/10 | 10/10 |
| Kimi K3 | 10/10 | 10/10 |
最清晰的单一案例是Qwen3-Next在混淆的sysmon-native窃取器上的表现：在没有配置文件时，以0.98的置信度判定为良性并建议加入允许列表；在启用配置文件后，对字节完全相同的输入，以0.98的置信度判定为恶意并建议阻止，此前有四个配置文件触发。基线Sonnet和Kimi在没有配置文件时已经正确，证据强化了它们的判定，因此配置文件强化而非扭曲了一个已经正确推理的模型。
配置文件触发
特定技术的配置文件根据每个载荷的攻击模式触发。
表4. 每个载荷在关键或恶意阈值下触发的能能力配置文件。
| 包 | 触发的关键配置文件 |
|---|---|
| sysmon-native | T004（二进制伪装）、T001（凭据收集）、T002（网络外泄）、T003（环境侦察） |
| buildchain-native | T004（二进制伪装）、T007（投放器/暂存器）、T002（网络外泄）、T001（凭据收集） |
| netpulse-native | T004（二进制伪装）、T006（反向shell） |
| hashworker-native | T004（二进制伪装）、T002（网络外泄） |
| taskd-native | T004（二进制伪装） |
讨论
失败模式分析
实验揭示了四种失败模式，每种模式都覆盖了评测面板中的很大一部分，而非局限于任何单一模型（表5）。这些模式并非互斥，因为一个良性判定既可能是忽视，也可能是合理化，因此表中报告的是各模式的普遍程度，一个模型所在行的计数之和可能超过十。我们从判定层级读取忽视和模糊化，从书面推理中读取合理化和虚构。
有两个因素可以解释这些现象。第一个是领域知识，预算型LLM缺乏在软件包上下文中解读二进制结构证据所需的领域知识[13]。第二个是原始能力。阅读经过剥离和字符串混淆的二进制文件需要反汇编和解码，而预算层级并未尝试这些操作。
表5. 在无配置文件的十个载荷上，跨全部九个模型的各模型失败模式计数（90次扫描）。
| 模型 | 合理化 | 忽视 | 模糊化 | 虚构 |
|---|---|---|---|---|
| Haiku 4.5 | 4 | – | 4 | 4 |
| Sonnet 4.6 | – | – | – | 4 |
| Gemini 3.5 Flash | – | – | – | 4 |
| Gemma 3 12B | 5 | 5 | – | – |
| GLM 5.3 Flash | 1 | – | 1 | 2 |
| GPT-5.4-nano | 10 | 2 | 8 | – |
| Kimi K3 | – | – | – | 6 |
| Qwen3-Next 80B | 9 | 9 | – | – |
| Llama 3.1 8B | 5 | 4 | 2 | 1 |
| 模型数（共9个） | 6 | 4 | 4 | 6 |
| 普遍程度 | ~37% | 22% | 16% | ~23% |
采用多数判定的集成方法无法解决这一问题。在混淆的sysmon-native窃取程序（版本2）上，九个判定分裂为三个良性（Gemma、Qwen、Llama）、两个可疑（Haiku、GPT-5.4-nano）、一个高度可疑（GLM）、三个恶意（Gemini、Kimi、Sonnet）：多数派低于检测阈值，因此投票返回了错误答案。这些模式不会相互抵消；它们会叠加，因此如果不首先弥合领域知识差距，任何投票方案都无法提供可靠的覆盖。这与LLM集成中多数投票的已知局限相符，即相关错误会汇聚到错误答案上而非相互抵消[14, 15]。
合理化（约占扫描的37%，涉及六个模型）援引上下文线索、安装脚本、原生模块打包或软件包描述，构建一个良性解释来覆盖二进制信号。Haiku将未混淆的sysmon v1判定为恶意，置信度0.98，但一旦字符串被XOR编码，其判定就降为可疑，将node-gyp-build视为标准做法，将.node扩展名视为合法插件，这与已记录的事后合理化相符[16]。因此，混淆颠倒了预期关系。载荷被隐藏得越彻底，被赋予的严重性就越低，而且由于理由在内部保持连贯，对未混淆样本的评估永远不会引发这种结果。
忽视（22%，涉及四个模型）在完全没有接触二进制文件的情况下返回良性判定。Qwen3-Next在十个载荷中的九个上返回良性，置信度0.98，并建议将每个都加入允许列表，包括netpulse反向shell和taskd持久化工具，其声明的意图完全忽略了二进制文件的导入。该判定对导入的模糊性不敏感，而统一的高置信度使这一失败对任何下游阈值都不可见。
对冲（16%，四个模型）会引发怀疑，但从未升级为决定性判定。GPT-5.4-nano 在十个载荷中的八个上以 0.55-0.62 返回 SUSPICIOUS，从未达到高度可疑或恶意，其中 buildchain-native 仅给出 SUSPICIOUS 0.62 以及“Monitor”的建议操作。可疑判定看起来像是在进行分析，却没有在 YARA 和 Semgrep 阶段之外增加任何内容，而在仅在恶意阈值处拦截的策略下，这些载荷会通过。
虚构（约 23%，六个模型）是奇特的情况，其判定正确但理由系捏造，因此将其记录以供审计的流水线会积累虚构的指标，从而误导后续分析师或任何基于这些指标微调的模型。它甚至出现在两个基线中，因此无论能力层级如何都会反复出现。Gemini 是最明显的案例。它对全部十个载荷都返回 MALICIOUS，但编造了细节，在 taskd 上报告“地址 0x401490 处的解密例程”，在 netpulse 上报告“地址 0x4013b0 处的自定义 XOR 解密循环”，尽管这两个地址在扫描输入中都不存在，且两个载荷都不包含密码。虚构集中在证据最薄弱之处，即单函数 x86 载荷，其扫描只暴露一个真实地址。
结构性缺口
这些漏检是结构性的，而非个别模型的缺陷。低于升级阈值的预算层级失败以合理化和驳回为主，其中二进制文件与干净的源代码、node-gyp-build 安装脚本、专业的元数据以及一份看似合理的 README 并存，对于原生模块而言每一项都平平无奇。没有任何单一工件会误导模型。35 次失败中的每一次都至少依赖其中两个良性信号，24 次同时依赖四个，14 次将二进制文件自身的导入重新表述为标准系统调用（表 6）。LLM 可以孤立地分析二进制证据 [17, 18]，但这里的失败是情境性的。
表 6. 35 次检测失败中引用的良性情境信号。
| 引用的良性信号 | 计数 |
|---|---|
| 安装脚本（node-gyp-build）被称为标准 | 35/35 |
| native-addon / .node 打包 | 35/35 |
| 元数据 / 所述用途“与……一致” | 32/35 |
| 干净的 lib/index.js JavaScript | 21/35 |
| 二进制文件自身的导入被重新表述为“标准/正常” | 14/35 |
失败模式的可预测性
这些模式是可预测的，因为每个模型都表现出一种，尽管没有一种在模型的整个输出中是确定性的，因此防御者不能简单地挑选一个更好的模型。这两个类别甚至以不同方式失败，驳回几乎完全是开放权重模型的行为（Gemma、Qwen 和 Llama 的 20 个无配置文件良性判定中有 18 个），而专有模型很少驳回，而是合理化、对冲或虚构。这与模型选择有关。一个由少数未混淆或低歧义包组成的测试集会让预算模型看起来足够，同时掩盖其在混淆凭据窃取器上的失败，而混淆在真实恶意软件中反复出现，Binary String Obfuscation 配置文件在 425 个 OSV 确认的二进制包中的 74 个上触发（17%）。仅测试高歧义载荷则产生相反效果，会否定一个尚可用的模型，并促使团队在前沿模型上过度支出。正确的判定也不意味着正确的标签，因为预算模型常常标记恶意性却分配错误的类别，因此类别和所述证据是分诊提示，而非归因的基准真相。
成本影响
基线 Sonnet 4.6 和 Kimi K3 在没有配置文件的情况下检测到了每一个载荷，其每次扫描成本约为预算档的 3 倍，而预算档在启用配置文件后以更低的价格达到了相同的准确率。配置文件还改变了每个模型所执行的 token 工作量（表 7），其方向取决于模型在无辅助情况下工作的努力程度。预算档因约 1,800 token 的证据块而承担了适度的输入溢价，输入上升了 9% 到 34%，其分析在其他方面保持不变，而更彻底的模型则朝相反方向变化。Opus 在没有配置文件时每次扫描会请求额外文件，收集约 10.5K 输入 token，启用后降至 7.2K（−32%），Kimi 出于同样的原因输出 token 减少了 13%。配置文件为廉价模型增加了一笔小而有限的输入成本，并从昂贵模型那里收回的远多于此。
表 7. 每个模型每次扫描的 token 使用量，在十个载荷上取平均，分别为无能力配置文件和有能力配置文件的情况。
| 模型 | 输入（无配置文件） | 输入（有配置文件） | Δ 输入 | 输出（无配置文件） | 输出（有配置文件） | Δ 输出 |
|---|---|---|---|---|---|---|
| Haiku 4.5 | 5,381 | 7,213 | +34% | 933 | 1,616 | +73% |
| Gemini 3.5 Flash | 7,000 | 7,614 | +9% | 493 | 488 | −1% |
| Gemma 3 12B | 5,866 | 7,623 | +30% | 420 | 506 | +21% |
| GPT-5.4-nano | 4,900 | 6,428 | +31% | 568 | 729 | +28% |
| Qwen3-Next 80B | 5,691 | 7,267 | +28% | 523 | 772 | +48% |
| GLM 5.3 Flash | 5,531 | 6,606 | +19% | 746 | 1,110 | +49% |
| Llama 3.1 8B | 4,884 | 6,402 | +31% | 302 | 351 | +16% |
| Sonnet 4.6 | 5,382 | 7,214 | +34% | 1,150 | 1,472 | +28% |
| Kimi K3 | 8,706 | 9,388 | +8% | 5,572 | 4,842 | −13% |
| Opus 4.6 | 10,551 | 7,214 | −32% | 1,254 | 1,370 | +9% |
生产验证
恶意集
公开 OSV 公告 [9]（排除已撤回条目）确认了 470 个携带原生二进制的恶意 npm 包版本，共计 604 个二进制文件。按格式划分，它们是 PE（273）、ELF（215，全部被剥离）和 Mach-O（113），另有 3 个未识别；按编译器划分，363 个是原生 C 或 C++，183 个是 Go，58 个是 Rust。这 241 个 Go 或 Rust 二进制文件占总数的 40%，正是引擎的运行时感知门控所针对的情况，其中 50 个（全部为 ELF）是 UPX 打包的。在这 470 个中，有 425 个落入我们已扫描、未撤回的语料库，构成检测中的评估集。
良性集
良性集仅根据外部信号定义，不依赖引擎自身的判定。一个包在满足以下条件时符合资格：携带原生二进制、月下载量超过一百万次，且从未出现在 OSV 中，由此得到 287 个不同包中的 2,449 个包版本。扫描器将其中 104 个升级为高度可疑或以上，假阳性率为包版本的 4.25%，集中在 6 个不同的包中，占 287 个的 2%。在这 104 个上，静态剧本也都触发了，并且在 33 个上，二进制能力配置文件达到了恶意或严重阈值，因此升级反映了二进制文件、打包、高熵区段和可疑导入中的真实信号。残余的假阳性率是静态二进制歧义性的固有属性。
检测
评估集是恶意集中带有生产判定的 425 个携带二进制的包版本（我们已判定语料库中的未撤回子集）。针对这些以及良性集，扫描器在升级阈值下达到精确率 0.77、召回率 0.81、F1 0.79（表 8）。召回率是针对 OSV 的包级标签评分的，该标签并不隔离恶意制品，并且二进制能力配置文件驱动了 74% 的检测，其余则因 JavaScript、元数据或源代码信号而被升级。
表 8. 在升级阈值下，跨 OSV 确认的二进制恶意软件和良性验证语料库的检测性能。
| TP | FN | FP | TN | 精确率 | 召回率 | F1 |
|---|---|---|---|---|---|---|
| 345 | 80 | 104 | 2345 | 0.77 | 0.81 | 0.79 |
扫描器在 425 个阳性样本中恢复了 345 个；60 个落入可疑，20 个被判定为良性，硬漏检率为 4.7%。检查这 20 个被判定为良性的包的元数据（不打开二进制文件），约一半原样打包了可识别的第三方工具（ripgrep、node-pty、NSIS 安装程序插件），而 OSV 将恶意归因于安装层或 JavaScript 层；其余则附带该包自身编译的 CLI，因账户接管活动或低置信度公告而被标记。因此二进制层面的漏检率低于标题数字，尽管我们并不声称每个被判定为良性的二进制文件都是良性的。
局限性
生产数据是依据 OSV 的包级标签衡量的，这些标签将整个包标记为恶意，而不区分具体是哪个产物；一些被判定为良性的包被错误标记，其载荷在 JavaScript 或元数据中，而非二进制文件中。因此报告的召回率和假阳性率描述的是针对这些标签的表现，而非专门针对二进制检测的表现，后者可能略高或略低。而且托管模型位于持续更新的端点之后，因此绝对判定反映的是某一个服务时期，可能会漂移，这就是为什么我们的结论基于同一时期内无配置与有配置条件下字节完全相同输入的差值，而非任何单一判定。
结论
四种失败模式——合理化、轻描淡写、模棱两可和虚构——在整个模型组中反复出现，在升级阈值下对 50% 的预算档测试产生检测失败，在更严格的恶意标准下为 73%。能力配置在模型推理之前注入预先计算好的二进制领域知识，将升级阈值下的失败降至 4%，并消除了所有良性判定，同时将良性集上的假阳性控制在包版本的 4.25%（2,449 个中的 104 个；不同包的 2%），低到足以让分析师手动清除。这些结合起来，使一个便宜得多的模型能够匹配一个昂贵得多的模型的检测准确率。
附录
表 A1。无能力配置下的判定（判定与置信度），按模型和载荷。这是表 3 和“无能力配置的结果”部分所总结的完整矩阵。
| 模型 | buildchain | hashworker | netpulse | taskd | sysmon v1 | sysmon v2 | sysmon v3 | sysmon v4 | sysmon v5 | sysmon v6 |
|---|---|---|---|---|---|---|---|---|---|---|
| Claude Haiku 4.5 | HIGHLY_SUSP 0.85 | HIGHLY_SUSP 0.85 | MAL 0.92 | HIGHLY_SUSP 0.85 | MAL 0.98 | SUSP 0.72 | SUSP 0.65 | SUSP 0.65 | HIGHLY_SUSP 0.78 | SUSP 0.72 |
| Gemini 3.5 Flash | MAL 0.98 | MAL 0.99 | MAL 0.98 | MAL 0.98 | MAL 0.98 | MAL 0.95 | MAL 0.95 | MAL 0.95 | MAL 0.95 | MAL 0.95 |
| Gemma 3 12B | HIGHLY_SUSP 0.85 | HIGHLY_SUSP 0.85 | HIGHLY_SUSP 0.85 | HIGHLY_SUSP 0.85 | HIGHLY_SUSP 0.85 | BENIGN 0.95 | BENIGN 0.95 | BENIGN 0.95 | BENIGN 0.95 | BENIGN 0.95 |
| GPT-5.4-nano | SUSP 0.62 | SUSP 0.62 | SUSP 0.55 | SUSP 0.62 | SUSP 0.62 | SUSP 0.62 | BENIGN 0.78 | BENIGN 0.78 | SUSP 0.55 | SUSP 0.62 |
| Qwen3-Next 80B | BENIGN 0.98 | BENIGN 0.98 | BENIGN 0.98 | BENIGN 0.98 | MAL 0.98 | BENIGN 0.98 | BENIGN 0.98 | BENIGN 0.98 | BENIGN 0.98 | BENIGN 0.98 |
| GLM 5.3 Flash | HIGHLY_SUSP 0.70 | HIGHLY_SUSP 0.80 | MAL 0.90 | HIGHLY_SUSP 0.85 | MAL 0.90 | HIGHLY_SUSP 0.80 | SUSP 0.60 | HIGHLY_SUSP 0.70 | MAL 0.85 | MAL 0.85 |
| Llama 3.1 8B | MAL 0.95 | HIGHLY_SUSP 0.85 | SUSP 0.80 | BENIGN 0.95 | HIGHLY_SUSP 0.85 | BENIGN 0.95 | SUSP 0.70 | MAL 0.95 | BENIGN 0.95 | BENIGN 0.95 |
| Claude Sonnet 4.6 | MAL 0.93 | MAL 0.97 | MAL 0.95 | MAL 0.92 | MAL 0.97 | MAL 0.95 | HIGHLY_SUSP 0.82 | MAL 0.92 | MAL 0.95 | MAL 0.95 |
| Kimi K3 | MAL 0.90 | MAL 0.90 | MAL 0.95 | MAL 0.85 | MAL 0.93 | MAL 0.92 | MAL 0.92 | MAL 0.90 | MAL 0.92 | MAL 0.90 |
参考文献
[1] Sonatype. “2026 State of the Software Supply Chain”. 2026. https://www.sonatype.com/state-of-the-software-supply-chain/introduction
[2] SourceCodeRed. “IndonesianFoods spam campaign publishes more than 86,000 malicious NPM packages”. 2025. https://sourcecodered.com/indonesianfoods-npm-worm/
[3] Kieran Miyamoto. “DPRK npm packages”. https://dprk-research.kmsec.uk/
[4] Amazon. “Amazon identifies North Korean hacker group behind open-source supply chain attacks”. 2026. https://aws.amazon.com/blogs/security/amazon-identifies-north-korean-hacker-group-behind-open-source-supply-chain-attacks/
[5] OpenSourceMalware. “PolinRider: DPRK Threat Actor Implants Malware in Hundreds of GitHub Repos”. 2026. https://github.com/OpenSourceMalware/PolinRider
[6] Zscaler. “Tracking Shai-Hulud: Inside the ChainDrop NPM Worm”. 2026. https://www.zscaler.com/blogs/security-research/tracking-shai-hulud-inside-chaindrop-npm-worm
[7] CISA. “Widespread Supply Chain Compromise Impacting npm Ecosystem”. 2025. https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem
[8] Unit42. “The npm Threat Landscape: Attack Surface and Mitigations”. 2026. https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/
[9] OSSF. “OpenSSF Malicious Packages”. https://github.com/ossf/malicious-packages
[10] VirusTotal. “What is YARA?”. 2026. https://docs.virustotal.com/docs/what-is-yara
[11] Semgrep. “Semgrep: lightweight static analysis for many languages”. https://semgrep.dev
[12] Levi, M. et al. “CyberPal.AI: Empowering LLMs with Expert-Driven Cybersecurity Instructions”. 2024. https://arxiv.org/pdf/2408.09304v1
[13] Ullah, S. et al. “LLMs Cannot Reliably Identify and Reason About Security Vulnerabilities (Yet?): A Comprehensive Evaluation, Framework, and Benchmarks”. 2024. https://arxiv.org/abs/2312.12575
[14] Traad, F.; Chehab, A. “To Ensemble or Not: Assessing Majority Voting Strategies for Phishing Detection with Large Language Models”. 2024. https://arxiv.org/abs/2412.00166
[15] Li, Q. et al. “Beyond Majority Voting: LLM Aggregation by Leveraging Higher-Order Information”. 2025. https://arxiv.org/abs/2510.01499
[16] Sharma, M. et al. “Towards Understanding Sycophancy in Language Models”. 2023. https://arxiv.org/abs/2310.13548
[17] Patsakis, C. et al. “Assessing LLMs in Malicious Code Deobfuscation of Real-world Malware Campaigns”. 2024. https://doi.org/10.1016/j.eswa.2024.124912
[18] Jelodar, H. et al. “Large Language Model (LLM) for Software Security: Code Analysis, Malware Analysis, Reverse Engineering”. 2025. https://arxiv.org/abs/2504.07137
来源：Databricks：Blog · databricks.com
来源：RadarAI · aihot.news