该论文提出并量化了「静态通过、动态失败」（Static-Pass Dynamic-Fail, SPDF）现象：代码通过了静态安全扫描，但在真实运行时仍可被利用。作者指出，静态分析因可扩展、可复现、成本低，被广泛当作软件供应链与 AI 生成代码的安全闸门，但它无法直接观察运行时的利用行为；那些依赖对抗性输入、执行上下文或漏洞链式组合才能触发的缺陷，往往能绕过静态检查而在实践中仍具可利用性。然而业界普遍把「静态扫描通过」等同于「行为安全」，这正是论文试图挑战的假设。为验证这一问题，作者构建了一个三阶段智能体流水线：第一阶段用 Bandit 与 Semgrep 组成的复合静态闸门做初筛；第二阶段由 LLM 驱动的 CWE（通用弱点枚举）推理，对静态无告警的样本重新审视，判断是否存在候选弱点；第三阶段在隔离的 Docker 容器中执行自主可利用性验证，以获得运行时证据。实验覆盖 SecurityEval、RedCode 与 CyberNative 三个数据集的 1355 份 Python 样本。在 654 份复合静态闸门零告警的样本中，LLM 阶段在 235 个文件中识别出 394 个候选漏洞；动态验证在 95 个文件中确认或部分确认了可利用性，得到 14.53% 的「包含式流水线比率」——即约每 7 份静态干净样本中就有 1 份被流水线发现候选弱点并获得运行时利用证据。分数据集看，候选「文件—CWE」对中的确认率差异明显：RedCode 为 33.7%，CyberNative 为 28.6%，SecurityEval 仅 5.4%。值得注意的是，包括 CWE-338（弱伪随机数）与 CWE-916（口令哈希计算量不足）在内的若干高频确认类别，Bandit 与 Semgrep 均未告警。作者由此论证：静态分析通过率与运行时安全性并非可互相替代的同一度量，而是软件保障体系中不同层级的指标。

该论文针对 GitHub Copilot 这一人工智能代码补全工具所生成代码的安全性进行了系统评估。研究动机在于，随着开发者越来越多地使用大语言模型（LLM）辅助编写代码，其输出可能隐含安全漏洞，而开发者往往因信任或疏忽而直接采用。作者构建了一个包含常见漏洞场景（如缓冲区溢出、SQL注入、命令注入等）的基准测试集，通过向 Copilot 输入相关提示，分析其生成的代码中是否包含可被利用的弱点。实验在多种编程语言和风险场景下展开，重点考察了提示的措辞、上下文、开发者意图等因素对生成结果安全性的影响。研究发现，Copilot 在大约 40% 的情况下会生成易受攻击的代码，且在某些安全关键的上下文中（例如使用不安全函数时）失败率更高；同时，生成代码的漏洞类型与 CWE（常见弱点枚举）能够对应。论文还探讨了开发者过度信任此类工具的风险，并讨论了简单的缓解措施（如安全感知的提示工程）对降低漏洞率的有限效果。该工作为 AI 辅助编程的安全影响提供了实证基础，对安全研究者、AI 模型开发者以及广泛使用 Copilot 的软件工程团队均有参考价值。

本文针对大型语言模型（LLM）从自然语言提示生成代码时，提示工程如何影响生成软件安全性的问题展开实证研究。现有观点认为结构化、面向安全的提示可以促使模型生成更安全的代码，但作者指出，其影响不能仅通过检测到的弱点是否存在来衡量。为此，研究者使用424个安全敏感的Python任务，采用五种逐渐增加结构和安全指导的提示变体，分别驱动GPT-4o和LLaMA 3.1-8B生成解决方案，并利用Bandit和CodeQL两个静态分析工具，从生成合规性、安全弱点普遍性、严重程度及CWE分布等多个维度进行评估。实验结果显示：结构化提示显著降低了模型的拒绝输出率（例如，GPT-4o的无效输出从424次中的338次降至37-52次），从而使得大规模分析成为可能；然而，安全导向的提示优化并不能一致地减少总体弱点数量。对于GPT-4o，更强的提示主要导致风险重新分布：高严重性发现的比例从20.8%降至13.6%，而低严重性发现的比例从32%升至43.5%；LLaMA模型则表现出较弱且不一致的变化。研究还观察到安全驱动的语义漂移现象，即更严格的提示会静默地移除或重写原本明确要求的、不安全的构造。总体而言，提示结构改善了合规性，但并不能替代LLM辅助开发中稳健的安全控制。该研究揭示了提示工程对代码安全影响的细微之处，提示安全从业者不能依赖提示词来保证生成代码的安全性，而应结合其他安全措施。适合LLM安全研究人员、软件工程安全实践者以及依赖AI辅助编码的开发者阅读。

该研究聚焦于静态应用安全测试（SAST）工具在发现 Web 应用漏洞时受到代码风格影响的问题。尽管 SAST 工具被广泛使用，但已知其存在诸多局限性，而编码风格对漏洞检测能力的影响此前鲜有系统研究。作者通过组合商业与开源的多种安全扫描器，对 PHP 和 JavaScript 代码进行了大规模实验，归纳出超过 270 种会阻碍现有工具分析的代码模式。这些模式被定义为“可测试性陷阱”（Testability Tarpits），即当代码中出现这些模式时，SAST 工具的分析能力会显著下降，可能导致漏报。基于这一发现，作者提出了一种在软件开发生命周期中识别这些模式的方法，从而向开发者提供关于代码可测试性的重要反馈。该方法不仅帮助开发者了解代码被静态分析的有效程度，还能辅助评估残余风险：即使静态分析器未报告任何发现，代码中仍可能隐藏漏洞。此外，文章还探讨了通过代码转换来提升代码对 SAST 工具的友好度，为增强安全测试效果提供了可行路径。该研究的核心贡献在于首次系统性地量化了代码模式对 SAST 检测能力的影响，并构建了模式清单，为提升 Web 应用安全测试的准确性和覆盖率提供了新的视角。适合安全研究人员、SAST 工具开发者和应用安全工程师阅读。

本文针对 AI 辅助开发工具生成代码中普遍存在安全漏洞、却缺乏在开发速度下自动检测、富化、修复和验证安全问题的机制这一痛点, 提出并评估了一套即时 (Just-in-Time) 漏洞检测与修复流水线。该流水线由多个阶段组成: 首先从 LLMSecEval 提示集生成 Python 代码; 然后并行使用 CodeQL 与 Bandit 进行静态扫描, 同时引入一个独立的 Code Validator LLM 进行漏洞检测; 随后将 Code Validator 的发现结果与 MITRE ATT&CK 技术、CWE 观察示例以及 Python 最佳实践指南进行富化; 接着由 Code Generation LLM 依据富化后的发现生成修复代码; 最后再次使用 CodeQL 和 Bandit 重新扫描以验证修复效果。论文评估了两种流水线配置: P1 仅使用富化后的 Code Validator 发现, P2 额外加入初始 CodeQL 与 Bandit 发现。实验在四个 Claude 模型 (Opus 4.8、Sonnet 4.6、Sonnet 5、Haiku 4.5) 上运行, 共对 26 个 LLMSecEval 提示对应的代码进行了 80 次完整流水线测试, 覆盖 9 类 CWE。结果显示, P1 在所有四个模型上都减少了静态分析器发现, 减少幅度从 -9% (Opus 4.8) 到 -54% (Sonnet 5); P2 进一步加深了减少幅度, 从 -29% (Opus 4.8) 到 -69% (Haiku 4.5), 且每个模型上 P2 均优于 P1。裁决一致性平均约为 81% 模态一致性, P2 略更稳定。修复过程在 15%-22% 的案例中引入了新漏洞, 其中约 70% 涉及单一新发现; 对四个模型中的三个, P2 降低了修复副作用, Sonnet 5 是唯一例外。值得注意的是, 最好的代码生成 LLM (Opus 4.8) 并不是最佳的流水线表现者, 在 P2 修复后, Sonnet 4.6 产生了最低的残留发现和最高的通过率, 这表明流水线整体有效性与首稿安全性是两个独立的属性。该研究为构建可落地的 AI 代码安全自动化管道提供了系统性证据, 对安全研究人员、开发工具链设计者以及希望在开发流程中嵌入代码安全验证的蓝队工程团队具有参考价值。

该研究针对AI编码代理生成代码的安全审查瓶颈问题展开。随着AI编码代理在生产环境中生成越来越多代码，人工安全审查的速度难以匹配代码生成速度。对于广泛使用的闭源权重模型，部署团队无法读取其内部结构，但可以使用开源权重模型作为代理输出的审查器，而该审查器的激活值是可读取的。研究者提出疑问：读取这些激活值是否能恢复仅向同一审查器提问所遗漏的安全信号。为此，他们对五个开源权重审查模型，在由成对的脆弱与修复后Python函数组成的语料上，为每个模型拟合了一个线性探针（linear probe），然后在训练中从未见过该弱点类型的真实公开漏洞上测试该探针，无需重新训练。实验结果显示，在通过更改单个函数修复的漏洞上，探针将脆弱函数排在修复后函数之上的比例在所有模型上均达到61%-67%，明显超过50%的随机水平。同时，该探针性能也优于同一模型通过其logits读取的YES/NO提示赢率，且在尝试的所有提示下均如此。而要求模型给出书面判断，即使使用思维链，在大多数情况下对脆弱函数和修复后函数返回相同答案，因此无法区分两者。最终结论是，模型激活中承载着仅通过提示同一模型无法获得的安全信息。该研究为利用模型内部激活进行代码安全信号检测提供了新思路和实证依据。适合关注LLM安全、AI代理安全及代码审查自动化领域的研究人员和安全工程师阅读。

大型语言模型（LLM）在代码生成任务中广泛应用，但其输出常存在安全漏洞。现有研究通过提示工程（prompt engineering）来降低风险，但存在两个局限：一是大多关注高层次提示策略，忽视了细粒度句法变体对模型行为的显著影响；二是主要评估闭源模型，限制了结果在工业环境中的适用性（工业界更偏好自托管开源模型以保护隐私、合规和部署控制）。本文聚焦于提示的句法成分如何影响开源LLM生成代码的安全性。作者提出一种基于解析器（parser-driven）的方法，系统性地生成安全相关代码生成提示的句法变体，并在多个开源LLM和编程语言上评估其对代码安全性的影响。实验结果表明，特定的句法元素（如约束、防护、条件、概念绑定）及其在提示中的位置一致地影响生成不安全代码的可能性。这些发现将提示句法视为具体的安全控制面，并为降低LLM辅助开发中的漏洞风险提供了可操作指导。

本文研究了大型语言模型（LLM）在代码安全漏洞检测中的路由天花板现象。作者基于先前的数学推理研究（SAIR）假设，将结构先验（即“小抄”）注入提示词，以提升模型在特定分布下的漏洞检测能力。实验使用了三个LLM（GPT-OSS-120B、Llama-3.3-70B、Gemma-4-31B），覆盖三种漏洞类型（CWE-798、CWE-284及非CWE的N+1反模式），分别代表句法、语境和语义复杂度。在合成数据集上，结构先验将语义漏洞召回率从20.0%提升至100.0%，但零样本性能随语义复杂度增加而下降。当将相同的小抄迁移至真实世界CVE数据集（VUDENC中的CWE-89和CWE-22）时，分布转移导致性能急剧下降：CWE-89的合成F1从100%降至48.9%（下降51.1个百分点）。迭代校准生成的v2小抄在真实数据上表现更差，进一步验证了SAIR中的性能权衡面。这些发现表明路由假设具有跨域普适性：模型具备解决任务的知识，但缺乏可靠的路由机制；结构先验虽能放大分布内性能，但会加剧分布外崩溃。作者主张应开发分布感知的训练方法，而非仅靠提示校准。论文代码已公开。

大型语言模型（LLM）生成的代码经常包含安全漏洞，且这些漏洞往往不是孤立的，而是跨多个关注领域同时出现，反映了软件安全中的横切性质。本文提出一个框架，将安全导向的蜕变关系（MR）与关联规则（AR）挖掘相结合，用于检测LLM生成代码中的漏洞，揭示其违反结构，并将该结构追溯到提示层面的风险因素。作者定义了覆盖主要CWE类别的九种MR，包括SQL注入、XSS、命令注入、路径遍历、硬编码凭证、弱密码学以及内存安全错误，并使用基于LLM的评判器对LLMSecEval基准测试中五个开源模型生成的3700个代码片段进行了评估。结果显示，68.8%的片段至少违反了一个MR，其中硬编码凭证（79.1%）和命令注入（74.4%）是最普遍的适用故障。AR挖掘揭示了强横切共违反模式：XSS和弱密码学共违反以82.5%置信度（提升度=3.23）预测硬编码凭证，并且存在紧密耦合的簇，连接认证、凭证处理和密码学弱点，以及输入处理和内存安全故障。随后进行的提示层面风险分析发现，与数据库和认证相关的提示是广泛横切不安全性的强预测因子，而65.5%的提示在五个模型上产生一致的违反结果。这些发现表明，不安全代码生成不仅是一组独立的缺陷，而是一个结构化的、由提示决定的现象，这促使采用簇感知验证和提示层面干预来实现更安全的LLM辅助编程。

该论文提出了一个名为 SV-TRUSTEVAL-C 的基准测试，用于评估大语言模型（LLM）在 C 语言源代码漏洞分析中的结构推理和语义推理能力。结构推理评估模型在不同数据流和控制流复杂度下识别代码元素间关系的能力；语义推理则检验模型在代码结构或语义发生扰动时保持逻辑一致性的能力。实验结果表明，当前 LLM 在理解复杂代码关系方面远未达到令人满意的水平，其漏洞分析更多依赖模式匹配而非稳健的逻辑推理。该基准测试揭示了 LLM 在代码安全分析中的关键弱点，并为提升其推理能力和可信度提供了重要参考。初始数据集已在 Hugging Face 公开。

本文研究了大语言模型（LLM）内部如何识别恶意代码的机制。尽管LLM在代码补全、漏洞检测等软件工程任务中表现优异，但其识别恶意或漏洞代码的内部工作机制仍不透明。作者采用机械可解释性方法，对三个指令微调的LLM（Llama3.1-8B-Instruct、Mistral-v0.3-7B-Instruct和Qwen2.5-7B-Instruct）进行了分析，利用PyPI Malregistry中的1500个恶意包和1500个良性包进行探测。实验首先通过线性探针定位前馈网络（FFN）中与恶意代码检测相关的神经元，然后通过因果干预（放大或抑制这些神经元）验证其作用。结果表明，放大促进恶意检测的神经元并抑制抑制性神经元可以提高分类准确率，而反向操作则会导致预测向单一类别崩溃，但该效果强烈依赖于具体模型。不同模型的护栏检测机制存在差异，其恶意代码检测行为在FFN层中的编码方式各不相同。该研究揭示了LLM编码恶意编程概念的方式，为神经元层级编辑、选择性遗忘和安全对齐等更可靠的防御机制奠定了基础。适合对LLM安全、可解释性和代码安全感兴趣的研究者阅读。

本文提出 CodeTracer，一个面向大语言模型代码补全系统中后门攻击的取证框架。背景是：代码补全系统（如 Copilot）依赖大型语言模型，但模型可能通过恶意微调数据被植入后门，导致生成恶意代码。现有防御技术难以检测和缓解自适应后门攻击。CodeTracer 在真实部署约束下（仅依赖微调语料库和报告的错误补全事件）运行，从受攻击输出中提取结构化行为指纹，将搜索范围缩小至语义相关的代码样本，并利用基于 LLM 的推理将不安全逻辑归因到特定的后门数据。在三个代表性漏洞场景和十种后门攻击、十六个竞争基线上的广泛评估表明，CodeTracer 持续达到高取证准确率、低误识别率，并对自适应攻击具有强鲁棒性。该方法不直接防御后门，而是帮助安全团队定位攻击根源，为后续清洗训练数据提供依据。

本文研究了一种名为“abliteration”的低秩权重编辑方法，用于解除代码大语言模型（LLM）在生成指定漏洞代码时的安全对齐拒绝行为。在基于学习的安全漏洞检测任务中，大规模有标注漏洞代码数据集的构建一直面临标签噪声问题，现有的LLM增强方法往往只是变换已有的漏洞种子，而非根据规范合成漏洞，导致标注不准确。因此，作者提出从安全代码出发，利用指令调优的LLM注入特定CWE（如CWE-89 SQL注入），但安全对齐的代码LLM通常会拒绝此类请求。Abliteration方法通过对模型残差流中的拒绝方向进行正交投影，实现在不显著影响代码生成能力的前提下消除拒绝行为。实验以Python和CWE-89为案例，评估了Qwen2.5-Coder-Instruct系列（3B、7B、14B参数）在PromSec和SafeCoder两个安全代码数据集上的表现，每种条件重复三次。结果显示：（i）拒绝行为与模型大小和提示上下文高度相关：14B模型拒绝100%的注入提示，7B在PromSec上拒绝73%但在SafeCoder上仅拒绝5%，而3B几乎从不拒绝；（ii）Abliteration将拒绝率降至零或接近零，同时保持语法有效性超过93%，表明在该设置下拒绝可以与代码生成能力分离；（iii）注入后的漏洞注入率受限于模型能力：14B达到88-97%，7B达到89-90%，3B仅25-48%，从而区分了“意愿”（通过abliteration实现）与“能力”（随参数规模增长）。漏洞判定通过CodeQL、Semgrep、Bandit三个工具的集成检测器以及两位作者对检测器阳性结果的人工裁决完成。本研究属于初步可行性探索，作者认为abliteration有望为漏洞数据集的规模化构建提供新途径，但同时也警示了潜在的安全风险。