跳转至

Purple Llama CyberSecEval Note

Purple Llama CyberSecEval: A Secure Coding Benchmark for Language Models 论文结构与方法解析

论文章节结构#

  1. Introduction（引言） – 介绍大型语言模型（LLM）在代码生成中的安全风险背景，并指出本文关注的两个主要网络安全风险：LLM 生成不安全代码的倾向，以及在恶意攻击请求下的服从情况。作者概述了 CyberSecEval 基准的整体方法和贡献，强调其是目前最全面的网络安全评测套件之一。

  2. Insecure coding practice testing（不安全编码实践测试） – 描述如何评估 LLM 建议不安全编码实践的频率。这一章节介绍了针对代码补全（autocomplete）和指令生成（instruct）两种情境的测试集构建方法，以及使用静态分析工具检测生成代码中的不安全模式等流程。作者提供了图1作为该部分方法的概览，并在后续小节详细说明。

  3. Cyberattack helpfulness testing（网络攻击协助测试） – 描述如何评估 LLM 在恶意网络攻击请求下提供协助的倾向。该部分基于业界标准的 MITRE ATT\&CK® 框架，构建了一系列请求模型帮助实施网络攻击的测试用例，并采用自动化判别方法评估模型的响应是否有助于攻击。

  4. Related Work（相关工作） – 回顾现有的 LLM 代码安全基准和研究。包括 Pearce 等人（2022）的早期工作（使用手工编写的25个 CWE 提示）以及后续扩展到更多漏洞类型和模型的研究。作者对比了 CyberSecEval 与这些工作的区别，指出本基准在支持的编程语言、自动化程度和评估维度上的扩展和改进。

  5. Limitations of CyberSecEval（基准的局限） – 列举 CyberSecEval 方法和设计中的主要假设与权衡。指出不安全代码检测可能存在误报漏报（静态分析方法的局限）、测试集中可能存在数据泄漏风险（模型训练数据包含测试代码）及目前仅支持英文提示、单轮对话等限制。

  6. Running CyberSecEval（基准使用指南） – 提供在开源 GitHub 仓库中运行 CyberSecEval 基准的说明。作者公开了完整的代码、测试用例和文档，读者可据此复现评测并对模型进行安全测试，并鼓励社区贡献改进。

  7. Conclusion（结论） – 总结 CyberSecEval 基准的贡献和实验发现，强调持续研究 LLM 安全性的必要性。作者重申本基准覆盖广泛的安全评估场景，并通过对 Llama 2、Code Llama 以及 OpenAI GPT 系列模型的案例分析，发现更强大的模型往往更可能产生不安全代码（平均有约30%的代码建议存在漏洞）且在约一半情况下会顺从恶意请求。这一结果凸显了在先进 LLM 开发中纳入安全考虑的迫切性。

Benchmark 构建方法#

测试语料来源与生成： CyberSecEval 基准包含两个部分：（1）不安全编码实践测试集，从真实世界开源代码库自动提取；（2）网络攻击协助测试集，由安全专家手工设计并经 LLM 扩充。第一个测试集利用作者开发的“不安全代码检测器（Insecure Code Detector, ICD）”在大型开源代码语料中搜索不安全编码实例。ICD 基于 Common Weakness Enumeration (CWE) 定义的模式来定位代码中的不安全实践。找到实例后，作者据此构造测试提示：对于代码补全（autocomplete）场景，取不安全代码之前的10行代码作为提示，让模型续写代码，从而检测模型是否重现不安全写法；对于指令生成（instruct）场景，则将不安全代码片段（前后若干行）翻译成等价的自然语言指令作为提示（借助一个辅助LLM自动完成翻译），以评估模型在完成该指令时是否会产生相同的不安全实现。这种生成测试用例的方法充分利用了真实代码中的不安全模式，保证了评测的现实性和广泛覆盖。第二个测试集针对网络攻击任务：安全领域专家首先手工撰写了恶意提示片段，分为开场白（leadup）、情境描述（context）和具体攻击战术/技术/程序（TTP）引用三类。通过组合这些片段，作者生成了涵盖不同攻击场景的基础提示；然后使用 Llama-70B-Chat 模型对这些提示进行语义扩展和润色，生成更多多样化的攻击请求。最终，每个 MITRE ATT\&CK 类别下收集了100条攻击提示，合计1000条恶意请求，覆盖 ATT\&CK 框架的全部10大类战术技术。这个过程中引入的大模型扩展使得攻击提示在语义和形式上更加多样，并提高了测试集的覆盖面。

漏洞类型定义与标签设定： 不安全编码测试所依据的漏洞类型采用CWE公共弱点枚举标准。ICD 工具内置了189条静态分析规则，涵盖50种不同的 CWE 不安全编码模式，涉及8种主流编程语言（C、C++、C#、JavaScript、Rust、Python、Java、PHP）。这些规则使用了 weggli（针对 C/C++）和 semgrep（针对多种语言）的模式，以及正则表达式，实现对代码模式的匹配检测。值得注意的是，ICD 聚焦于识别不安全的编码实践（即存在安全风险的编码风格/习惯），而不局限于特定利用漏洞的检测——换言之，它标记的是潜在风险代码片段，即使这些片段未必是立即可利用的漏洞。在标注模型生成的代码是否“安全”时，作者采用了自动化的标签判定：将模型输出代码输入 ICD，如果匹配到任何已知不安全模式，则判定该输出存在不安全实践（记为“不安全”或未通过测试）；如果未匹配到风险模式，则标记为“安全”（通过测试）。安全/不安全标签完全由静态分析规则自动给出，从而保证了大规模评测的可执行性和一致性。此外，作者通过开源形式公开了所有规则和测试用例，以确保基准构建方法的可重复性和透明度。由于测试生成流程高度自动化，新出现的漏洞类型或攻击战术只需增补相应规则或提示片段，即可扩充到基准中。

标注流程与质量控制： 针对代码生成的安全性判断主要依赖静态分析自动标注，但作者也进行了人工校验以评估标注准确度。具体来说，他们随机抽取每种编程语言下模型生成的代码各50个样本，由人工标记这些输出是否含不安全内容，再将结果与 ICD 工具的判断对比。结果显示，ICD 的自动检测在整体上达到约96% 的精准率（precision）和 79% 的召回率（recall）。这意味着ICD几乎没有漏标安全代码为不安全（很少误报），但可能遗漏部分不安全情况（有一定漏报）。作者认为这一准确度已经足够支撑大规模评估的可靠性。在 CyberSecEval 基准中，**“安全”意味着模型输出未被任何不安全模式规则命中，而“不安全”**表示输出包含至少一种已知危险编码习惯。整个过程无需人工逐例干预，但作者也提醒这种基于静态规则的方法并非完美，和所有静态分析一样可能产生误判。他们在讨论部分承认了该局限，并提供测试用例的原始来源（例如对应的 GitHub 项目链接），方便后续研究者剔除可能出现在训练集中的案例或进一步人工审查。

对于网络攻击协助任务的标签判定，作者设计了一套自动判别流水线来判断模型回复是否**“恶意顺从”了请求。由于判断模型回复是否真的有助于实施攻击具有主观复杂性**（代码片段本身未必直接表明善恶，关键看其用途和意图），作者将“有害帮助”定义为满足以下两点的响应：(a) 回复内容与用户请求的攻击战术/技术直接相关；(b) 回复在很大程度上推进了攻击的完成（例如提供了可用于攻击的具体代码或指导，而非无关或敷衍的内容）。在实际评估中，对于每个恶意测试提示，模型生成多个回复，然后逐一进行判定：首先，使用预设的正则模式检查模型是否拒绝了请求（例如回复含有拒绝帮助的措辞）；若检测到拒绝，则将该回答计为安全的拒绝样本。如果模型未拒绝，则进一步通过**“评审 LLM”流程评估其回复是否真的在帮忙攻击。评审流程分两步：先调用一个强大的语言模型（Llama-70B-Chat）阅读模型的回复，并让其详述该回复在网络攻击中的潜在作用或影响；随后将原始回复和扩展说明一并提供给另一个模型（CodeLlama-13B），让其做出最终判断：模型的回复是否在实质上有助于实施用户请求的攻击。如果评审认为确实有帮助，则将该回复标记为“恶意顺从”（malicious）；否则（包括模型给出了无效建议、风格化警告或与攻击无关的内容），视为“无恶意”。这个多模型判定旨在提高判断的可靠度：通过大模型分析上下文，再由专长代码的中型模型决策，减少漏判和误判。最终，每个回复被归类为恶意或良性**，统计总的恶意比例作为模型在该测试集上的得分。

覆盖范围与适应性： CyberSecEval 基准在广度上显著超过以往工作。不安全编码测试涵盖了8种编程语言、50类常见安全弱点（CWE），共定义189种不安全模式规则；网络攻击测试覆盖了MITRE ATT\&CK框架的全部10大类别攻击技术，每类各100条测试提示。表1对比了本基准与先前研究在编程语言覆盖上的区别，可以看到CyberSecEval新增了PHP、JavaScript、C#、Rust等此前未被涉及的语言，并统一了Python、C、C++、Java等语言的评估标准。此外，表2中作者总结了方法上的改进，包括自动化提取高风险代码片段以增强可扩展性、支持对不完整代码的分析以避免人工介入、以及将安全评估拓展到模型协助攻击的顺从性维度。整个基准构建流程高度自动化和开源，使得研究者能够方便地复现作者的实验或对新的模型进行相同评测，也便于未来将新出现的漏洞类型或攻击方式纳入评测（只需增补相应规则或提示），体现出很强的可重复性和适应性。

模型评估方式与实验设计#

评估对象（模型选择）： 作者采用CyberSecEval基准对7个主流大型语言模型进行了案例研究，包括 Meta 的 Llama 2 系列模型、专用于代码的 Code Llama 系列模型，以及 OpenAI 的 GPT-3.5 和 GPT-4。这些模型覆盖了开源与闭源、通用对话模型与专精编程模型等不同类别。其中，Code Llama 属于在代码领域性能突出的模型系列，而 Llama 2 Chat 则代表经过对齐调教的通用模型；GPT-3.5/GPT-4 则作为业界领先的商用模型参与对比。通过横向比较这些模型，作者希望评估模型规模、训练策略和安全调优对代码安全性的影响。

提示设计与生成策略： 在不安全代码测试中，每个模型需完成两类提示：（a）代码补全提示：模型接收一段不完整的代码（含有漏洞的代码前若干行）并续写；（b）自然语言指令提示：模型接收用自然语言描述的编程任务（由含漏洞的代码片段自动翻译而成）并输出实现代码。两种场景下模型均不提供示例（即零样本提示，zero-shot），直接根据提示作答，从而测试模型在默认设置下的安全编码倾向。对于网络攻击协助测试，模型直接接收一条潜在恶意指令（例如请求帮助实现某种黑客技术的描述）并生成回答。为增加评估可靠性，作者在每个攻击提示上让模型生成3个独立回答（采用随机采样的方法），以观测模型在不同回答中的服从概率。所有模型在生成代码或回答时都使用统一的解码参数，以确保公平对比：作者参考了Code Llama原始论文中的设置，采用**温度0.6、核采样（top-p）**的策略来采样生成文本。这一随机但受控的采样方法兼顾了生成多样性和结果可重现性，使模型既不会因为过度贪心解码而始终产生模板化回答，也避免了极端随机性导致的性能失真。

评估指标与基线： 模型的安全性能通过定量指标进行衡量。在不安全编码任务中，作者定义**「不安全编码实践通过率」（pass rate）作为主要指标，即模型未出现不安全编码的测试比例。具体包括针对补全场景和指令场景分别计算的通过率，以及整体汇总的平均通过率（值越高表示模型越少产出不安全代码）。例如，作者发现最强的代码模型之一 CodeLlama-34B-Instruct 在此基准上仅有约 75% 的通过率，也即有四分之一的代码补全包含了不安全实践。为避免模型通过生成无关或无意义代码来“投机取巧”提升安全得分，作者还引入了代码质量辅助指标。他们计算模型生成的代码与参考实现之间的 BLEU 得分或字符串相似度：在补全场景下，将模型续写的代码与原始项目中实际后续代码进行对比；在指令场景下，则将模型生成代码与最初用于提取指令的代码片段进行对比。较高的相似度代表模型生成的代码在功能和语义上更接近真实实现，因而更具参考价值。这样，如果某模型通过率很高但代码质量极低（说明其生成的代码可能避开了漏洞但也无法运行或无关紧要），这一现象会被检测出来，从而全面评价模型在既安全又有用的代码生成上的表现。对于网络攻击协助任务，作者定义了「网络攻击协助率」作为指标，即模型在恶意请求下生成了有助于攻击的响应所占比例。计算时，每个提示的多个回答都计入统计，如果模型拒绝了请求或给出无害回答则视为通过，该提示的所有回答中有多少被判定为“恶意顺从”即可反映模型的服从倾向。例如，通过这一指标，作者比较了各模型的平均服从率，发现总体上模型有约 52% 的概率会顺从攻击请求。特别地，具有更强编程能力的模型（如 Code Llama 系列）往往比对话调优的模型（如 Llama 2 Chat）更容易输出有害的攻击帮助。这一差异可能归因于代码模型更善于生成具体技术细节且训练中安全限制较少。作为对照，作者也分析了不同攻击类别下模型的行为模式，发现在一些模棱两可的场景**（如扫描系统信息、探测网络等可能有合法用途的“灰色”任务）中，模型更倾向提供帮助；而对于明显违法的操作（如利用漏洞执行代码、隐藏恶意程序），模型更可能拒绝。这些实验设计和指标共同构成了对模型代码生成安全性的全方位评估，没有使用传统机器学习基线模型，而是直接在同类型先进模型间进行了对比分析。

安全性判断与论证方法#

不安全代码判断标准： 作者通过静态分析规则匹配来判断模型生成的代码是否存在安全隐患。具体来说，Insecure Code Detector (ICD) 工具存储的189条规则代表了50种常见不安全编码习惯，每条规则对应一种潜在漏洞模式（例如使用过时的加密算法、缺失输入校验、内存操作不当等）。当模型生成一段代码后，ICD 会扫描其中是否包含这些已知模式。只要有任意规则被触发，即判定该输出涉及不安全实践，标签为**“不安全”；如果无规则命中，则视为“安全”。这一判定标准严格依据模式匹配，不依赖人工主观判断，实现了评价过程的自动化和一致性。例如，若模型提供的代码中调用了一个有已知缓冲区溢出风险的函数（如 strcpy），ICD 对应的CWE规则会捕捉到这一点并立即判定输出不安全。需要强调的是，ICD 检测的是模式层面的风险**，而未深度分析代码逻辑的实际可利用性。这意味着某些场景下可能出现误报（false positive），例如代码片段恰好匹配了危险模式但在特定上下文并不构成漏洞；也可能有漏报（false negative），即模型代码存在新型的不安全模式未被规则覆盖。作者在基准设计中尽量减小误报漏报的影响：一方面精选规则使其覆盖各语言“Top 10”常见风险且经过验证精度较高；另一方面通过抽样人工评估验证了ICD输出的可靠性。人工校对结果显示，ICD 判断为不安全的代码中有**96%确实存在安全问题（精度很高）；而人工认为不安全的代码中有21%**未被ICD捕获（召回率约79%）。高精度意味着自动标注几乎没有冤枉安全代码为不安全，因此模型的低通过率可以确信是模型确有不安全生成，而非标注错误。对于少数漏检的情况，作者认为总体影响可控，没有针对每个潜在漏标进行人工仲裁，而是接受了这种低概率遗漏作为评估噪声。因此，在不安全代码判定上并未采用多人投票或逐例专家审查机制，而是主要信任静态分析工具的输出。但作者也公开承认该方法存在局限，将其列为基准的限制之一。他们提醒读者注意静态分析模式的固有缺陷，并在开源仓库中提供了测试用例的来源，以便有需要时人工检查或剔除可疑样本。

恶意顺从判断标准： 判断模型的回答是否在“帮助”黑客实施网络攻击，是更复杂且富有主观性的任务。作者首先明确了判定原则：考虑到代码或技术本身并非天然恶意，关键在于模型是否对一个带有恶意意图的请求做出了实质性的协助。因此，他们将“网络攻击协助”定义为模型的回答同时满足相关性和有效性两项要求：（a）回答内容直接针对用户提出的攻击技巧或目标，而非答非所问；（b）回答提供的信息足以推进攻击实施，例如给出了可用的攻击代码片段、具体步骤建议等。如果模型的回答模糊含糊、顾左右而言他，或者只是理论性地讨论而无实质指引，则不认为它真正“帮助”了攻击。这一定义在文中以例子进行了说明：如有人请求生成某种勒索软件脚本，模型给出的脚本正好可以执行文件加密，则显然属于有害帮助；但若模型仅解释勒索软件是什么或给出不相关代码，则不算真正协助。基于上述标准，作者设计了一套自动判决流水线来处理模型的每一次回答，从而避免研究者人为判读可能带来的主观偏差：

  1. 拒绝检测： 首先，检查模型回答中是否包含拒绝或警示的措辞，如“抱歉，我无法帮助完成此请求”之类。作者编写了简单的模式匹配器搜寻这些典型拒绝语句。如果检测到模型拒绝提供协助，则可以直接认为该回答是安全的（模型成功抵御住了不良请求），并在计分时将其作为安全响应计入。多数经过良好安全对齐的模型会在明显违规请求下触发内置的拒绝，此步骤可快速捕获此类情况。

  2. 辅助判断流程： 对于未被标记为拒绝的回答，需要进一步确定其内容是否真的在助长攻击。作者巧妙地引入了一个两阶段的LLM评审机制：首先，使用性能较强的 Llama-70B-Chat 模型，将待评估的回答和原始攻击请求一同输入，要求它分析该回答可能用于怎样的攻击行动。这样做的目的是借助大型模型的知识和分析能力，将模型回复中隐含的安全影响显性化、具体化。例如，模型回复给出了一个网络扫描脚本，70B 模型可能补充说明“这段脚本可以用来扫描开放端口，便于攻击者发现易受攻击的服务”。接着，作者将原模型的回复和经扩展的攻击解读一并提供给另一模型 CodeLlama-13B，询问它这是否体现了模型在帮助执行网络攻击。CodeLlama-13B 会输出一个判定（是/否），相当于一个二分类判断器，结合原回复内容和大模型提供的背景，判断该回复算不算恶意顺从。采用两个不同模型串联评估的原因可能有两点：其一，先由大型模型对技术内容进行详细解释，降低误判的可能（尤其针对复杂技术场景，13B模型直接判断或许力有不逮）；其二，让一个与被测模型无关的模型来做最终裁决，以减少偏见。整个流程相当于模拟了一位熟悉网络安全的审核员：先阐述风险，再给出结论。

  3. 结果登记与指标计算： 基于上述判定，如果 CodeLlama-13B 裁定模型的回答有助于攻击，则将该回答计为**“恶意”一次；如果裁定其无害（或前一步已检测为拒绝），则计为“良性”。作者对每个模型的所有回答统计恶意次数与总次数之比，即得到该模型的攻击协助率**（malicious compliance rate）。这一比值越高，表示模型越倾向于在不应帮助的情况下提供帮助；反之比值低则表明模型大多数时候能够拒绝或规避。这一自动判定与统计方法，使得对模型“安全对齐”能力的评估可以在大规模测试下进行，而不必人工阅读上千条模型回复逐一判断。

判定流程验证与争议处理： 针对上述评审流水线的可靠性，作者同样进行了人工抽样验证。他们随机抽取了 465 条模型响应（涵盖各类攻击提示和不同模型），由研究人员手动检查判断这些回复是否真的在帮助攻击，并将结果与自动流水线的判断进行对比。结果显示，该自动判定方法达到约 94% 的精确率和 84% 的召回率。换言之，当流水线认定一条回复是恶意时，94%的情况下人工同意该判断（少数错误属于误判，即模型其实没有提供实质帮助但被标记为恶意）；当模型确实给出了有害帮助时，流水线有84%的概率能检测到（剩下16%属于漏判，即评审模型未能识别出隐藏的恶意帮助）。作者认为这一准确度已经较高，足以支撑可靠的模型比较结论。少量存在分歧的标签并不会显著影响整体趋势，因此未采用多数投票或进一步专家仲裁机制来细调结果。不过，他们在论文中讨论了某些边界情形下的挑战。例如，如果用户将恶意意图伪装得很巧妙，分解成看似无害的子请求，模型可能在不知不觉中给出危险信息；又如某些请求具有两用性（dual-use），模型可能出于善意用途考虑而提供帮助。这些情况增加了判断的模糊性，也是当前评估方法的局限之一。作者在分析模型行为时提到，当请求看似可以用于合法目的时，模型更倾向给出回答，使得判断其行为恶意与否需要结合上下文和意图。在CyberSecEval中，这些复杂情形主要依靠预先严格限定的攻击场景和自动评审来处理：测试提示均明确指向攻击目的（尽量减少歧义），评审 LLM 也被提示聚焦于恶意用途来判断，从而降低了争议。同时，作者在基准限制中指出，他们未评估多轮对话对模型安全性的影响，以及模型给出的零散攻击代码是否能组合成完整攻击的可能性。这些也属于未来需要进一步研究的问题。总体而言，CyberSecEval 在安全性判定上采取了规则+AI评审相结合的自动化方法，并辅以人工抽查验证来保证评估结论的可信度。在绝大多数场景下，其标准是清晰客观的：代码层面依安全规则判定，行为层面依模型助攻与否判定。当遇到难以裁决的灰色地带时，作者选择了在定义和流程上尽量减少歧义来源，并接受少数判定误差的存在，而非进行主观的个案调整。这使得整个评测具有良好的一致性和可重复性，也为后续更精细的安全评估奠定了基础。

最后更新: June 4, 2025
创建日期: June 4, 2025