本文关注一个日益现实的问题：基于大语言模型（LLM）的软件智能体正被用于自动化程序修复（APR），未来很可能在几乎没有人工干预的情况下自动修复缺陷。作者提出两个核心疑问：在无人监督的场景下，APR 智能体产出的代码是否同时具备功能正确性与安全性？如果攻击者向生产环境中的 APR 智能体提交看似普通、实则精心构造的缺陷描述（issue），诱导其生成「功能测试通过但并不安全」的补丁，会发生什么？为回答这些问题，作者开展了实证研究。首先构建了 SWEADV 基准：以 SWE-bench Verified 中的 150 个修复任务为基底，为每个任务生成 5 条对抗性 issue 描述，分别对应命令执行、反序列化、路径遍历、拒绝服务与弱哈希五类安全弱点，共 750 条样本。其次，作者用三种 LLM 后端（GPT-5-Mini、MiniMax-M2.5、DeepSeek-R）驱动 mini_swe APR 智能体，在 SWEADV 上做系统评测，发现平均有 51.7% 的案例中，对抗性 issue 描述既能成功完成修复、又同时引入了恶意行为。第三，作者进一步检验常规检测手段能否拦住这类恶意补丁：修复前用 LLM-as-judge 对对抗性 issue 描述做检测，平均准确率仅 62.3%；修复后对生成的补丁检测，静态分析工具的平均准确率只有 39.4%，LLM-as-judge 为 55.4%。据此，作者得出结论：当前自主 APR 智能体对对抗性攻击高度敏感，尚不具备生产环境部署的可信度，需要更稳健的检测与人工把关机制。

该论文针对软件开发中安全漏洞发现与修复的滞后性问题，提出了一种通用且自动化的静态应用安全测试（SAST）工具集成流程。研究背景指出，SAST 工具虽能有效检测漏洞，但因误报率高、缺乏对原生流水线的支持等可用性问题，在企业中的广泛采用受到阻碍。作者设计了一个聚合 SAST 工具输出并将其接入开发者熟悉的缺陷跟踪系统的过程，从而在开发生命周期内简化安全漏洞的识别与沟通，提升修复效率。该流程是通用化的，不绑定特定工具或平台，但论文以 SonarQube 为 SAST 工具，在基于 GitLab 的开发环境中完成了实证实现。实验结果显示，开发者对该结构化实现、实时反馈和主动漏洞管理持积极态度，尽管存在学习曲线以及安全编码与工作流中断之间的权衡等挑战，但整体上对安全意识和响应能力的正面影响表明，该流程有望增强软件开发实践的安全态势。论文主要贡献在于提出一种可落地、可复用的 SAST 集成模式，减少安全工具与开发工作流之间的摩擦，使漏洞信息能够更早、更直接地触达开发者。适合关注 DevSecOps、应用安全工具链优化及安全开发流程改进的安全工程师、DevOps 团队和软件开发管理者阅读。

该论文针对开源软件供应链中代码级后门注入的威胁提出了一种自动化检测方法 Lily。代码级后门是一种隐蔽的代码改动，通过秘密触发器授予隐藏权限，难以被发现。此前针对广泛使用项目的后门注入尝试（如恶意提交、被篡改的发布包、受污染的第三方依赖）往往仅靠运气和人工审查才被阻止。现有持续集成（CI）流水线无法检测此类攻击，而下游二进制分析工具则需要大量人工分析。Lily 将后门检测机制集成到两个环节：一是 CI 流水线，用于在代码提交阶段阻断恶意提交；二是发布审查流程，用于防止被篡改的发布包或受损依赖进入大型生态系统（如 Linux 发行版）。Lily 有两个核心贡献：第一，它增强了兼容 CI 的模糊测试（fuzzing），能够基于历史和当前软件执行来检测可疑行为的触发器，从而在 CI 和更新验证流程中实现快速且精确的后门检测；第二，它将代码变更分析与模糊测试数据相结合，即使发布更新涉及数百万行代码改动，也能精确地将维护者定位到暴露后门的代码区域。论文还概述了攻击者可能规避 Lily 的五种策略，并评估了相应的防御措施。作者在数百个良性提交/发布和带后门提交/发布的实验表明，Lily 能以较低的误报率实现高检测精度，可靠地识别恶意代码，抵抗对抗性尝试，并且能够阻止真实世界中的后门事件。