#prompt-engineering

共收录 5 条相关安全情报。

← 返回所有主题
👥 作者: Ishpuneet Singh, Shreyas Mahajan, Gurjot Singh, Maninder Singh

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

💡 推荐理由: 该研究首次系统性地揭示了主流AI编码助手在生成安全认证代码时的结构性缺陷,证明单次安全提示不足以保障代码安全,为依赖LLM辅助开发的团队提供了关键警示和可落地的迭代重提示方案。

🎯 建议动作: 研究跟进,建议安全团队评估内部使用的AI编码助手,并尝试将迭代重提示策略纳入代码审查流程。

排序因子: 来自 arXiv 其他板块 (+2) | 命中热门研究主题 (+2) | Community 数据源 (+1) | LLM 评分加成 (+0.5)
👥 作者: Lixun Ma, Ruolong Ma, Bei Wang, Feng Wei, Zhenguang Liu, Lorenzo Cavallaro, Wentao Chen

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

💡 推荐理由: 该研究揭示了LLM代码生成在真实开发场景中的高漏洞率,并提供了可操作的缓解方向,对依赖LLM开发的安全团队具有重要参考价值。

🎯 建议动作: 研究跟进

排序因子: 来自 arXiv 其他板块 (+2) | 命中热门研究主题 (+2) | Community 数据源 (+1) | LLM 评分加成 (+0.5)
👥 作者: Matteo Cicalese, Antonio Della Porta, Stefano Lambiase, Emanuele Iannone, Torge Hinrichs, Riccardo Scandariato, Fabio Palomba

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

💡 推荐理由: 揭示了提示的细粒度句法结构是影响LLM生成代码安全性的关键控制面,为开源LLM在工业安全实践中的使用提供了可量化的改进方向。

🎯 建议动作: 研究跟进

排序因子: 来自 arXiv 其他板块 (+2) | 命中热门研究主题 (+2) | Community 数据源 (+1) | LLM 评分加成 (+0.6)
👥 作者: Xiaoyun Xu, Lichao Wu, Jona te Lintelo, Siyu Zhang, Stjepan Picek

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

💡 推荐理由: 本工作揭示了LLM安全代码生成的核心瓶颈在于知识激活而非知识缺失,提出的轻量推理时方法无需重训练即可显著提升代码安全性,对安全开发流程和LLM安全研究具有重要启发。

🎯 建议动作: 研究跟进

排序因子: 影响边界/网络设备 (+5) | 来自 arXiv 其他板块 (+2) | 命中热门研究主题 (+2) | Community 数据源 (+1) | LLM 评分加成 (+0.6)
👥 作者: Richard J. Young, Gregory D. Moody

现有针对语言模型在恶意代码生成任务上的拒绝行为评测基准,常常将“请求生成可执行恶意软件”与“请求有害安全知识”混为一谈。这种混淆会导致两种请求类型在安全对齐模型中触发不同的拒绝路径,而基于混合提示计算出的单一拒绝率无法单独衡量任何一类。本文引入了一个“武器”与“知识”的分类轴,并通过一个五模型共识协议将其操作化。作者从四个公开基准中提取了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在恶意代码生成场景下的拒绝行为,避免将安全知识请求误判为武器生成请求。

💡 推荐理由: 本文提供了一个经过严格共识标注的提示库,能帮助安全团队精确区分LLM是生成恶意代码还是提供安全知识,从而更准确地评估和修补模型的安全拒绝机制。

🎯 建议动作: 研究跟进

排序因子: 影响边界/网络设备 (+5) | 来自 arXiv 其他板块 (+2) | Community 数据源 (+1) | LLM 评分加成 (+0.5)