开发团队根据您的红队报告实施了补救措施后,本次行动尚未完全结束。接下来的重要一步是复测并验证所施行的修复措施是否有效解决了已报告的漏洞,同时未引入新问题。这一验证环节是确认大型语言模型安全态势确实有所提升的重要一环。可以将其视为对您已细致识别和记录的漏洞进行闭环处理。复测的目的复测不仅仅是简单检查原始利用方式是否仍然有效。它的目标更为全面:确认修复效果: 主要目标是验证开发团队施行的缓解措施是否成功阻止了所报告的特定漏洞。识别修复不足之处: 有时,修复可能只解决了漏洞的表象而非其根本原因,或者只涵盖了所演示的精确利用路径。复测旨在查看原始攻击的微小变动能否绕过修复。发现回归问题: 安全修复,像任何代码改动一样,可能会无意中引入新漏洞或破坏现有功能。在此阶段进行回归测试有助于发现此类意外后果。确认抵御能力: 一个好的修复措施应运行良好。复测有助于评估修复措施在面对修改后的攻击技术时的抵御能力。规划您的复测工作在进行复测前,做好规划可确保效率和全面性。了解修复方案: 与开发团队协作,了解所实施修复措施的性质。了解漏洞是如何被假定修复的(例如,输入清洗、模型安全微调、输出过滤修改),将指导您的复测策略。这是一项针对特定提示的狭义修复,还是一项更广泛的架构改动?确定优先级: 侧重于已报告为已修复或已缓解的漏洞。已处理的高影响漏洞应置于复测列表的首位。回顾初始发现: 重新熟悉您的原始报告,包括重现漏洞的精确步骤、所使用的提示词以及观察到的LLM行为。大型语言模型的复测方法您的复测方法应系统化。以下是您可以如何着手:重现原始攻击: 这是第一步也是最直接的步骤。尝试使用您初始报告中记录的完全相同的方法、提示词和条件来重现漏洞。如果原始攻击仍然有效,则说明修复无效,需要明确传达这一点。测试修复的稳固性并寻找绕过方法: 如果原始攻击被阻止,下一步是测试修复的抵御能力。攻击者很少在第一次尝试后就放弃。细微变动: 修改您的原始攻击提示词。如果提示注入通过阻止特定关键词得到缓解,请尝试使用同义词、转述或字符编码技巧(例如,如果适用于输入处理,可使用Unicode等效字符)。例如,如果“ignore previous instructions”被阻止,请尝试“disregard earlier directives”或“your prior commands are now void”。语境变动: 如果漏洞与特定对话语境相关,尝试通过不同的对话路径达到类似的易受攻击状态。边界条件: 测试接近修复设计处理能力临界点的输入。回归测试: 对一个漏洞的修复不应为其他问题敞开大门。检查相关功能: 如果修复涉及为安全目的修改输入处理,请测试合法的、安全的输入现在是否被错误地拒绝或误解。例如,旨在防止有害内容生成的严格输入过滤器,如果实施不慎,可能会无意中阻止与敏感话题相关的良性查询。抽查: 对其他功能进行快速检查,特别是那些可能与已修复区域共享代码或逻辑的功能,以确保它们未受到负面影响。(有选择地)重新运行广泛测试: 如果修复措施影响重大或触及了LLM的核心处理组件,请考虑重新运行您初始广泛测试用例的一小部分。验证修复的完整性: 确保修复解决了根本问题,而不仅仅是您提供的特定示例。如果越狱漏洞通过阻止特定角色得到修复,请尝试其他角色或扮演情景,以达到类似结果。如果数据泄露漏洞针对某一种敏感信息打上了补丁,请检查LLM可能访问的其他类型的敏感数据是否仍能通过类似或不同的方式被窃取。分析并报告复测结果复测完成后,您需要记录并传达结果:成功: 漏洞确认已修复,您尝试绕过修复的努力均未成功。未发现回归问题。这是理想结果。部分修复: 原始报告的利用方式被阻止,但您发现变种或相关利用方式仍有效。修复不全面。无效修复: 原始漏洞仍可被利用。修复没有明显效果。回归问题: 对原始漏洞的修复引入了一个或多个新漏洞或破坏了现有功能。复测报告是验证修复的主要文档。对于所验证的每个漏洞,应在报告中明确说明:漏洞的标识符或描述。开发团队实施的修复概要(如果已知)。所采取的复测步骤(包括任何新的提示词或使用的技术)。结果(成功、部分修复、无效修复、回归问题)。支持结论的证据(例如,LLM响应、错误消息)。如果发现新问题(回归问题),应以与初始评估中新发现相同的严谨度进行记录,包括严重性和潜在影响。迭代复测周期复测发现修复不完全正确的情况并不少见。在这种情况下,过程将变为迭代式:您报告复测发现,开发团队着手修订修复,然后您再次进行复测。digraph G { rankdir=TB; node [shape=box, style="filled", fillcolor="#e9ecef", fontname="sans-serif"]; edge [fontname="sans-serif"]; vuln_id [label="漏洞已识别", fillcolor="#ffc9c9"]; report_vuln [label="报告漏洞", fillcolor="#ffd8a8"]; dev_fix [label="开发团队实施修复", fillcolor="#a5d8ff"]; retest [label="红队复测修复", fillcolor="#b2f2bb"]; fix_verified [label="修复已验证并关闭", fillcolor="#96f2d7"]; report_retest_fail [label="报告复测失败 / 回归问题", fillcolor="#ffa8a8"]; vuln_id -> report_vuln; report_vuln -> dev_fix; dev_fix -> retest; retest -> fix_verified [label=" 成功"]; retest -> report_retest_fail [label=" 修复失败 / \n发现回归问题"]; report_retest_fail -> dev_fix [label=" 开发修订修复"]; }红队补救和复测过程通常涉及一个迭代周期,直到漏洞得到充分处理。这个协作循环会持续进行,直到漏洞被有效缓解到可接受的风险水平。有效的复测建立了对安全改进真实且有抵御能力的信心。它还通过展示对确保修复成功实施的承诺,增强了红队工作的价值。最后,请记录您的复测程序和发现的任何新颖绕过技术。这有助于丰富您团队的知识库,并提高未来复测工作的效率。