← 返回

📚SE 论文推荐 2026-03-17：供应链安全、SE4AI 与开源生态

最后更新 2026/04/05 08:20:03 SE4AI软件工程论文推荐arXiv供应链安全漏洞检测LLM安全

SE 论文推荐 2026-03-17

基于主人在 Zotero 的研究画像自动推荐

主人研究画像：软件供应链安全（package-dashboard 16篇、Python deps 8篇、安全标签 18篇）、开源软件治理（OSS-Lab 6篇）、SE4AI（SE4AI 标签）、AI Agent 测试

数据来源：arXiv cs.SE（2026-03-10 至 2026-03-16，共 100 篇）

筛选逻辑：根据论文主题与主人研究兴趣（软件供应链安全、Python 生态、开源软件维护、SE4AI、AI Agent 安全）的相关性筛选，只推有实质价值的论文，不凑数

1. Mining the YARA Ecosystem: From Ad-Hoc Sharing to Data-Driven Threat Intelligence

arXiv: 2603.14191v1 | PDF: PDF

英文摘要

YARA has established itself as the de facto standard for “Detection as Code,” enabling analysts and DevSecOps practitioners to define signatures for malware identification across the software supply chain. Despite its pervasive use, the open-source YARA ecosystem remains characterized by ad-hoc sharing and opaque quality. We conducted a large-scale mixed-method study of 8.4 million rules mined from 1,853 GitHub repositories. Our pipeline integrates repository mining to map supply chain dynamics, static analysis to assess syntactic quality, and dynamic benchmarking against 4,026 malware and 2,000 goodware samples. We reveal a highly centralized structure where 10 authors drive 80% of rule adoption. The ecosystem functions as a “static supply chain”: repositories show a median inactivity of 782 days and a median technical lag of 4.2 years. While static quality scores appear high (mean = 99.4/100), operational benchmarking uncovers significant noise (false positives) and low recall. Coverage is heavily biased toward legacy threats (Ransomware), leaving modern initial access vectors severely underrepresented.

中文摘要

解决的问题：YARA 是软件供应链中事实上的”检测即代码”标准，但其开源生态系统缺乏对结构特征、维护动态和操作可靠性的实证研究。从业者在没有质量证据的情况下依赖公开仓库。

方法：

  • 大规模混合方法研究：分析 1,853 个 GitHub 仓库中的 840 万条 YARA 规则
  • 仓库挖掘 → 映射供应链动态；静态分析 → 评估语法质量
  • 动态基准测试：用 4,026 个恶意软件和 2,000 个良性软件样本测量操作有效性

核心发现：

  • 高度集中化：10 位作者贡献了 80% 的规则采纳
  • “静态供应链”：仓库中位不活跃天数 782 天，技术滞后 4.2 年
  • 静态质量高但操作效果差：假阳性严重、召回率低
  • 覆盖偏向遗留威胁（勒索软件），现代攻击向量严重不足

与主人研究的相关性：高度相关 — 直接属于软件供应链安全领域，展示了开源安全工具生态系统的系统性问题（集中化、维护停滞、质量隐患），与主人的 package-dashboard 研究思路高度契合。

2. MALTA: Maintenance-Aware Technical Lag, Estimation to Address Software Abandonment

arXiv: 2603.10265v1 | PDF: PDF

英文摘要

Open-source ecosystems rely on sustained package maintenance. When maintenance slows or stops, Technical Lag (TL), the gap between installed and latest dependency versions accumulates, creating security and sustainability risks. However, existing TL metrics, such as Version Lag, struggle to distinguish between actively maintained and abandoned packages. We introduce MALTA, a scoring framework comprising three metrics: Development Activity Score (DAS), Maintainer Responsiveness Score (MRS), and Repository Metadata Viability Score (RMVS). We evaluate MALTA on 11,047 Debian packages linked to upstream GitHub repositories (1.7M commits, 4.2M PRs). MALTA achieves AUC = 0.783 for classifying active versus declining maintenance. Most significantly, 62.2% of packages classified as “Low Risk” by Version Lag alone are reclassified as “High Risk” when MALTA signals are incorporated.

中文摘要

解决的问题：当开源包维护放缓或停止时，技术滞后（Technical Lag）会累积，带来安全和可持续性风险。现有指标（如 Version Lag）无法区分活跃维护和已废弃的包，导致风险被系统性低估。

方法：

  • 提出 MALTA 评分框架，包含三个子指标：
    • DAS（开发活动评分）：基于提交和 PR 活动
    • MRS（维护者响应评分）：基于 issue/PR 响应时间
    • RMVS（仓库元数据活力评分）：基于仓库状态
  • 在 11,047 个 Debian 包（链接到上游 GitHub 仓库）上评估，涵盖 170 万次提交和 420 万个 PR

核心发现：

  • MALTA 分类活跃 vs 衰退维护的 AUC = 0.783
  • 关键发现：62.2% 被 Version Lag 标记为”低风险”的包，在 MALTA 信号下被重新分类为”高风险”
  • 这些包平均 2019 天没有提交，9.8% 的仓库已归档

与主人研究的相关性：高度相关 — 直接切入开源包维护风险度量，与主人在 package-dashboard 和 Python 依赖安全方面的研究完全对齐。提出的 MALTA 框架可直接应用于 Python/PyPI 生态的维护健康度分析。

3. VulnAgent-X: A Layered Agentic Framework for Repository-Level Vulnerability Detection

arXiv: 2603.13384v1 | PDF: PDF

英文摘要

Software vulnerability detection is critical in software engineering as security flaws arise from complex interactions across code structure, repository context, and runtime conditions. Existing methods are limited by local code views, one-shot prediction, and insufficient validation, reducing reliability in realistic repository-level settings. This study proposes VulnAgent-X, a layered agentic framework integrating lightweight risk screening, bounded context expansion, specialised analysis agents, selective dynamic verification, and evidence fusion into a unified pipeline. Experiments on function-level and just-in-time vulnerability benchmarks show VulnAgent-X outperforms static baselines, encoder-based models, and simpler agentic variants, with better localisation and balanced performance-cost trade-offs.

中文摘要

解决的问题：现有漏洞检测方法受限于局部代码视角、一次性预测和不足的验证，在仓库级别的真实场景中可靠性不足。安全漏洞来自代码结构、仓库上下文和运行时条件的复杂交互。

方法：

  • 分层智能体框架，包含五个阶段：
    1. 轻量级风险筛查 → 初步筛选高风险代码
    2. 有界上下文扩展 → 获取相关代码上下文
    3. 专用分析智能体 → 多角度漏洞分析
    4. 选择性动态验证 → 运行时验证
    5. 证据融合 → 综合多源证据做出判断
  • 在函数级和即时漏洞基准上评估

核心发现：

  • 超越静态基线、编码器模型和简单智能体变体
  • 更好的定位能力和更平衡的性能-成本权衡
  • 将漏洞检测视为分阶段、证据驱动的审计过程，减少了误报

与主人研究的相关性：高度相关 — 漏洞检测是软件供应链安全的核心环节。该工作将 AI Agent 用于仓库级漏洞检测，结合了 SE4AI 和供应链安全两个方向，与主人的研究画像高度重合。

4. ChainFuzzer: Greybox Fuzzing for Workflow-Level Multi-Tool Vulnerabilities in LLM Agents

arXiv: 2603.12614v1 | PDF: PDF

英文摘要

Tool-augmented LLM agents increasingly rely on multi-step, multi-tool workflows to complete real tasks. This design expands the attack surface, because data produced by one tool can be persisted and later reused as input to another tool, enabling exploitable source-to-sink dataflows that only emerge through tool composition. We present ChainFuzzer, a greybox framework for discovering and reproducing multi-tool vulnerabilities with auditable evidence. ChainFuzzer evaluates 20 popular open-source LLM agent apps (998 tools), extracts 2,388 candidate tool chains, synthesizes 2,213 stable prompts, and confirms 365 unique, reproducible vulnerabilities across 19/20 apps (302 require multi-tool execution). Overall, ChainFuzzer achieves 3.02 vulnerabilities per 1M tokens.

中文摘要

解决的问题：LLM Agent 越来越多地使用多步骤、多工具工作流完成任务。这种设计扩大了攻击面——一个工具产生的数据可能被持久化后作为另一个工具的输入，形成仅在工具组合时才会出现的可利用的 source-to-sink 数据流。现有的单工具测试无法发现这类长程行为。

方法：

  • 灰盒模糊测试框架，三步走：
    1. 工具链提取：识别高影响操作及其严格 source-to-sink 数据流，提取候选工具链
    2. Trace-guided Prompt Solving (TPS)：合成稳定提示词，可靠驱动 Agent 执行目标链
    3. 护栏感知模糊测试：通过 payload 变异和 sink 特定预言，在 LLM 护栏下复现漏洞

核心发现：

  • 测试 20 个流行开源 LLM Agent 应用（998 个工具），在 19/20 个应用中确认 365 个唯一可复现漏洞
  • 302 个漏洞需要多工具执行才能触发
  • TPS 将链可达性从 27.05% 提升到 95.45%
  • 护栏感知模糊测试将 payload 级触发率从 18.20% 提升到 88.60%

与主人研究的相关性：高度相关 — 这是 SE4AI 领域的前沿工作，针对 AI Agent 系统的安全测试，提出了系统性的漏洞发现方法。与主人关注的 AI Agent 测试和安全主题完美契合。

5. TOSSS: a CVE-based Software Security Benchmark for Large Language Models

arXiv: 2603.10969v2 | PDF: PDF

英文摘要

With their increasing capabilities, LLMs are now used across many industries. As LLMs are increasingly used in software development workflows, a critical question arises: are LLMs good at software security? We introduce TOSSS (Two-Option Secure Snippet Selection), a benchmark that measures the ability of LLMs to choose between secure and vulnerable code snippets. TOSSS relies on the CVE database and provides an extensible framework that can integrate newly disclosed vulnerabilities over time. We evaluate 14 widely used open-source and closed-source models on C/C++ and Java code and observe scores ranging from 0.48 to 0.89.

中文摘要

解决的问题：随着 LLM 被越来越多地集成到软件开发流程中，一个关键问题浮现：LLM 在软件安全方面表现如何？LLM 能否识别并选择安全的代码而非有漏洞的代码？

方法：

  • 提出 TOSSS（Two-Option Secure Snippet Selection）基准
  • 给模型一对代码片段（一个安全、一个有 CVE 漏洞），测试其选择安全版本的能力
  • 基于 CVE 数据库构建，可扩展到新披露的漏洞
  • 评分 0-1（1 = 总是选择安全版本）

核心发现：

  • 测试 14 个主流开源和闭源模型
  • C/C++ 和 Java 代码上的安全得分范围：0.48 到 0.89
  • 模型在安全代码识别方面表现参差不齐，最好也只有 89% 的准确率

与主人研究的相关性：中高度相关 — 这是 LLM 在软件安全领域的基准测试工作，与 SE4AI 方向直接相关。对主人研究 AI 辅助开发的安全性有参考价值。

6. To See is Not to Master: Teaching LLMs to Use Private Libraries for Code Generation

arXiv: 2603.15159v1 | PDF: PDF

英文摘要

Large Language Models (LLMs) have shown strong potential for code generation, yet they remain limited in private-library-oriented code generation. Existing approaches mainly rely on retrieving private-library API documentation and injecting relevant knowledge into the context at inference time. However, our study shows that this is insufficient: even given accurate required knowledge, LLMs still struggle to invoke private-library APIs effectively. We propose PriCoder, an approach that teaches LLMs to invoke private-library APIs through automatically synthesized data. PriCoder models private-library data synthesis as graph construction, alternating between Progressive Graph Evolution and Multidimensional Graph Pruning. Experiments on three mainstream LLMs show gains of over 20% in pass@1 in many settings.

中文摘要

解决的问题：LLM 在使用私有库 API 生成代码方面表现不佳。即使在推理时注入了准确的 API 文档，LLM 仍然难以有效调用私有库 API。这在实际开发中很常见——企业内部库、新发布的开源库都属于模型训练时没见过的私有库。

方法：

  • 提出 PriCoder 方法，通过自动合成数据来教 LLM 使用私有库 API
  • 将数据合构建模为图的构建，交替使用两个图操作符：
    1. 渐进式图演化：逐步合成更多样化的训练样本
    2. 多维图剪枝：通过严格过滤管道提升数据质量
  • 构建两个基于最近发布库的新基准

核心发现：

  • 在三个主流 LLM 上，pass@1 提升超过 20%
  • 对通用代码生成能力影响可忽略

与主人研究的相关性：中度相关 — 虽然主要关注代码生成，但涉及 Python 私有库生态和包管理问题。对于理解 LLM 如何处理新的/私有的包依赖有参考价值，与 Python 生态研究间接相关。

7. The Impact of AI-Assisted Development on Software Security: A Study of Gemini and Developer Experience

arXiv: 2603.15298v1 | PDF: PDF

英文摘要

The ongoing shortage of skilled developers, particularly in security-critical software development, has led organizations to increasingly adopt AI-powered development tools. However, it remains unclear how developers’ general programming and security-specific experience, and the type of AI tool used (free vs. paid) affect the security of the resulting software. We conducted a quantitative programming study with software developers (n=159) exploring the impact of Google’s AI tool Gemini on code security. While we did not observe significant differences between using Gemini in terms of secure software development, programming experience significantly improved code security and cannot be fully substituted by Gemini.

中文摘要

解决的问题：AI 辅助开发工具被广泛采用以提升生产力，但开发者的编程经验和安全经验、以及 AI 工具类型（免费 vs 付费）如何影响最终代码的安全性，尚不清楚。

方法：

  • 定量编程实验，n=159 名软件开发者
  • 三组对照：不使用 AI、使用 Gemini 免费版、使用 Gemini 付费版
  • 分配安全相关编程任务，评估代码安全性

核心发现：

  • 未观察到使用 Gemini 在安全软件开发方面的显著差异
  • 编程经验显著提高代码安全性，不能被 Gemini 完全替代
  • 付费版 vs 免费版无显著差异

与主人研究的相关性：中度相关 — 属于 SE4AI 领域，直接评估 AI 工具对代码安全的影响。对理解 AI 辅助开发的安全局限性有参考价值，但方法相对简单。

📊 本期总结

#论文方向相关度
1YARA Ecosystem Mining供应链安全⭐⭐⭐⭐⭐
2MALTA开源维护风险⭐⭐⭐⭐⭐
3VulnAgent-X漏洞检测 + AI Agent⭐⭐⭐⭐⭐
4ChainFuzzerLLM Agent 安全测试⭐⭐⭐⭐⭐
5TOSSSLLM 代码安全基准⭐⭐⭐⭐
6PriCoder私有库代码生成⭐⭐⭐
7Gemini & SecuritySE4AI 安全影响⭐⭐⭐

本期亮点：

  • 🔥 供应链安全方向论文质量很高，YARA 生态系统的大规模实证研究和 MALTA 的包维护风险框架都与主人研究直接相关
  • 🔥 AI Agent 安全成为热门话题，ChainFuzzer 和 VulnAgent-X 分别从模糊测试和分层检测角度切入
  • 📈 LLM 安全基准受到关注，TOSSS 基于 CVE 数据库的设计有较好的扩展性

自动生成于 2026-03-17 18:33 (Asia/Shanghai) | 数据来源：arXiv cs.SE