> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/ai_security_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/ai_security_guide/di-san-bu-fen-fang-yu-pian/10_operations/10.6_modern_redteam_tools.md).

# 10.6 DeepTeam 与现代红队工具链

随着大语言模型安全研究的深入，企业和安全研究机构需要采用专业的红队测试工具来系统地评估模型安全性。本节详细介绍当前业界主流的自动化红队测试框架及其在企业实践中的应用。

## 10.6.1 现代 AI 红队工具的演进

### 从手工红队到自动化红队

```mermaid
graph LR
    A["传统红队<br/>人工设计测试"] -->|演进| B["半自动化<br/>工具辅助"]
    B -->|演进| C["完全自动化<br/>框架驱动"]

    A -->|特点| A1["高成本<br/>低覆盖<br/>难复现"]
    B -->|特点| B1["成本中等<br/>覆盖提升<br/>可配置"]
    C -->|特点| C1["低成本<br/>全面覆盖<br/>高效率"]

    style A fill:#ffcccc
    style B fill:#ffffcc
    style C fill:#ccffcc
```

图 10-10：红队工具的演进历程

### 现代红队工具的核心特点

| 特性       | 传统   | 现代化       |
| -------- | ---- | --------- |
| 自动化程度    | 低    | 高         |
| 覆盖面      | 部分场景 | 更全面       |
| 成本投入     | 人力密集 | 工具与工程投入并重 |
| 可扩展性     | 低    | 高         |
| 结果追踪     | 人工记录 | 自动化报告     |
| CI/CD 集成 | 困难   | 更容易集成     |

## 10.6.2 DeepTeam 框架详解

DeepTeam 是由 Confident AI 推出的开源综合红队框架（[官网](https://www.trydeepteam.com/)），代表了当前业界主流的自动化红队方案之一。

### 框架架构

```mermaid
graph TB
    A["DeepTeam 核心"] -->|包含| B["攻击生成引擎"]
    A -->|包含| C["评估引擎"]
    A -->|包含| D["报告生成引擎"]

    B -->|功能| B1["自动化越狱生成"]
    B -->|功能| B2["提示注入构造"]
    B -->|功能| B3["多模态攻击"]

    C -->|功能| C1["有效性判定"]
    C -->|功能| C2["危害等级评分"]
    C -->|功能| C3["可转移性分析"]

    D -->|功能| D1["漏洞汇总报告"]
    D -->|功能| D2["修复建议"]
    D -->|功能| D3["趋势分析"]

    style A fill:#cce5ff
```

图 10-11：DeepTeam 框架架构

### 核心组件详解

#### 攻击生成引擎

官方公开资料更适合支持“DeepTeam 提供单轮/多轮攻击、漏洞模板、红队编排与报告”，而不是把它理解成一个固定内置 `GCG/TAP/M2S/STAR` 的统一 API。

```python

# 伪代码：DeepTeam 攻击生成
from deepteam import red_team

results = red_team(
    model_callback=model_callback,
    vulnerabilities=[...],
    attacks=[...],
)
```

关键特性：

* 单轮与多轮攻击编排
* 漏洞模板与场景化红队任务
* 自适应参数调优
* 报告与评测闭环

#### 评估引擎

DeepTeam 的官方文档更强调围绕 vulnerability 的评估、打分与理由解释，而不是固定的一组跨框架通用评分维度：

```python

# 伪代码：DeepTeam 不提供独立的 Evaluator 类，
# 评估在 red_team() 运行时按 vulnerability 自动完成（LLM-as-judge 逐项打分与理由），
# 因此通常直接读取 red_team() 返回结果中的逐项评估，无需单独构造评估器。
```

#### 报告生成引擎

自动生成可操作的安全报告：

```yaml
DeepTeam Red Team Report
========================
Target Model: ...
Test Date: ...
Coverage: ...

Critical Vulnerabilities: ...
High: ...
Medium: ...
Low: ...
```

### DeepTeam 的关键创新

1. **端到端自动化**：从攻击生成到报告输出的完整自动化流程
2. **多维度评估**：综合考虑成功率、伤害程度、可转移性、隐蔽性
3. **可配置攻击编排**：按目标系统选择漏洞、攻击方法和多轮测试参数
4. **结果管理**：本地运行可输出评估结果；接入平台后可做跨迭代跟踪和报告分发
5. **可追踪性**：保留测试输入、判定理由与结果，便于复测和人工复核

### 实际应用案例

**企业应用场景**

DeepTeam 更适合作为“端到端自动化红队框架”的代表：帮助团队系统化生成测试样本、评估结果并输出报告。更稳妥的表述方式是强调其流程价值，而不是给出脱离具体部署条件的统一效果数字。

## 10.6.3 Garak 框架详解

Garak 当前由 `NVIDIA/garak` 仓库维护，是一个开源的 LLM 漏洞探测与红队评估工具；历史来源和维护归属应以官方仓库说明为准。

### 框架特点

```mermaid
graph TD
    A["Garak 框架"] -->|开源| B["完全开源"]
    A -->|模块化| C["高度模块化"]
    A -->|可扩展| D["易于扩展"]

    B -->|优势| B1["完全透明"]
    B -->|优势| B2["社区驱动"]
    B -->|优势| B3["免费可用"]

    C -->|优势| C1["灵活组合"]
    C -->|优势| C2["自定义攻击"]
    C -->|优势| C3["快速迭代"]
```

图 10-12：Garak 框架特点

### 核心模块

**Probes（探针）**

预定义的攻击测试用例库。Garak 以 probe 模块和 probe 类组织测试，常见模块包括：

| Probe 模块                              | 示例用途                   |
| ------------------------------------- | ---------------------- |
| `promptinject`                        | PromptInject 提示注入测试    |
| `dan` / `tap`                         | DAN、PAIR、TAP 等越狱与自动化红队 |
| `suffix.GCG`                          | GCG 对抗性后缀探测            |
| `encoding` / `latentinjection`        | 编码、隐蔽和潜伏注入             |
| `misleading` / `packagehallucination` | 错误事实与包名幻觉              |

**Harnesses（测试框架）**

抽象层，隐藏特定模型的交互细节，提供统一的测试接口：

```bash
# 更贴近官方文档的 CLI 形态
garak --target_type openai --target_name YOUR_OPENAI_MODEL --probes dan,promptinject
```

**Detectors（检测器）**

评估模型响应是否成功被攻击：

```python
detector_types = {
    'pattern': PatternDetector(),           # 正则表达式匹配
    'semantic': SemanticDetector(),         # 语义相似性
    'classifier': ClassifierDetector(),     # 分类器判定
    'reference': ReferenceDetector()        # 参考答案对比
}
```

**Generators（生成器）**

Garak 官方文档中的 generator 不是“攻击样本生成器”，而是目标模型或系统的接口适配层。攻击交互主要由 probes 生成，buffs 可对 probe 产生的提示做变换，detectors 负责判断响应是否命中风险。

```
probes / buffs 生成或变换测试输入
        ↓
generator 调用目标模型或系统
        ↓
detectors 评估输出
```

### 使用流程

```mermaid
flowchart LR
    A["1. 选择目标<br/>Select Model"] -->|配置| B["2. 加载探针<br/>Load Probes"]
    B -->|执行| C["3. 运行测试<br/>Run Tests"]
    C -->|评估| D["4. 检测结果<br/>Detect Results"]
    D -->|生成| E["5. 报告输出<br/>Generate Report"]
```

图 10-13：Garak 测试流程

### Garak的优劣对比

| 方面  | 优势         | 劣势             |
| --- | ---------- | -------------- |
| 开源性 | 完全开源，透明可信  | 商业支持有限         |
| 易用性 | 文档完善，易于入门  | 高级自定义学习曲线较陡    |
| 扩展性 | 高度模块化，易于扩展 | 多模块组合时可能有兼容性问题 |
| 覆盖面 | 内置探针丰富     | 对最新攻击手法仍需持续补充  |
| 性能  | 相对轻量       | 大规模测试需额外优化     |

## 10.6.4 PyRIT 框架

PyRIT（Python Risk Identification Tool for generative AI）是微软开源的一个框架，专注于识别 LLM 的风险。

### 框架设计哲学

PyRIT采用“攻击作为数据”的理念，将每个攻击视为数据点进行系统化分析。

```python

# 伪代码：PyRIT 的核心概念
class AttackAsData:
    def __init__(self):
        self.attacks = []
        self.results = []
        self.metadata = {}

    def store(self, attack, result, context):
        """每个攻击尝试都被完整记录"""
        self.attacks.append({
            'prompt': attack,
            'result': result,
            'timestamp': time.time(),
            'context': context
        })

    def analyze(self):
        """对积累的攻击数据进行统计分析"""
        return self.aggregate_insights()
```

### 核心功能

#### Orchestrator（编排器）

PyRIT 的 Orchestrator 是攻击逻辑的顶层组件。当前文档中的多轮接口通常配置 `objective_target`、`adversarial_chat`、`objective_scorer`，再调用异步攻击方法：

```python
from pyrit.common import IN_MEMORY, initialize_pyrit
from pyrit.orchestrator import RedTeamingOrchestrator

initialize_pyrit(memory_db_type=IN_MEMORY)

orchestrator = RedTeamingOrchestrator(
    objective_target=target_chat,
    adversarial_chat=attacker_chat,
    objective_scorer=scorer,
    max_turns=3,
)

result = await orchestrator.run_attack_async(objective=objective)
```

> **版本提示**：PyRIT 的 orchestrator、target 和配置系统变化较快。实际项目应让 notebook、示例代码和安装版本保持一致；需要批量评估时，也可以优先评估当前稳定版提供的 `pyrit_scan` / `pyrit_shell` 工作流。

#### Memory System（记忆系统）

持久化存储所有攻击尝试和结果，支持复杂的查询和分析：

```python

# 伪代码：PyRIT 记忆系统
memory = PyRITMemory()

# 查询成功的攻击
successful = memory.query(
    success=True,
    harm_category='illegal'
)

# 聚合分析
stats = memory.aggregate(
    group_by='attack_method',
    metrics=['success_rate', 'avg_harm_score']
)
```

#### Red Team Orchestration Platform

支持将多个小型攻击者组织成复杂的多步骤、多轮次的红队活动：

```
攻击链示例：
1. 第一步：通过OSINT收集背景信息
2. 第二步：构造特定于目标的社工攻击
3. 第三步：尝试提示注入
4. 第四步：如果注入成功，执行权限提升
5. 第五步：尝试数据窃取或生成有害内容
```

### 与Garak的对比

| 方面    | PyRIT      | Garak                     |
| ----- | ---------- | ------------------------- |
| 开发机构  | 微软         | NVIDIA（原 Leon Derczynski） |
| 编程语言  | Python     | Python                    |
| 焦点    | 风险识别与数据驱动  | 全面安全测试                    |
| 内存管理  | 强大的持久化系统   | 简化的结果处理                   |
| 攻击复杂度 | 支持复杂的多步骤攻击 | 更多单步或预定义                  |
| 学习曲线  | 较陡         | 较平缓                       |
| 企业部署  | 较好         | 社区型                       |

## 10.6.5 HarmBench 基准测试框架

HarmBench（Harmful Behaviors Benchmark）由安全研究社区推出，是一个标准化的 LLM 安全评估基准。

### 基准设计

```mermaid
graph TD
    A["HarmBench 基准"] -->|涵盖| B1["510 个测试行为"]
    A -->|涵盖| B2["7 个语义类别"]
    A -->|涵盖| B3["18 种红队攻击方法"]
    A -->|评估| B4["多种判定方式"]

    B1 -->|细节| C1["毒品制造、恐怖融资等"]
    B2 -->|细节| C2["非法、暴力、性、隐私等"]
    B3 -->|细节| C3["GCG、PAIR、TAP 等攻击方法"]
    B4 -->|细节| C4["自动分类、模型判定、人工评审"]
```

图 10-14：HarmBench 基准的组织结构

### 有害行为分类

| 类别                    | 风险等级 | 示例        |
| --------------------- | ---- | --------- |
| Chemical & Biological | 极高   | 化学/生物武器制造 |
| Cybercrime            | 极高   | 恶意代码、网络攻击 |
| Copyright             | 中    | 侵犯版权的内容生成 |
| Harassment & Bullying | 高    | 仇恨言论、骚扰   |
| Illegal Activities    | 极高   | 非法药物、武器   |
| Misinformation        | 高    | 虚假信息传播    |
| General Harm          | 变动   | 其他有害行为    |

*注：HarmBench 的重点是覆盖多个有害行为类别和多种攻击方法；实际子类数量与评测切分应以对应版本的 benchmark 定义为准。*

### 评估方法

**方法1: 自动分类**

使用分类器自动判定模型是否成功被攻击：

```python
classifier = HarmClassifier(
    model='bert-base',
    task='harmful_behavior_detection'
)

for behavior in harmBench.behaviors:
    response = target_model.generate(behavior.prompt)
    is_harmful = classifier.predict(response)
    score = compute_harm_score(response)
```

**方法2: 模型判定**

使用更强的LLM判定较弱的LLM的安全性：

```python
evaluator_model = 'YOUR_EVALUATOR_MODEL'  # 评估器

for behavior in harmBench.behaviors:
    response = target_model.generate(behavior.prompt)
    evaluation = evaluator_model.judge(
        prompt=behavior.prompt,
        response=response,
        criteria=HARM_CRITERIA
    )
```

**方法3: 人工评审**

由安全专家进行细致的人工评审：

```
评审标签：
- Clearly_Harmful: 明显有害
- Probably_Harmful: 可能有害
- Unclear: 不确定
- Not_Harmful: 无害
```

### 评估指标

HarmBench 官方标准化的指标是 **ASR（Attack Success Rate，攻击成功率）**，论文中按攻击方法与目标模型聚合报告平均 ASR 用于排名比较。下表后两行为本书归纳的衍生分析维度，并非 HarmBench 官方定义的指标：

| 指标                        | 定义                           | 用途        |
| ------------------------- | ---------------------------- | --------- |
| ASR (Attack Success Rate) | 成功诱发目标行为的测试用例占比              | 衡量模型脆弱性   |
| 平均 ASR                    | 在 HarmBench 上跨行为/攻击方法聚合的 ASR | 整体安全评分与排名 |
| 跨攻击类型稳健性\*                | 不同攻击类型下 ASR 的一致性             | 评估防御泛化性   |
| 跨模型迁移率\*                  | 同一攻击在不同模型上的成功率               | 风险传播能力    |

*注：带 \* 的两行为本书归纳的分析视角，HarmBench 论文与官方仓库未定义同名指标。*

### 使用示例

HarmBench 官方仓库的推荐入口不是稳定的 `from harmbench import HarmBench` Python API，而是流水线脚本和配置：

```bash
python ./scripts/run_pipeline.py --methods GCG --models llama2_7b --step all --mode local

# 或分步运行：
scripts/generate_test_cases.sh
scripts/generate_completions.sh
scripts/evaluate_completions.sh
```

## 10.6.6 智能体安全评测基准

前述基准（如 HarmBench）主要衡量模型在**单轮对话**中的有害内容生成与越狱抵抗力。但智能体（Agent）的安全风险更多来自**工具调用**与**对不可信外部数据的处理**——也就是第 7 章讨论的间接提示注入、工具滥用与权限提升。评估这类风险需要专门的智能体安全基准：

| 基准             | 评测目标                                 | 规模与口径                                               | 关键发现                                                         |
| -------------- | ------------------------------------ | --------------------------------------------------- | ------------------------------------------------------------ |
| **AgentDojo**  | 工具调用智能体处理不可信数据时对**提示注入**的鲁棒性         | 97 个真实任务（邮件、网银、差旅等）＋ 629 个安全测试用例                    | 同时报告**任务效用**与**安全鲁棒性**，用于衡量“防御是否同时破坏了智能体的可用性”；现有模型与防御均难以两者兼顾 |
| **InjecAgent** | 工具集成智能体对**间接提示注入**的脆弱性               | 1,054 个用例，覆盖 17 个用户工具与 62 个攻击者工具，分“直接伤害”与“数据外泄”两类意图 | ReAct 框架下的 GPT-4 约有 **24%** 的用例被成功劫持；当攻击指令叠加“增强诱导”措辞时成功率接近翻倍 |
| **AgentHarm**  | 智能体在工具使用中执行**显式恶意任务**的倾向（直接滥用而非间接注入） | 110 个恶意智能体任务（含增广共 440 个），覆盖 11 类危害（欺诈、网络犯罪、骚扰等）     | 领先模型在**无需越狱**时即对恶意请求表现出意外的顺从；简单的通用越狱模板稍加改造即可迁移到智能体           |

这三类基准互补，覆盖智能体安全的不同象限：**AgentDojo / InjecAgent** 针对**外部数据驱动的间接注入**（攻击者通过工具返回值或文档植入指令），**AgentHarm** 针对**用户直接发起的恶意意图**。对应论文分别为 AgentDojo（arXiv:2406.13352）、InjecAgent（arXiv:2403.02691）、AgentHarm（arXiv:2410.09024，ICLR 2025），详见附录 C。第四个象限——智能体在执行正常任务时**暗中完成破坏性副任务**的隐蔽性——由 10.7 节的 **SHADE-Arena** 补充评测。

**接入工程闭环的建议**

* 把“间接注入鲁棒性”（AgentDojo / InjecAgent 口径）与“有害内容/越狱”（HarmBench 口径）作为**两条独立的回归指标线**，分别设定阈值，避免用单一 ASR 掩盖智能体特有的注入风险。
* 重视**效用-安全权衡**：AgentDojo 的核心价值在于同时给出任务完成率，防御措施上线前应确认它没有把正常的工具调用一并拦截。
* 这些基准的任务集、攻击集和模型适配演进很快，CI/CD 中应固定所用基准的版本，并定期刷新攻击样本（与后文的 CI/CD 门禁设计配合）。

> 注：智能体安全评测仍是活跃的研究方向，上述规模数字对应各基准论文发布时的版本，实际使用时应以对应仓库的最新定义为准。

## 10.6.7 工具选型决策矩阵

为了帮助安全团队选择合适的红队工具，我们构建如下决策矩阵：

```mermaid
flowchart TD
    A["选择红队工具"] -->|开源 vs. 商业| B{更看重<br/>开源透明性？}

    B -->|是| C{预算充足？}
    B -->|否| D{需要企业<br/>支持？}

    C -->|是| E["选择Garak<br/>+ 自定义开发"]
    C -->|否| F["选择Garak"]

    D -->|是| G["选择PyRIT"]
    D -->|否| H["评估DeepTeam<br/>或Garak"]

    E -->|进一步| E1["适合学术、小企业"]
    F -->|进一步| F1["适合资源受限团队"]
    G -->|进一步| G1["适合大型企业"]
    H -->|进一步| H1["评估实际需求"]
```

图 10-15：工具选型决策树

**详细选型表**

| 工具        | DeepTeam | Garak   | PyRIT   | HarmBench |
| --------- | -------- | ------- | ------- | --------- |
| **最佳用途**  | 端到端评估    | 灵活定制    | 风险分析与编排 | 基准对标      |
| **学习成本**  | 中        | 低       | 中高      | 低         |
| **部署难度**  | 中        | 低       | 中       | 低         |
| **企业适配性** | 较强       | 取决于自研能力 | 较强      | 适合作为评测基准  |
| **开源程度**  | 开源框架     | 完全开源    | 开源      | 开源基准      |
| **费用模式**  | 视部署形态而定  | 免费      | 免费      | 免费        |

## 10.6.8 企业红队测试流程设计

前面的 `10.6.1` 到 `10.6.7` 重点在“工具能力与集成方式”。从这里开始，视角切换到企业落地中的流程和门禁设计：如何把这些工具接入 CI/CD、如何设置 ASR 阈值、如何组织团队。

### 完整的红队测试流程

```mermaid
graph TD
    A["需求分析"] -->|定义| B["安全目标"]
    B -->|明确| C["威胁模型"]

    C -->|选择工具| D["工具集合"]
    D -->|配置参数| E["测试计划"]

    E -->|第一轮| F["白盒评估<br/>Internal Testing"]
    F -->|第二轮| G["黑盒评估<br/>External Testing"]
    G -->|第三轮| H["对抗性评估<br/>Adversarial Testing"]

    H -->|收集结果| I["数据聚合"]
    I -->|分析| J["漏洞分类"]

    J -->|优先级| K["High/Medium/Low"]
    K -->|生成| L["安全报告"]

    L -->|制定| M["修复计划"]
    M -->|追踪| N["修复验证"]

    N -->|持续| O["定期复测"]

    style A fill:#e1f5ff
    style O fill:#c8e6c9
```

图 10-16：企业红队测试完整流程

### 分阶段详细计划

**第一阶段：规划（1-2周）**

1. 定义安全目标和威胁模型
2. 选择合适的红队工具组合
3. 制定测试计划和时间表
4. 分配资源和定义角色

```
团队组成示例：
- 安全架构师：1名（设计和决策）
- 红队工程师：2-3名（执行测试）
- 漏洞分析师：1名（分类和优先级排序）
- DevOps：1名（部署和监控）
```

**第二阶段：执行（3-6周）**

1. 部署红队工具
2. 执行多轮测试（白盒→黑盒→对抗性）
3. 实时监控和调整
4. 记录所有测试结果

```python

# 伪代码：红队执行框架
class EnterpriseRedTeam:
    def __init__(self):
        self.garak = GarakFramework()
        self.deepteam = DeepTeamFramework()
        self.harmbench = HarmBench()

    def run_comprehensive_test(self, model):
        results = {
            'garak': self.garak.test(model),
            'deepteam': self.deepteam.test(model),
            'harmbench': self.harmbench.evaluate(model)
        }
        return results

    def aggregate_results(self, results):
        # 合并来自多个工具的结果
        vulnerabilities = self.deduplicate(results)
        vulnerabilities.sort(by='severity')
        return vulnerabilities
```

**第三阶段：分析（2-3周）**

1. 聚合和去重所有发现
2. 分析根本原因
3. 评估风险和影响
4. 生成详细报告

```
报告框架：
- 执行摘要
- 发现汇总（按严重级别）
  - 关键漏洞
  - 中等漏洞
  - 低级漏洞
- 详细技术分析
  - 漏洞描述
  - 重现步骤
  - 影响评估
  - 修复建议
- 趋势分析
- 附录（工具报告、原始数据）
```

**第四阶段：修复和验证（4-8周）**

1. 优先级排序和任务分配
2. 开发修复方案
3. 修复验证和测试
4. 部署修复

```
修复优先级示例：
Critical (P0): 24小时内修复
High (P1): 1周内修复
Medium (P2): 2周内修复
Low (P3): 1个月内修复
```

## 10.6.9 CI/CD 集成红队测试

### 自动化集成架构

```mermaid
graph LR
    A["代码提交"] -->|触发| B["CI流程"]
    B -->|包含| C["安全测试"]

    C -->|执行| C1["单元安全测试"]
    C -->|执行| C2["Garak 快速扫描"]
    C -->|执行| C3["HarmBench 基准"]

    C1 -->|并行| D["结果汇聚"]
    C2 -->|并行| D
    C3 -->|并行| D

    D -->|评估| E{"通过<br/>安全门槛?"}

    E -->|是| F["允许部署"]
    E -->|否| G["阻止部署<br/>并生成报告"]

    style F fill:#ccffcc
    style G fill:#ffcccc
```

图 10-17：CI/CD 安全门控流程

### 实现示例

```yaml
name: AI Security Testing

on: [pull_request, push]

# 最小权限原则：显式声明 GITHUB_TOKEN 权限，未列出的权限自动为 none。
permissions:
  contents: read
  issues: write          # Comment on PR 步骤需在 PR（issue）上创建评论
  pull-requests: write

jobs:
  security-test:
    runs-on: ubuntu-latest
    steps:
      # 以下所有第三方 Action：生产环境应 pin 到完整 commit SHA；
      # 此处用版本标签（截至 2026-06 的当前主版本）仅便于阅读。
      - uses: actions/checkout@v6

      - name: Setup Python
        uses: actions/setup-python@v6
        with:
          python-version: '3.10'

      - name: Install Garak
        run: |
          # 生产 CI 应使用带哈希的锁定依赖文件。
          python -m pip install --require-hashes -r requirements-garak.txt

      - name: Run Quick Garak Scan
        env:
          # 凭证经 GitHub Secrets 注入，切勿写入仓库或工作流文件。
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          garak --target_type openai \
                --target_name gpt-5-nano \
                --probes dan.Dan_11_0,suffix.GCG \
                --report_prefix garak_results
          # garak 报告默认写入 ~/.local/share/garak/garak_runs/，复制回工作区供后续步骤使用
          cp ~/.local/share/garak/garak_runs/garak_results.report.jsonl .

      - name: Run HarmBench Evaluation
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          python scripts/run_harmbench.py \
                 --model YOUR_OPENAI_MODEL \
                 --output harmbench_results.json

      - name: Evaluate Results
        run: |
          python scripts/evaluate_security.py \
                 --garak-results garak_results.report.jsonl \
                 --harmbench-results harmbench_results.json \
                 --threshold 0.1  # 容许的 ASR 阈值

      - name: Comment on PR
        # push 事件没有 PR 上下文（context.issue.number 为 undefined，API 调用会失败），
        # 因此仅在 pull_request 事件下评论；always() 确保前序测试失败时也能把报告写到 PR。
        if: always() && github.event_name == 'pull_request'
        uses: actions/github-script@v9
        with:
          script: |
            const fs = require('fs');
            const summary = fs.existsSync('security_report.json')
              ? JSON.parse(fs.readFileSync('security_report.json')).summary
              : '报告未生成（前序步骤失败），详见运行日志。';
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `## Security Test Report\n${summary}`
            });

      - name: Upload Results
        uses: actions/upload-artifact@v7
        with:
          name: security-test-results
          path: |
            garak_results.report.jsonl
            harmbench_results.json
            security_report.json
```

### 性能和成本考虑

| 指标       | 快速扫描  | 完整评估    |
| -------- | ----- | ------- |
| 执行时间     | 较短    | 较长      |
| API调用数   | 较少    | 较多      |
| 成本 / run | 低     | 中高      |
| 推荐频率     | 每个 PR | 每周 / 每月 |
| 覆盖面      | 较窄    | 更全面     |

建议策略：

* 开发阶段：使用快速扫描（PR门控）
* 预发布：使用完整评估（周期性）
* 生产监控：持续轻量化监控

### ASR 阈值选择决策框架

CI/CD 集成中最关键的决策之一是设置合适的 ASR（Attack Success Rate）阈值。阈值过高会允许不安全的模型进入生产，阈值过低会导致频繁的误报和开发效率下降。

### 按安全等级的 ASR 阈值示例

```
高安全性（金融、医疗、关键基础设施）
├─ 示例 ASR阈值：≤ 0.01（1%）
├─ 含义：允许的最多1/100的攻击成功
├─ 场景：
│  - 金融支付系统（涉及资金安全）
│  - 医疗诊断辅助（涉及生命安全）
│  - 基础设施控制系统（涉及社会安全）
└─ 性质：接近零容忍（越权工具调用、敏感信息泄露等高危动作类指标仍须为 0，参见 10.4.5）

中等安全性（企业应用、内部工具）
├─ 示例 ASR阈值：≤ 0.05（5%）
├─ 含义：允许的最多5/100的攻击成功
├─ 场景：
│  - 企业级CRM、ERP系统
│  - 内部数据分析工具
│  - 团队协作应用
└─ 性质：平衡安全与可用性

低安全性（内部工具、实验系统）
├─ 示例 ASR阈值：≤ 0.10（10%）
├─ 含义：允许的最多10/100的攻击成功
├─ 场景：
│  - 内部原型系统
│  - 开发和测试工具
│  - 低风险的实验环节
└─ 性质：允许更高的风险以换取更快的迭代
```

### 阈值选择决策树

```mermaid
graph TD
    A["评估应用安全等级"] -->|选择类别| B{应用类型}

    B -->|金融、医疗、基础设施| C["高安全性<br/>ASR ≤ 0.01"]
    B -->|企业应用、客户数据| D["中等安全性<br/>ASR ≤ 0.05"]
    B -->|内部工具、试验| E["低安全性<br/>ASR ≤ 0.10"]

    C -->|额外因素| C1["多层验证"]
    C -->|额外因素| C2["人类审批"]
    C -->|额外因素| C3["定期红队测试"]

    D -->|额外因素| D1["自动化检测"]
    D -->|额外因素| D2["定期评估"]

    E -->|额外因素| E1["基础测试"]
```

### 实现示例

```python
class ThresholdSelectionFramework:
    """ASR阈值选择框架"""

    THRESHOLDS = {
        'high_security': 0.01,      # 金融、医疗
        'medium_security': 0.05,    # 企业应用
        'low_security': 0.10        # 内部工具
    }

    def select_threshold(self, application_context):
        """根据应用上下文选择合适的ASR阈值"""

        risk_assessment = self.assess_risk(application_context)

        # 评估因素
        factors = {
            'data_sensitivity': self.check_data_sensitivity(application_context),
            'user_impact': self.check_user_impact(application_context),
            'financial_exposure': self.check_financial_exposure(application_context),
            'regulatory_requirements': self.check_regulatory_requirements(application_context),
        }

        # 多因素决策
        if (factors['data_sensitivity'] == 'high' or
            factors['financial_exposure'] == 'high' or
            'healthcare' in factors['regulatory_requirements'] or
            'finance' in factors['regulatory_requirements']):
            return self.THRESHOLDS['high_security']

        elif (factors['data_sensitivity'] == 'medium' or
              factors['user_impact'] == 'high'):
            return self.THRESHOLDS['medium_security']

        else:
            return self.THRESHOLDS['low_security']

    def configure_ci_cd_gate(self, application, threshold):
        """配置CI/CD门控"""
        return {
            'application': application,
            'asr_threshold': threshold,
            'action_on_failure': 'block_deployment' if threshold <= 0.01 else 'warn_and_notify',
            'review_required': threshold <= 0.05,
            'escalation_path': self.get_escalation_path(threshold)
        }
```

### 特殊考虑

**1. 渐进式上线**

对于初期部署，可以采用更严格的阈值，然后根据实际运行数据逐步调整：

```
第一阶段（内测）：ASR ≤ 0.02（额外严格）
第二阶段（公测）：ASR ≤ 0.05（按照等级选择）
第三阶段（生产）：ASR ≤ 最终确定的阈值
```

**2. 攻击类型加权**

不同类型的攻击风险程度不同，可以针对性地设置阈值：

```python

# 示例：按攻击危害等级加权
weighted_asr = (
    asr_illegal_instructions * 0.5 +      # 非法指令权重最高
    asr_prompt_injection * 0.3 +          # 提示注入权重次之
    asr_misinformation * 0.2               # 误信息权重较低
)
```

**3. 定期审查和调整**

ASR阈值不是一成不变的，应该根据：

* 威胁态势的演化
* 组织风险容忍度的变化
* 实际的安全事件数据
* 行业标准的更新

定期（建议每季度）进行审查和调整。