使用大语言模型保障源代码安全：从发现到修复的完整实践指南

核心问题：为什么使用大语言模型保障代码安全的关键已从发现漏洞转向验证和修补？

模型能力正在快速且不均衡地发展。在与安全团队合作寻找和修复自身代码及开源软件中的漏洞过程中，我们获得了更深入的理解：发现漏洞现在已易于并行化，而瓶颈已转移到验证、分诊和修补环节。截至2026年5月22日，在我们对开源软件的扫描中，已披露1,596个漏洞，据我们所知，其中仅有97个已被修补。这个巨大的差距清楚地表明，发现漏洞只是第一步，后续的验证和修复才是真正消耗资源和时间的环节。

本文将详细介绍如何与Claude Opus合作构建威胁模型、发现代码库中的漏洞，然后进行验证、分诊和修补。我们将分享团队如何扩展发现能力，以及在后续阶段中哪些方法最为有效。

发现并修复循环：安全工作的新范式

核心问题：如何构建一个可持续的代码安全扫描流程，避免陷入“发现大量漏洞却无法修复”的困境？

成功发现和修复最多漏洞的团队都采用了现有最佳实践的变体。我们将其提炼为六个步骤的序列：

威胁建模：在开始扫描之前确定什么算作漏洞
沙箱环境：构建隔离环境以安全运行代理并证明漏洞可利用性
发现：让模型在源代码中查找漏洞
验证：独立确认哪些发现实际上是可利用的
分诊：去重发现、分配严重性并优先处理需要修复的内容
修补：应用修复、确认漏洞已被消除并搜索变体

前两个步骤——构建威胁模型和沙箱环境——是循环的设置阶段。这些通常对每个代码库执行一次，并在底层系统发生变化时重新审视。接下来的四个步骤是针对源代码运行的循环：发现、验证、分诊和修补。

反思与见解：这种结构化的六步流程体现了一个重要转变——安全工作正从“手工发现漏洞”转向“管理和优化自动化流程”。首次运行代码库通常会产生最多的发现，后续运行往往发现较少但更复杂的漏洞，因为较简单的漏洞在之前的运行中已被修补。然而，不要期望第n次运行会有零个新发现。模型具有随机性，大型代码库可能存在一个长尾漏洞，即使代码未更改，这些漏洞也会持续涌现。

在代码库的首次迭代中，应该多次运行循环，根据净新发现数量和您对该系统的风险承受能力来决定何时停止。首次迭代后，继续（1）定期扫描或（2）每当代码发生有意义更改时扫描。

第一步：威胁建模——定义什么算作漏洞

核心问题：如何构建准确的威胁模型，避免模型因不理解信任边界而产生大量误报？

误报最常见的原因是模型对信任边界缺乏良好理解。模型可能将代码标记为易受攻击，因为它假设客户端可以发送损坏的值或攻击者可以控制配置，尽管这些输入在您的环境中是受信任的。相反，模型可能假设面向互联网的服务是仅内部的，从而低估真实漏洞。在这两种情况下，模型在威胁模型上是错误的，而不是在代码上。

实际案例：一个团队注意到其发现中的一个模式：模型在那些有良好文档记录的威胁模型、系统设计文档、需求和约束的系统上表现最好。当威胁模型定义良好时，模型的发现“90%都是可利用的”。

两步构建法

您可以与Claude合作，通过两个步骤构建威胁模型：

首先，从代码、文档和漏洞历史中进行引导。 向模型提供您会在安全工程师第一天就交给他们的内容：架构文档、wiki、入口点、git历史和过去的漏洞。这有助于克服仅从代码推断隐含知识、权衡和设计决策的挑战。然后，要求模型创建一个包含系统上下文、资产、入口点和信任边界的威胁模型。最后，让模型聚类过去的错误并列出相关的漏洞类别。确保威胁模型记录了您关心和不关心的漏洞及其原因。

实际案例：一个团队审查了数百个过去的CVE和安全修复提交，将它们提炼成“错误形状”提示，然后问模型两个问题：修复是否完整，是否在其他地方也应用了？他们在一小时内发现了三个可利用的问题。正如他们所说：“‘人们过去利用过什么’有时比‘在这个代码库中找漏洞’是更容易成功的作弊码。”

其次，让模型采访非常了解系统的人。 考虑Shostack的四个问题：我们在构建什么？可能出什么问题？我们在做什么？我们做得好吗？ 先运行引导步骤，这样被采访者就不必从零开始。这样，他们可以不用花几个小时研究和从头构建威胁模型，而是可以从草稿开始。虽然采访步骤是可选的，但它添加了模型无法从代码或文档中获得的上下文，从而改进了威胁模型。

关键实践

几个实践可以产生重大差异：

考虑依赖项的安全策略。 许多开源项目发布了安全策略。例如，vLLM的security.md、SQLite的“防御黑暗艺术”和ImageMagick的安全策略。您的威胁模型应该直接考虑它们，而不是从头重建策略。
命名什么是受信任的。 如果您信任配置文件或经过身份验证的客户端，请在威胁模型中记录。这些假设有助于将不可利用的错误与实际漏洞区分开来。
在代码中包含THREAT_MODEL.md。 将其放在仓库中并随着代码更改而更新。发现代理可以在搜索之前阅读它，跳过已知非问题。

您将在两个地方使用威胁模型。在发现阶段，作为范围：划分代码、优先考虑目标并跳过超出范围的内容。这有助于无法完全扫描的大型代码库。在分诊阶段，作为过滤器：在广泛扫描后，使用威胁模型更好地根据您的系统和环境校准严重性。

实际案例：一个扫描大型项目的团队有40%的误报率，他们深入调查原因。发现是可重现的，PoC证明了可利用性。但拥有代码的开发团队将其视为误报，因为错误不符合项目的威胁模型。另一个团队的首席信息安全官简洁地说：“[模型]对代码有很好的上下文，但对我们没有很好的上下文。”

第二步：沙箱环境——安全运行代理并验证可利用性

核心问题：如何构建既保护生产系统又能有效验证漏洞可利用性的沙箱环境？

沙箱的一个目的是保护您的系统。 为了让模型安全自主地运行，您需要强大的隔离层。没有它，代理可能超出目标并做意外的事情。

实际案例：一个团队告诉模型它没有网络访问权限——当它实际上有时——模型发现它仍然可以从GitHub获取。另一个团队观察到代理在扫描中途回答GitHub问题。这两个动作都不是恶意的，但都表明需要通过代码和配置强制执行约束。

将隔离与您的威胁模型匹配。容器对于读取代码的发现代理来说是可以的，但在微虚拟机（如Firecracker）或具有严格限制出口的完整虚拟机中运行目标和其PoC，这样任何东西都无法到达您的生产系统。永远不要让凭据（~/.aws、~/.ssh、.env）对代理可用。

仅在设置沙箱时给予网络访问权限。拉取依赖项、构建、安装工具、部署目标并运行现有测试以确认一切正常。然后，快照环境并移除其网络访问权限。在扫描期间，仅允许流量到模型API，通过本地代理路由。在每次运行开始时加载快照，这样每次扫描都从相同的干净状态开始。

沙箱的另一个目的是证明可利用性。 在静态扫描期间，模型读取代码并假设什么可能损坏，但它无法测试路径是否可达或是否存在补偿控制。因此，模型可能标记您实际上不关心的不可利用的代码正确性错误。当团队构建了一个代理可以编译代码、运行测试并引爆概念证明的沙箱时，不可利用的发现显著下降。

实际案例：一个攻击性安全团队构建了一个给代理测试床的框架，有一个简单的验证规则：只有代理能够构建概念证明并在测试床上运行它，才是真正的阳性。他们六周后的评估是“最大的效能杠杆是给模型测试床、实时系统和运行PoC。”

构建忠实沙箱的关键

在构建沙箱时，尽可能固定所有内容，以便每次运行在相同环境中使用相同的代码：镜像标签、提交SHA、依赖项和构建命令。缓存本地副本，以便构建不需要网络，并旨在使容器耐用，以便多个测试循环只需加载它。

实际案例：一个团队的扫描标记了一个漏洞，结果发现是代理下载了旧版本的库而不是实际部署的版本的副产品。这是一个阅读记录并发现正在下载不同依赖项的工程师发现的。他们现在构建Docker容器，依赖项固定以匹配生产，这样发现代理和验证代理在攻击者会使用的相同工件上操作。

重要的是构建足够忠实于生产的沙箱。排除依赖项（如队列或数据存储）可能导致低估生产中可能存在的错误。相反，忽略生产防御（如WAF或身份验证网关）会导致模型报告您的生产环境已缓解的不可利用发现。

尽管如此，如果由于云依赖、数据存储或其他现实世界复杂性而构建代表性沙箱不切实际，请从发现步骤（如下）开始。您不一定需要在沙箱中运行PoC。前沿模型仅通过分析源代码就能很好地发现漏洞。包括我们自己在内的几个团队发现这很有效。权衡在于验证阶段，如果没有运行目标，我们无法用PoC证明发现，因此要为验证预算更多时间。一旦发现量证明其合理性，您也可以稍后投资沙箱。

反思与见解：沙箱环境的构建往往被忽视，但它实际上是整个流程的基石。没有合适的沙箱，您要么冒着生产系统风险，要么无法有效验证发现的漏洞。这提醒我们，自动化安全工具的成功很大程度上依赖于基础设施的投入，而不仅仅是算法本身的优化。

第三步：发现——提供丰富上下文、简短提示和有用工具

核心问题：如何优化发现阶段，让模型能够高效、准确地识别代码库中的漏洞？

为发现代理提供可按需加载的上下文，如威胁模型、架构文档和过去扫描的结果。当代理理解您的信任边界和系统的实际部署方式时，它可以更好地识别特定于您系统的漏洞。

我们发现前沿模型在发现阶段从越来越简单的提示中受益。反直觉的是，更具规定性的提示使发现变得更糟——长检查表倾向于减少模型的创造力并生成更少的新颖错误。以下是在发现阶段有帮助的提示技巧：

提供目标和上下文。 指示“为什么”和“什么”——为什么扫描，重要的发现看起来像什么，正在扫描什么系统——并将“如何扫描漏洞”留给模型。前沿模型在安全任务上越来越擅长，过度规定可能会缩小它们尝试的范围。
尝试要求特定的漏洞类别。 如果您想根据先前的CVE或代码库语言专注于特定类型的漏洞，请说明。描述漏洞类别，它的作用以及它倾向于存在的地方，以便模型可以在您的代码库中识别它。
定义输出。 要求具有预定义字段的结构化报告，并排序它们以便模型的推理在每个字段上构建。示例字段包括理由、发现、影响、严重性等。包含一个逃生舱，以便模型可以提前退出弱发现。

给模型工具以搜索和阅读代码库，如grep、glob等。也让模型使用您的团队可能使用的特定安全工具，如SAST扫描器或模糊测试器。询问模型特定任务需要什么工具并使它们可用。最后，让模型根据需要构建工具：最近的前沿模型越来越擅长编写它们需要的工具。

实际案例：除了源代码外，一个渗透测试团队给发现代理工具发送请求、检查响应和查询流量日志。结果，代理不需要猜测路径是否可达，并且可以在运行的应用程序上测试每个候选，将他们的真实阳性率提高到接近100%。

优化发现策略

让模型对系统进行第一遍以划分搜索空间，例如按攻击面、端点或组件。然后，将这些分区提供给并行发现代理，这样它们就不会收敛到相同的浅层错误上。最后，运行一个系统级遍历，将分区级发现作为上下文来搜索漏洞。

实际案例：试图暴力发现错误的团队很快遇到递减回报。从一个团队：“我们最初尝试只是水平扩展和发送更多代理，但看到有限的回报。”另一个增加了焦点区域和并行代理的数量，并得到“大量问题”，其中大部分是彼此的重复。

如果您有运行目标的沙箱，请要求发现代理构建发现的概念证明，如脚本、崩溃输入或失败的测试。构建PoC帮助代理迭代并固定发现，并且工件为验证代理提供具体证据以评估。尽管如此，代理无法重现的发现仍然可以报告，标记为未证明，以保持高召回率。

第四步：验证——过滤掉不可利用的发现

核心问题：如何有效区分真实可利用的漏洞和误报，避免在无效发现上浪费资源？

发现优化召回；验证优化精确度。换句话说，发现应该尽可能多地找到漏洞——甚至是不太可能的漏洞——而验证应该排除实际上不可利用的发现。当代理试图在同一个步骤中做两者时，它可能会自我审查并排除可利用的真实阳性。我们艰难地学到了这一点，要求发现代理也验证发现导致它们过滤掉单独验证步骤会确认的真实阳性。

验证代理应该独立于发现代理。在没有共享文件系统或对话历史的新容器中运行验证器。如果验证器暴露于发现代理的推理，它可能只是同意而不是测试主张。因此，只给验证器（1）概念证明或书面发现和（2）代码库，以便它可以搜索发现者遗漏的缓解措施（例如，上游验证、身份验证门、类型约束或不可达代码）。

如果单次验证遍历仍然让太多不可利用的发现通过，尝试运行多个独立验证器。它们可以考虑不同角度或使用不同模型运行。然后，采取多数投票。也考虑有一个单独的裁判来决定发现和验证代理结果之间。

提示验证代理反驳发现代理的发现。让验证器假设每个发现都是误报并搜索发现错误的原因。包括验证代理可以用来确定发现是否为真实阳性的明确标准。这在发现代理的输出不包括PoC时最为重要。目标是排除尽可能多的不可利用发现，以减少手动审查的工作量。

实际案例：在我们合作的团队中，添加对抗性验证器将发现阶段的不可利用发现率大约减半。要求验证器还构建确认漏洞的概念证明将误报率降至接近零。这两步共同帮助显著减少了下游的分诊和修补负载。

如果您能够在沙箱中充分重现生产环境（参见步骤2），提示验证代理构建并执行可重现的概念证明（PoC）。如果PoC有效，您可以得出结论发现是可利用的。请注意，反过来说不成立——无法生成有效的PoC不是误报的证明。

实际案例：一个扫描开源包的团队构建了一个验证步骤来闭环：扫描包，生成概念证明，然后部署使用该包并触发PoC的模拟应用程序。他们的看法是：“验证是最大的障碍，PoC是验证。”

反思与见解：发现和验证的分离不仅仅是一个技术选择，它反映了安全工作中“创造”与“批判”的不同思维模式。当同一个代理试图同时创造性地发现漏洞和批判性地验证它们时，往往会陷入自我怀疑或过度自信。这种分离原则实际上可以应用于许多其他AI辅助任务中。

第五步：分诊——按根本原因去重，按前提条件和影响排序

核心问题：如何高效处理大量发现，避免开发团队因“漏洞疲劳”而忽视真正严重的问题？

虽然验证确认发现是可利用的，但分诊评估修补优先级。以前，当发现需要更多努力时，发现错误的工程师也会对其进行分诊。现在，随着模型能够在午餐前找到一百个候选，分诊已成为瓶颈。

适当的分诊有助于防止警报疲劳。如果您提交太多重复或严重性膨胀的错误，产品工程师可能会停止阅读它们，即使是那些需要立即修补的。开源维护者特别容易被未分诊的发现压倒，因为他们从依赖其软件的许多不同用户那里接收报告。

实际案例：多个团队分享了同样的教训：如果我们向产品工程师发送一堆发现，其中大多数是不可利用的，他们将失去对报告的信任并放弃。他们还优先考虑关键和高发现，以避免压倒下游工程师。其他团队发现通过将模型指向他们现有的积压——来自先前扫描器、先前模型、漏洞赏金接收的开放发现——并在几天内清除了数百个陈旧项目，这是一个胜利。

去重策略

要去除发现的重复，考虑根本原因。扫描器经常在多个调用站点标记一个错误或报告单个根本原因的多个症状。这里有一个实用方法：首先，使用便宜的确定性遍历：相同文件、相同类别、漏洞行号在彼此十行以内。然后，让模型对剩余内容应用定性规则：

视为重复：以不同措辞表述的相同根本原因；在多个调用站点报告的相同漏洞；在每个端点报告的缺失全局保护（如身份验证检查）；或在同一路径中标记的原因及其后果。
视为不同：同一文件中的不同漏洞类别；到达不同汇点的不同变量；一个辅助函数内的两个独立错误；两个端点上相同的缺失检查，但每个都需要自己的修复。

如果您的框架为每个发现生成PoC和补丁，另一种去除发现重复的方法是检查一个发现的补丁是否也解除其他发现的PoC。

严重性评估

去重后，基于以下因素评估每个发现的严重性：

可达性。 攻击者能否从真实入口点到达此代码，还是只能从内部代码和端点到达？
攻击者控制。 不受信任的输入是否完整到达汇点，还是上游有东西清理或约束它？
前提条件。 必须具备什么才能触发错误：非默认设置、特定功能标志、攻击者必须击中的狭窄时间窗口？
身份验证。 未经身份验证的攻击者能否触发它，还是需要登录用户或管理员？
读取与写入。 攻击者只能读取数据，还是也能修改它？
爆炸半径。 如果PoC触发，谁受影响？一个用户还是所有用户，一个租户还是平台，用户空间还是内核？

要将评分标准转换为分数，让模型在分配严重性之前写出对每个问题的答案。先通过证据可以防止模型锚定在错误类别（“SQL注入，所以关键”）然后膨胀严重性以匹配。作为起点：零前提条件且未经身份验证的远程访问是关键或高严重性。一两个前提条件，或经过身份验证的路径，是中等。三个或更多，或仅本地，是低。根据您的系统调整阈值。

模型可能因为上下文不足而膨胀严重性。它们可能不知道攻击者实际控制什么输入，或者无法看到补偿控制。作为前者的例子，如果由未经身份验证的请求触发，SQL注入是关键的，但如果由仅管理员配置文件触发，则不是问题。对于后者，防止漏洞的上游WAF或身份验证可能无法从源代码单独看到。

解决方案是在分诊期间提供威胁模型，告诉模型在您的系统中您关心和不关心哪些类型的漏洞。例如，澄清“我们信任经过身份验证的客户端”可以简化或移除一整类关键问题。

实际案例：一个团队发现模型通常过度自信，除非基于某些东西进行验证，或者对某些东西是否作为威胁模型的一部分有更多上下文。他们的修复是给分诊代理与发现代理相同的威胁模型。

第六步：修补——闭环并改进下一周期的上下文

核心问题：如何确保补丁不仅修复当前漏洞，还能防止类似问题再次出现？

修补是您闭环并修复漏洞的地方。它还有助于基于验证的发现改进威胁模型——更新信任边界或需要更多审查的组件——并将过去的发现输入到下一次扫描的上下文中。每个周期都强化代码库并使下一次扫描更有信息量。

在修补之前，编写一个用现有代码失败的新测试。然后，实现修复并确认相同的测试现在通过而不破坏任何其他东西。（是的，这是测试驱动开发）。如果不添加测试，修复可能会静默回归，并且很难事后证明错误是真实的。

实际案例：一个渗透测试人员发现他们生成的补丁不一致——有些好，有些坏——直到框架告诉模型通过在修补后的代码上重新运行概念证明来验证补丁。通过给模型反馈以迭代，补丁质量跳跃，节省了人工审查的时间。

根本原因修复与变体搜索

模型可能在特定调用站点狭窄地解决发现，而不是根本原因。简单地提示模型识别并修复根本原因可能是有效的。然后，让模型在两个级别寻找变体：（1）相同模式，在其他地方有其他调用站点或相同错误代码的副本，（2）相同类别，具有一个SQL注入漏洞的代码库往往有更多SQL注入漏洞。用验证的发现和补丁更新威胁模型以闭环。

在您发布补丁之前，运行对抗性检查。让一个新的发现代理作为攻击者探测补丁以确认补丁是全面的。然后，简化生成的补丁以解决过于侵入性的补丁。最小补丁更容易审查，不太可能引入新错误。提示进行修复根本原因的最小更改——不重构，不顺便清理，不重新格式化。

实际案例：一个团队关于他们最常见的补丁失败：“建议的补丁往往尽可能严格，到它们会断开与其他服务的连接的程度。它会解决问题，但断开允许服务首先工作的依赖关系。”

补丁验证阶梯

您可以针对一系列检查验证每个补丁，从最便宜的开始：

构建。 补丁编译并且新测试通过。
尝试重现。 原始PoC应该停止工作。这捕获无效补丁。
检查回归。 原始测试套件仍然通过。这捕获损坏或过度限制的补丁。
重新攻击。 一个新的发现代理运行对抗性检查。这捕获不完整的补丁。

最后，虽然模型可以编写补丁，但人类仍然需要拥有它。生成的补丁可能以可预测的方式失败——修复症状而不是根本原因，阻止合法输入，或移除对依赖服务的访问。目标是尽可能多地验证每个补丁，以便人工审查需要更少的努力。目标是帮助开发团队专注于模型可能不知道的细微差别（例如，即将到来的更改、代码风格），而只需要最少的审查和补丁更新。

反思与见解：修补阶段实际上是整个流程中最需要人机协作的环节。模型擅长生成补丁代码，但对业务逻辑、系统依赖和代码风格的细微理解仍然需要人类判断。这提醒我们，AI安全工具的目标不是取代人类安全专家，而是放大他们的能力，让他们从重复性工作中解放出来，专注于真正需要人类智慧的决策。

实用摘要与操作清单

核心问题：如何快速开始使用大语言模型保障代码安全，避免常见的实施陷阱？

快速启动步骤

克隆参考框架：获取defending-code-reference-harness并在Claude Code中运行/quickstart。它将引导您完成从威胁建模到扫描到分诊的交互式工作流，针对演示目标。
选择初始目标：选择一个服务或包。从代码和文档引导威胁模型，并进行采访。
投资沙箱：构建您环境的沙箱。这是前期投资最大的部分，但对后续流程至关重要。
执行首次扫描：扫描。用独立代理验证发现。基于您的标准分诊并审查所有被评为高及以上的发现。
修补并迭代：修补。然后定期重新扫描。

关键资源清单

Claude Security：Anthropic的代理漏洞检测和修补托管产品
defending-code-reference-harness：包含交互式工作流技能和自主运行演示框架的配套仓库
claude-code-security-review action：GitHub action，Claude作为每个拉取请求的安全审查者
威胁情报丰富代理：构建代理的cookbook，针对威胁情报源丰富妥协指标
漏洞检测代理：构建代理的cookbook，构建威胁模型、扫描漏洞并将发现分诊为结构化报告

常见陷阱避免

不要期望零发现：模型具有随机性，大型代码库有长尾漏洞
不要跳过验证：发现和验证必须分离，否则会自我审查
不要忽视威胁模型：没有准确威胁模型的扫描会产生大量误报
不要过度信任补丁：始终验证补丁不会破坏现有功能或依赖关系

一页速览（One-page Summary）

问题：使用大语言模型保障代码安全时，发现漏洞已变得容易，但验证、分诊和修补成为瓶颈。

解决方案：六步“发现并修复”循环

威胁建模：定义信任边界和什么算作漏洞，减少误报
沙箱环境：隔离运行环境，验证漏洞可利用性
发现：提供丰富上下文和工具，使用简单提示
验证：独立于发现，过滤不可利用的发现
分诊：按根本原因去重，基于可达性、控制、前提条件等排序
修补：测试驱动，修复根本原因，搜索变体，验证补丁

关键见解：

首次扫描发现最多，后续运行发现更少但更复杂
模型在良好文档化的威胁模型上表现最好（90%可利用率）
对抗性验证可将不可利用发现减半，要求PoC可将误报率降至接近零
最小补丁更容易审查，不太可能引入新错误

实施建议：先投资威胁模型和沙箱，预算重点放在扫描后的流程而不是更多扫描。

常见问题解答（FAQ）

Q1：如何减少大语言模型发现漏洞时的误报率？
A：构建准确的威胁模型，明确信任边界和什么算作漏洞；使用独立验证代理，要求构建概念证明；根据可达性、攻击者控制、前提条件等实际因素评估严重性，而不是仅基于漏洞类别。

Q2：是否必须建立沙箱环境才能开始使用大语言模型进行安全扫描？
A：不是必须的。前沿模型仅通过分析源代码就能很好地发现漏洞。但没有沙箱的权衡是验证阶段无法用PoC证明发现，需要为验证预算更多时间。可以在发现量证明其合理性后稍后投资沙箱。

Q3：为什么发现和验证需要由不同的代理完成？
A：当同一个代理试图同时发现和验证时，它会自我审查并过滤掉可利用的真实阳性。分离这两个过程可以保持发现的高召回率和验证的高精确度。

Q4：如何评估发现的漏洞严重性？
A：基于六个因素：可达性（攻击者能否从真实入口点到达）、攻击者控制（不受信任输入是否完整到达汇点）、前提条件（触发漏洞需要什么条件）、身份验证要求、读写权限、爆炸半径（影响范围）。先评估这些因素再分配严重性，避免仅基于漏洞类别膨胀严重性。

Q5：生成的补丁常见的失败模式有哪些？
A：三种常见失败：修复症状而不是根本原因；阻止合法输入，过度限制；断开与其他服务的依赖关系。解决方案是使用测试驱动开发，验证补丁不会破坏现有测试，并要求最小补丁。

Q6：首次扫描后应该多久进行一次后续扫描？
A：首次迭代后，继续（1）定期扫描或（2）每当代码发生有意义更改时扫描。不要期望后续运行会有零新发现，模型具有随机性，大型代码库有长尾漏洞持续涌现。

Q7：如何处理大量重复的漏洞发现？
A：两步去重：首先用确定性规则（相同文件、类别、行号在十行内）；然后用定性规则判断是否为同一根本原因的不同表现。如果生成PoC和补丁，可以检查一个补丁是否也解除其他发现的PoC。

Q8：威胁模型应该包含哪些关键信息？
A：系统上下文、资产、入口点、信任边界；明确命名什么是受信任的（如配置文件、经过身份验证的客户端）；记录您关心和不关心的漏洞类别及原因；考虑依赖项的现有安全策略而不是从头重建。

大语言模型代码安全实战：为何漏洞发现只是第一步？验证与修复才是真瓶颈