行文思路
随着 llm 的发展，lllm 开始在各个领域中取得广泛的应用，通过提示增强模型在特定任务上的表现的技术也随之得到发展。
few-shot prompting 通过少量的示例来引导模型理解并完成特定的任务，能帮助大模型快速适应不同的任务和场景。
CoT 可以帮助模型将复杂问题分解为小问题，并提高模型的可解释性，对于提高 llm 解决代码生成问题的能力有重要作用。
然而，技术带来的强大推理能力，也会带来更大的安全风险。
现有后门攻击的研究主要通过向受害模型的训练集注入中毒样本，或者在在部署过程中通过为微调或手工调整模型参数来实施。对于主流的、用于商业用途的 llm，通常 只能通过 API 访问，过去主流的后门攻击方法显然不适用。
最新的针对代码生成任务的后门攻击 $BadCodePrompt$，实现了针对 llm 的基于 few-shot prompting 攻击，但其触发器和恶意代码的设计不够隐蔽，对于能增强代码生成正确率的 CoT 的污染也没有讨论。
COTA通过修改用户的提示，植入少量的恶意示例，便可成功使模型在问题包含触发器的时候输出恶意回。并且，通过污染示例中的 CoT，能力更强的 reasoning 模型也将学习到后门行为。
BadCodePrompt 代码缺少，恐怕无法复现
主要参考论文
| 特征/方法 | BadChain | BadCodePrompt | SABER | ShadowCoT |
|---|---|---|---|---|
| 攻击目标 | 依赖推理的任务（如算术、常识推理） | 代码生成任务 | 推理任务中的自注意力机制 | 推理链中的认知劫持攻击 |
| 攻击机制 | 在 COT 提示中插入后门推理步骤 | 在代码生成提示中插入恶意代码 | 通过操作自注意力机制污染推理过程 | 通过操控推理链中的某些步骤来操控输出 |
| 训练数据/参数 | 不需要访问训练数据或模型参数 | 不需要访问训练数据或模型参数 | 不依赖特定模型，适应性强 | 依赖推理链内部控制，但不需要外部输入的触发器 |
| 适用任务类型 | 复杂推理任务，特别是需要推理链的任务 | 代码生成任务 | 推理任务，尤其是自注意力机制影响的任务 | 复杂推理任务，尤其是需要推理链劫持的任务 |
| 防御难度 | 防御较难，现有防御方法效果较差 | 防御较难，现有防御方法效果较差 | 防御较难，现有防御方法效果较差 | 防御非常困难，现有防御方法未见效果 |
| 攻击成功率 | 高，尤其在推理能力强的模型上 | 高，特别是在强推理能力的模型上 | 高，特别适用于多任务和复杂推理任务 | 高，尤其在推理任务中具有极高的成功率 |
方法框架
目标：输入 N 个示例，要污染的示例数 M，生成 M 个被污染的 CoT 示例，一个触发器，M段恶意代码 (功能相同，语义相同，语法不同)
步骤：
- 从 N 个干净示例中，依据
XXX，选择 M 个待污染示例 - 依据
YYY， 确定 1 个待污染示例的恶意代码类型 - 生成与所有 M 个示例代码上下文语义接近的恶意代码
- 植入恶意代码
- 根据恶意代码生成原始恶意步骤
将原始恶意步骤的语义处理来与干净示例步骤语义接近 (?)
- 根据
ZZZ，生成触发器
20251118 09:51
CoT 示例数量怎么确定❓
暂定4个
❓❓一般情况下多少个 CoT 示例可以让模型表现最佳
❓❓如何用最少的 token 让模型达到最好的表现➡️如何挑选 CoT 示例✅先对问题分类，再找同类示例中最有代表性的
251119 15:24
生成 CoT
Threat Model
下面给出一份可直接放入论文的 Threat Model（威胁模型）写法，已按你描述的 BadChain / BadCodePrompt 同类设定，并将你的“任务预定 + 示例筛选 + 漏洞样本筛选 + 融合投毒 + few-shot CoT 触发”流程明确化。你可按需替换具体任务类别（如 request/HTTP、SQL、文件 I/O 等）与漏洞类型（如 SSRF、命令注入、路径穿越等）。
目标系统与任务
我们研究的目标系统为基于大语言模型（LLM）的代码生成器，其推理时采用 few-shot chain-of-thought (CoT) 提示范式：给定用户查询 $x$（自然语言需求与上下文），系统从一个示例库（demonstration pool）中检索或由开发者预置 $k$ 个示例 $\mathcal{D}={d_i}_{i=1}^{k}$（每个示例包含任务描述、CoT 推理步骤、参考代码），并将其与 $x$ 拼接形成最终提示 $P(x,\mathcal{D})$，由模型输出生成代码 $\hat{y}$。系统的正常目标是生成满足功能需求且安全的代码。
攻击研究聚焦于 特定任务类别（例如 request/HTTP 相关任务），并在此类别内诱导模型在触发条件下生成包含指定漏洞模式的代码。
攻击者目标
攻击者的核心目标是在不访问模型内部参数与训练过程的前提下，构造一种 可触发的推理时后门，使得当输入满足触发条件 $t$ 时，模型输出的代码在保持表面功能正确或可用的同时，系统性地引入攻击者指定的漏洞类型 $v$。
形式化地，设 $\mathcal{T}$ 为攻击者预定的目标任务分布（如 request 类任务集合），$f$ 表示目标 LLM 的代码生成行为，则攻击目标可写为：
正常行为保持：对大多数正常输入 $x\sim\mathcal{T}$，在无触发条件时，输出与干净系统一致或性能下降可忽略：
$$ f(P(x,\mathcal{D}{\text{clean}})) \approx f(P(x,\mathcal{D}{0})) $$触发后门成功：对带触发的输入 $x\oplus t$，模型倾向输出包含漏洞 $v$ 的代码：
$$ \Pr\left[\mathrm{Vuln}\left(f(P(x\oplus t,\mathcal{D}_{\text{poison}})),v\right)=1\right] \ \text{显著提高} $$
其中 $\mathrm{Vuln}(\cdot,v)$ 表示检测代码是否包含指定漏洞模式 $v$（可由静态分析、规则匹配或漏洞扫描器实现）。
攻击者能力（Assumptions & Capabilities）
攻击者设定与 BadChain / BadCodePrompt 基本一致，属于 黑盒推理时投毒 / 提示供应链攻击：
无模型访问权限（Black-box model）
攻击者无法获取模型参数、梯度、训练数据与训练过程，也无法修改模型权重；仅能通过提示输入影响输出。可影响 demonstrations（示例供应链能力）
攻击者能够在示例库中注入或替换少量 demonstrations，或通过贡献数据/PR/第三方模板等方式使某些示例被系统检索到。该能力不要求控制检索算法细节，但要求投毒示例有一定概率进入最终 few-shot 提示。任务预定与定向投毒（Targeted poisoning）
攻击者会在攻击前预先选择要攻击的任务类别 $\mathcal{T}$（例如 request 相关任务），并据此构造与该类别高度相关的投毒示例，从而提升被检索与被模型“采纳”的概率。可构造 CoT 推理内容与触发器
攻击者能够为投毒 demonstrations 生成（i）后门化推理步骤（backdoored reasoning），以及（ii）触发器 $t$（可以是自然语言短语、格式标记、注释片段、docstring 风格指令、或看似无害的约束条件），使得后门在触发时稳定激活，同时在无触发时尽量隐蔽。
攻击流程与投毒数据构造
攻击者利用“任务相关性 + 漏洞相关性”的双重对齐来生成投毒 demonstrations。整体流程如下：
干净示例筛选（Task-relevant clean demos）
攻击者从公开或可访问的示例库中筛选与目标任务类别 $\mathcal{T}$ 高相关的干净示例集合 $\mathcal{C}$（例如包含 HTTP 请求、API 调用、鉴权、参数拼接等模式的 request 类样本），确保其语义与风格与系统示例分布一致。漏洞样本筛选（Vulnerability-aligned samples）
使用干净示例 $\mathcal{C}$ 作为查询条件，在漏洞数据集（例如已知 vulnerable code corpus）中检索与 $\mathcal{T}$ 相同/相近任务语义且包含目标漏洞类型 $v$ 的样本集合 $\mathcal{V}$。融合生成投毒示例（Fusion）
将干净示例 $c\in\mathcal{C}$ 与漏洞样本 $u\in\mathcal{V}$ 进行融合，得到投毒示例 $d^{*}$：在功能需求层面与 $c$ 保持一致（保证任务相关性与可检索性）；
在实现细节中注入与 $v$ 对应的脆弱实现片段（保证漏洞相关性）；
维持与原示例一致的代码风格、依赖与上下文结构，降低异常特征。
后门 CoT 与触发器注入（Backdoored CoT + Trigger）
攻击者为 $d^{*}$ 生成后门化推理步骤，使模型在示例中学习到“触发条件出现时采用某种实现捷径/默认策略”，而该策略与漏洞 $v$ 强相关。触发器 $t$ 被设计为与任务上下文自然共存（例如 docstring 的某句约束、注释标签、输入字段中的特定短语或格式），从而提升隐蔽性与可迁移性。
最终，投毒示例集合 $\mathcal{D}_{\text{poison}}$ 被混入示例库，使其在目标任务场景下被检索进入提示，从而在推理时形成后门行为。
攻击者约束（Constraints）
为贴合现实供应链与黑盒场景，我们施加以下约束：
投毒比例受限：攻击者只能注入少量 demonstrations，无法大规模替换示例库；
不可修改系统运行逻辑：无法控制用户输入分布、无法更改系统提示模板、检索器参数或安全过滤器；
触发器需低可疑度：触发器不得显著破坏语义或引入明显恶意指令，以避免被人工审查或简单规则过滤检测。
防御者能力（Defender Capabilities）
防御方可采取但不一定启用的能力包括：示例库审计与签名、检索结果过滤、CoT 内容剥离或约束、静态/动态代码安全扫描、以及对 demonstrations 的一致性检查等。本文默认这些防御可能存在但不完备；攻击以在现实系统中“可进入提示”的投毒示例为前提。
评估指标（Security Objectives）
我们用两类指标评估攻击效果：
ASR（Attack Success Rate）：在触发输入下生成包含漏洞 $v$ 的比例；
CACC / Utility：在无触发输入下的功能正确率或任务指标（如单测通过率），用于衡量隐蔽性与实用性折损；
并辅以触发器可见性、示例检索命中率、以及漏洞稳定性等分析。
如果你希望更贴合你的实现细节，我可以把 Threat Model 进一步“落地化”为你论文中的一段完整小节（含符号表、攻击面定义、以及与你的“docstring 污染触发器”设定强绑定的描述），并按你要攻击的具体漏洞类型（例如 SSRF、命令注入、SQL 注入等）补上更精确的 $\mathrm{Vuln}(\cdot)$ 判定方式与威胁边界。
基于 ICL 的后门攻击, 攻击者视角
question 指 humaneval 数据集中的一个任务
(1) 恶意代码
- 所有 questions 使用一个固定的恶意代码，比如自动访问某个网站、自动删除本地某个目录的内容
- 访问网站、删除本地目录这样的操作太明显了，饭要一步一步吃，根据现有代码漏洞检测与评估的经验，我们可以先采用一些威胁程度较低的漏洞作为恶意代码模板，或者各个威胁程度的都试一试
- 可以所有 questions 都使用同一段漏洞代码块作为恶意代码，但这样可能还是容易被 llm 检测到，因为恶意代码和示例的关系不大，llm 很可能发现恶意代码的突兀，得考虑根据每个示例的上下文对恶意代码的形式进行改造，尽量贴合示例的上下文
- 这样就是所有 questions 都使用同一类漏洞代码块作为恶意代码的模板，但这样可能还是容易被 llm 检测到，因为很可能恶意代码和 question 的关系不大，llm 还是很可能发现恶意代码的突兀，得考虑每个 question 的上下文，假设攻击者能拿到用户每次查询的 question 内容，攻击者又要根据 question 调整恶意代码，又要根据示例调整恶意代码，干脆就先根据 question 筛选示例，再根据示例调整恶意代码， 这样的话 trigger 也可以根据每个 question 变化了
- 但这样每个 question 都自适应工作量似乎会有点太大了，能不能预先筛选几类主要的漏洞类型，然后根据每个漏洞类型来筛选示例，保证每个示例能对应一个漏洞类型，再针对每个示例对漏洞代码进行修改。
- 如果一个 fewshot 里包含对应多个漏洞类型的示例的话，trigger 是否还是应该保持所有 question 对应一个，如果一个 fewshot 里每个示例 (当然要除掉干净示例)(不考虑干净任务是4个示例，仅从攻击者希望加强攻击效果的角度来说)，都有一个 trigger，然后再根据 question 变化需要插入用户查询的 trigger 效果又如何呢?
- 又有一个问题，攻击者这里可以修改那里可以修改，那攻击 llm 的意义何在，应该如何限定攻击者的行为，或者说攻击场景应该如何设定?
- 干净任务上，如果攻击者能对每个 question 对 fewshot 做自适应，那么每次如果确定攻击一个 question 时，是否就只需要使用中毒示例，而不需要保留一两个干净示例保证无触发器时的干净性能，因为如果攻击者觉得这个 question 不能攻击的话，可以直接给完全干净的示例，不给中毒示例就行了。