Databricks 如何用领域知识注入提升 LLM 对 npm 二进制恶意包的检测
Closing the Binary Blind Spot: Domain-Knowledge Injection for LLM Malware Triage in npm Packages
Databricks 针对 npm 恶意包中占比 3.8%（432 个包版本）的捆绑二进制样本，提出在推理阶段注入预计算静态证据的"能力画像"方案，而非微调模型权重。在 9 个模型上测试显示，含二进制包无法得出明确恶意结论的比例为 14.4%，是纯源码包 6.2% 的两倍以上。
引言
针对软件包注册表的供应链攻击在数量和复杂程度上都在增长 [1]。公开研究经常观察到各类威胁行为者向 npm 注册表部署恶意软件，从垃圾邮件活动 [2] 到朝鲜恶意软件的持续扩散 [3, 4, 5]，再到 2025 年和 2026 年影响重大的 TeamPCP [6, 7]，其中朝鲜和 TeamPCP 行为者有着成功入侵广泛使用的开源项目以最大化下游影响范围的记录 [8]。
为了直接研究这一问题，我们自 2025 年 11 月起一直在收集 npm 恶意软件样本，并观察到，在我们扫描并通过 OSV npm 恶意软件公告 [9] 证实的 11,413 个软件包版本中，npm 注册表上的大多数恶意软件将有效载荷隐藏在软件包源代码中或从外部服务器获取，占已证实数据集的 96.2%。其余 3.8%，即 432 个软件包版本，捆绑了二进制文件。尽管数量不多，但它们在分诊过程中可能带来不成比例的风险。一个经过剥离、不透明的二进制文件不携带任何可供工具读取的源代码，却可以嵌套在干净源代码和元数据的表象之下，并可能使 LLM 倾向于做出良性判定。
我们评估了一组 LLM 如何在不同程度的混淆和模糊性下对精心构造的二进制有效载荷进行推理，识别出该攻击向量特有的失败模式，并通过一种专门构建、经济高效的领域知识编码方式来弥补这些失败，从而同时提升预算模型和前沿模型的检测质量。
背景
为了支持更广泛的研究社区，我们构建了一个扫描器，实时监控 npm 注册表，并在 LLM 分诊之前运行静态阶段，对 tarball 使用 YARA [10]，对 JavaScript 和元数据使用 Semgrep [11] 和 npm 注册表 API，并对编译产物运行二进制分析模块。它将输出组装成结构化提示，LLM 返回带有推理的判定，并可在最多三轮中请求额外文件。
我们的分析发现，捆绑二进制文件的软件包既是流水线最难分诊的，也是最罕见的。分发恶意 JavaScript 的攻击者可以假定目标已具备执行有效载荷的运行时，而二进制文件则必须针对一系列目标机器进行编译。在 OSV 确认的 npm 恶意软件中，携带二进制文件的软件包未能得出明确恶意判定的频率是仅含源代码软件包的两倍以上（14.4% 对 6.2%）。
先前的工作在专家编写的数据上对开源模型进行指令微调，将知识固化到权重中 [12]。这条路线无法触及闭源的托管模型，而且随着威胁形势变化需要重新训练。我们采取相反的方法，在推理时提供专业知识，即在模型推理之前将预先计算好的静态证据放入提示中。
实验设计
目标
我们评估 LLM 能否检测出隐藏在原本干净软件包中预编译二进制文件里的恶意逻辑。次要问题是，检测失败是系统性的而非随机的。第三，编码二进制问题的领域知识能否提高检测准确率。
对抗性有效载荷
我们构建了五种原生 Node.js 插件（.node 文件）的载荷类型（表 1），覆盖常见的供应链攻击模式。导入范围从可辩护的（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称为MALICIOUS 0.98，但一旦字符串被XOR编码，其判定就降至SUSPICIOUS，将node-gyp-build视为标准，将.node扩展名视为合法附加组件，这与已记录的事后合理化相符[16]。因此，混淆颠倒了预期关系。载荷被隐藏得越彻底，所分配的严重性就越低，而且由于理由在内部保持连贯，对未混淆样本的评估永远不会引出它。
驳回（22%，四个模型）返回良性判定，而完全不涉及二进制文件。Qwen3-Next在十个载荷中的九个上返回BENIGN 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