红队报告完成并详细说明了可行的缓解步骤后，重点将转向直接与负责实施这些修复的开发团队合作。这不仅仅是移交一份文档。它旨在培养一个合作的环境，让红队的发现能够转化为大型语言模型（LLM）系统的实际安全改进。有效的合作是任何红队行动成功的主要因素。
培养富有成效的伙伴关系
在此阶段，红队与开发团队之间的动态会发生变化。在测试期间，你的角色是对抗性的，积极寻找弱点。现在，重点转变为伙伴关系。两个团队有一个共同目标：提高LLM应用程序的安全性。以支持性顾问的心态对待这些交互。你的目标是帮助开发团队了解漏洞，并帮助他们构建更安全的软件。
准备开展合作
在与开发团队会面之前，请确保做好充分准备：
- 清晰是核心：仔细检查你的报告，特别是漏洞描述和缓解建议，确保其清晰、简洁，并易于非LLM安全专家背景的开发人员理解。
- 确定联系人：了解开发团队内部的主要联系人是谁。这通常包括技术负责人、工程经理或负责受影响组件的特定开发人员。
- 内部统一：如果有多名红队成员参与，请确保你方所有成员对调查结果和要传达的重要信息达成一致。
修复启动会议
专门的启动会议通常是启动修复流程的理想方式。
- 目的：主要目标是引导开发团队回顾最重要的发现，解释潜在影响，讨论你建议的缓解措施，并回答他们的初步问题。这不仅仅是一场演示，更是一次讨论。
- 参会人员：通常包括相关的红队成员、开发团队负责人、主要开发人员，有时还包括需要了解风险和资源影响的产品负责人或经理。
- 议程：
- 简要重申红队行动的范围和目标。
- 列出优先级高的漏洞清单，首先关注高影响的漏洞。
- 对于每个主要发现，解释攻击场景，如果可能，呈现其影响（不引起恐慌），并讨论根本原因。
- 开放提问和讨论。
- 概述提议的缓解策略，强调这些是建议，并乐意讨论替代方案。
有效解释LLM特有漏洞
开发团队擅长构建软件，但他们可能对LLM带来的风险不甚熟悉。诸如间接提示注入、某些类型的数据投毒或复杂的越狱技术等漏洞可能显得抽象。
- 使用清晰语言：尽可能避免过于技术化的行话。如果必须使用特定术语，请加以说明。
- 具体实例：将漏洞与实际、易懂的攻击场景联系起来。例如，与其仅仅说“提示注入”，不如解释它如何导致LLM泄露敏感用户数据或生成有害内容。
- 侧重影响：帮助他们理解某个漏洞为何对他们的应用和用户重要。将其与业务风险、用户信任或操作稳定性关联起来。
合作讨论缓解策略
尽管你的报告包含建议，但开发团队拥有代码库，并且对系统了解最透彻。
- 扮演顾问角色：将你的缓解建议作为讨论的起点。
- 集思广益寻求方案：鼓励开发团队提出自己的解决方案或对你的建议进行修改。他们可能会发现你未曾考虑过的限制或替代方法。
- 权衡利弊：讨论不同缓解方案的优点和缺点。这包括实施工作量、潜在性能影响、对用户体验的影响以及剩余风险程度。例如，一个非常严格的输入过滤器可能会阻止某些攻击，但也可能降低LLM处理合法查询的可用性。
- 指导而非命令：你的角色是确保所选解决方案有效解决漏洞。如果他们提议的解决方案不充分，请清楚解释原因，并引导他们采取更妥善的方法。
提供持续支持和澄清
修复很少是一次性工作。开发团队在设计和实施修复时可能会遇到问题。
- 保持可联系性：随时待命，解答疑问、审查提议的代码更改（如果达成一致），或对漏洞进行进一步澄清。
- 快速响应：及时响应可以避免延误修复流程。
- 迭代过程：有时，首次修复尝试可能不完美。请准备讨论迭代和改进。
以下图表展示了红队和开发团队在修复阶段的一般交互流程：
此图表展示了典型的修复交互周期，突出了红队和开发团队的不同阶段，以及他们的共同努力。
促进知识传递
除了修复单个缺陷，此次合作的一个重要成果是帮助开发团队培养他们对LLM安全的理解。
- 解释“为什么”：帮助他们理解漏洞背后的根本原因和模式。例如，如果发现多个提示注入点，请讨论LLM输入处理的一般原则。
- 分享资源：引导他们查阅相关的文章、文档或工具，这些可以帮助他们理解和未来的开发实践。
- 培养安全倡导者：如果可能，识别开发团队中热衷于安全的个人，他们可以作为内部倡导者。
设定重新测试的预期
有必要沟通清楚，一旦修复部署，红队将重新测试以验证其有效性。这设定了清晰的预期，并强化了安全的迭代性质。本主题将在下一节“重新测试和验证修复”中详细介绍，但其基础工作是在这些合作会议中奠定的。
处理分歧
偶尔，可能会出现关于发现的严重程度、缓解措施的可行性或资源分配的分歧。
- 保持专业和客观：你的论点应基于数据、风险分析和潜在影响。避免情绪化反应。
- 努力理解：如果开发团队提出异议，尝试理解他们的理由。可能存在你不知道的技术限制或业务优先级。
- 寻找共同点：寻求在解决安全风险的同时，尽可能尊重开发团队限制的解决方案。
- 必要时上报：如果重大风险无法通过直接讨论解决，可能需要预定义的升级路径（通常涉及双方管理层），但这应作为最后的手段。
建立长期关系
成功的修复工作可以建立信任，并将红队定位为有价值的伙伴，而不仅仅是审计者。鼓励将安全视为共同责任的文化。这种合作方法从长远来看可以使LLM系统更安全，因为开发团队将更善于主动识别和缓解潜在问题。
通过与开发团队紧密而建设性地合作，你将红队发现从一系列问题转化为促进真正安全改进的催化剂。这种合作精神对于提升组织LLM安全态势的成熟度非常重要。
