本文针对大型语言模型（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辅助编码的开发者阅读。

本文评估了大型语言模型（LLM）在自动生成安全认证代码方面的能力。研究选取了五种主流AI编码助手，通过双模态评估框架（静态代码分析结合动态渗透测试）并参照NIST SP 800-63B指南，分析了四种提示策略（基础、安全、NIST引导、迭代重提示）下生成的认证系统安全性。实验结果表明，仅使用功能性或通用安全提示生成的代码普遍缺少关键保护机制，尤其是在暴力破解防御、会话管理和密码健壮性方面。即使加入显式的NIST上下文单次提示，合规性虽有提升但架构上仍不充分。唯有采用迭代重提示（Reprompting）策略，即强制模型进入上下文自我审计循环，才能实现纵深防御的安全架构。最终结论是当前AI编码助手无法默认生成安全应用，企业部署必须从单次提示工程转向持续、标准驱动的验证流程。该研究揭示了LLM辅助编码中普遍存在的安全幻觉，并提出了可操作的改进方向。

本论文聚焦于大型语言模型（LLM）在代码生成中的安全性问题，指出现有基准测试往往依赖明确指定的安全需求，无法覆盖真实开发中提示词模糊或不完整的场景。作者从开发者视角出发，识别出三类典型风险场景：模糊需求（Ambiguous Requirements）、未充分指定的操作上下文（Under-Specified Operational Context）以及安全-功能冲突（Security-Functionality Conflict）。基于这些场景，构建了一个包含2700个测试用例的大规模基准，用于细粒度评估LLM在真实条件下的安全性。对八款最新LLM的广泛评估显示，所有模型在风险场景下的平均漏洞率超过56%。进一步研究发现，安全感知的提示（security-aware prompting）可以显著降低这些风险，提升幅度高达45%。该工作为LLM代码生成的安全评估提供了更贴近实际的测试框架，并证明了简单提示工程对缓解安全问题的有效性。

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

大型语言模型（LLM）在生成代码时频繁引入可利用的安全缺陷。现有防御方法通常依赖繁重的微调或外部知识检索，带来显著的计算开销和冗余代码示例导致的数据偏差。本文提出一种相反观点：预训练语料库中已包含丰富的安全知识，缺陷在于激活不足——缺乏明确、简洁的提示时，模型倾向于遵循训练分布中的常见模式，抑制了安全相关表征。为此，作者提出 SPARK，一个无需重新训练的推理时安全皮套，包含两个组件：组件 I 为每个编码任务检索相关的通用弱点枚举（CWE）条目，并将简短的结构化提示附加到 prompt 中，仅此即可激活模型已有的安全表征；组件 II 在每一步解码时向 logits 添加预计算的 token 偏置——该偏置通过对安全方向向量（平均安全隐藏状态与平均不安全隐藏状态之差）投影到语言模型头部获得，离线计算一次，推理时每生成一个 token 仅需一次向量加法。SPARK 在 C++、Java 和 Python 上对 9 个开源模型进行评测，与 7 个基线（包括微调和检索增强方法）对比，在所有设置中匹配或超越最佳基线，同时保持 HumanEval 代码功能正确性。此外，还在黑盒环境下对 7 个最强闭源模型（包括 Claude、DeepSeek 和 GPT）测试组件 I，证实了不安全代码生成的瓶颈以及本方法带来的改进。该工作表明，通过轻量级推理时干预激活 LLM 内生的安全知识，可以高效提升代码安全性，为安全代码生成提供了新范式。

现有针对语言模型在恶意代码生成任务上的拒绝行为评测基准，常常将“请求生成可执行恶意软件”与“请求有害安全知识”混为一谈。这种混淆会导致两种请求类型在安全对齐模型中触发不同的拒绝路径，而基于混合提示计算出的单一拒绝率无法单独衡量任何一类。本文引入了一个“武器”与“知识”的分类轴，并通过一个五模型共识协议将其操作化。作者从四个公开基准中提取了3,133条提示，利用五个大语言模型裁判（来自Anthropic、OpenAI、Google、智谱AI、阿里巴巴四家厂商）进行三个投票过半数判决，最终得到1,554条共识为“武器”（CODE）的提示库（主要发布成果），以及388条共识为“知识”（KNOWLEDGE）的比较集。整个流程的裁判间信度由Fleiss' Kappa衡量，在3,133条提示上达到0.876（95%置信区间[0.862,0.888]），属于Landis & Koch标准中的“几乎完全一致”，其中69.3%的提示为五裁判全票一致。所有3,133条提示均满足了3/5多数阈值，因此共识流程未产生任何模糊排除的提示。本文的贡献在于提供了信度有据可查的标注数据集，并论证了“武器”与“知识”区分作为代码安全评测组织轴的重要性，而该分类轴能否实际分离模型行为则留给配套的基准论文去验证。对于安全从业者而言，该数据集可用于评估自家LLM在恶意代码生成场景下的拒绝行为，避免将安全知识请求误判为武器生成请求。