引言
针对软件包注册表的供应链攻击在数量和复杂程度上都在增长[1]。公开研究经常观察到各类威胁行为者向 npm 注册表部署恶意软件，从垃圾邮件活动[2]到朝鲜（DPRK）恶意软件的持续扩散[3, 4, 5]，再到 2025 年和 2026 年造成重大影响的 TeamPCP[6, 7]；其中朝鲜行为者和 TeamPCP 都有成功入侵被广泛使用的开源项目、以最大化下游影响范围的记录[8]。
为了直接研究这一问题，我们自 2025 年 11 月起持续收集 npm 恶意样本，并观察到：在我们扫描并通过 OSV npm 恶意软件公告[9]核实的 11,413 个 package-version 中，npm 注册表上的大多数恶意软件将载荷隐藏在包源码中或从外部服务器获取，占已核实数据集的 96.2%。其余 3.8%（432 个 package-version）捆绑了二进制文件。尽管数量不大，但它们在分诊过程中可能带来不成比例的风险。一个经过剥离、不透明的二进制文件不包含任何可供工具读取的源码，却可以被嵌套在干净的源码和元数据外表之下，并可能使 LLM 倾向于得出良性结论。
我们评估了一组 LLM 在不同混淆程度和歧义程度下如何对精心构造的二进制载荷进行推理，识别出这一攻击向量特有的失效模式，并通过一种专门构建、成本高效的领域知识编码方式来弥补这些缺陷，从而同时提升预算级模型和前沿模型的检测质量。
背景
为支持更广泛的研究社区，我们构建了一个扫描器，实时监控 npm 注册表，并在 LLM 分诊之前运行静态阶段：对 tarball 运行 YARA[10]，对 JavaScript 和元数据运行 Semgrep[11] 及 npm 注册表 API，并对编译产物运行二进制分析模块。它将输出组装成结构化提示，LLM 返回带有推理的判定结果，并可在最多三轮内请求额外文件。
我们的分析发现，捆绑二进制文件的包既最罕见，也最难被流水线分诊。分发恶意 JavaScript 的攻击者可以假定目标已具备执行载荷所需的运行时，而二进制文件则必须针对一系列目标机器进行编译。在 OSV 确认的 npm 恶意软件中，含二进制文件的包未能得出明确恶意判定的频率是纯源码包的两倍以上（14.4% 对 6.2%）。
先前的工作通过对专家编写的数据进行指令微调来训练开源模型，将知识固化到权重中[12]。这条路线无法覆盖闭源的托管模型，而且随着威胁态势变化需要重新训练。我们采取相反的方法，在推理阶段提供专业知识，即在模型推理之前将预先计算好的静态证据放入提示中。
实验设计
目标
我们评估 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 原生窃取器：不启用画像时判为良性、置信度 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 原生窃取器（版本 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 对十个载荷中的八个返回 SUSPICIOUS，置信度 0.55-0.62，从未达到高度可疑或恶意，其中 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 |
| 原生插件 / .node 打包方式 | 35/35 |
| 元数据 / 所述用途“与之一致” | 32/35 |
| 干净的 lib/index.js JavaScript | 21/35 |
| 二进制文件自身的导入项被重新解释为“标准/正常” | 14/35 |
失败模式的可预测性
这些模式是可预测的，因为每个模型都会表现出其中一种，尽管没有任何一种在某个模型的全部输出中具有确定性，因此防御者不能简单地换一个更好的模型。这两类模型的失败方式甚至不同：轻率否定几乎完全是开放权重模型的行为（20 次无画像良性判定中有 18 次来自 Gemma、Qwen 和 Llama），而专有模型很少轻率否定，而是合理化、模棱两可或虚构。这关系到模型选择。一个由少量未混淆或低歧义包组成的测试集会让预算级模型显得足够好用，同时掩盖其在混淆凭据窃取器上的失败；而混淆在真实恶意软件中反复出现，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 个，全部经过 strip 处理）和 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 年软件供应链状况”。2026 年。https://www.sonatype.com/state-of-the-software-supply-chain/introduction
[2] SourceCodeRed。“IndonesianFoods 垃圾邮件活动发布超过 86,000 个恶意 NPM 包”。2025 年。https://sourcecodered.com/indonesianfoods-npm-worm/
[3] Kieran Miyamoto。“朝鲜 npm 包”。https://dprk-research.kmsec.uk/
[4] Amazon。“Amazon 识别出开源供应链攻击背后的朝鲜黑客组织”。2026 年。https://aws.amazon.com/blogs/security/amazon-identifies-north-korean-hacker-group-behind-open-source-supply-chain-attacks/
[5] OpenSourceMalware。“PolinRider：朝鲜威胁行为者在数百个 GitHub 仓库中植入恶意软件”。2026 年。https://github.com/OpenSourceMalware/PolinRider
[6] Zscaler。“追踪 Shai-Hulud：深入解析 ChainDrop NPM 蠕虫”。2026 年。https://www.zscaler.com/blogs/security-research/tracking-shai-hulud-inside-chaindrop-npm-worm
[7] CISA。“影响 npm 生态系统的广泛供应链入侵”。2025 年。https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem
[8] Unit42。“npm 威胁态势：攻击面与缓解措施”。2026 年。https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/
[9] OSSF。“OpenSSF 恶意包”。https://github.com/ossf/malicious-packages
[10] VirusTotal。“什么是 YARA？”。2026 年。https://docs.virustotal.com/docs/what-is-yara
[11] Semgrep。“Semgrep：面向多种语言的轻量级静态分析”。https://semgrep.dev
[12] Levi, M. 等。“CyberPal.AI：以专家驱动的网络安全指令赋能 LLM”。2024 年。https://arxiv.org/pdf/2408.09304v1
[13] Ullah, S. 等。“LLM 尚无法可靠地识别和推理安全漏洞（目前？）：全面评估、框架与基准”。2024 年。https://arxiv.org/abs/2312.12575
[14] Traad, F.; Chehab, A. “集成与否：评估大语言模型钓鱼检测中的多数投票策略”。2024 年。https://arxiv.org/abs/2412.00166
[15] Li, Q. 等。“超越多数投票：利用高阶信息的 LLM 聚合”。2025 年。https://arxiv.org/abs/2510.01499
[16] Sharma, M. 等。“理解语言模型中的谄媚倾向”。2023 年。https://arxiv.org/abs/2310.13548
[17] Patsakis, C. 等。“评估 LLM 在真实恶意软件活动恶意代码去混淆中的表现”。2024 年。https://doi.org/10.1016/j.eswa.2024.124912
[18] Jelodar, H. 等。“用于软件安全的大语言模型（LLM）：代码分析、恶意软件分析、逆向工程”。2025 年。https://arxiv.org/abs/2504.07137
在您的收件箱中获取最新文章
订阅我们的博客，最新文章将直接发送到您的收件箱。