Using LLMs to Secure Source Code

标题：使用大型语言模型保护源代码

URL来源：https://eugeneyan.com/writing/secure-source-code/

发布时间：2026年5月27日

Markdown内容： 模型能力正在迅速且不均衡地发展。我们一直在与安全团队合作，帮助他们发现并修复自身代码和开源软件中的漏洞，这项工作让我们更好地理解了如何使用模型来保护源代码。我们的主要结论是：发现漏洞现在很容易并行化，瓶颈已经转移到了验证、分类和修复上。

为了说明这种差异，作为我们对开源软件扫描的一部分，截至2026年5月22日，我们已经披露了1,596个漏洞。据我们所知，其中97个已经得到了修复。

本指南将逐步介绍你如何与Claude Opus合作，构建威胁模型，发现代码库中的漏洞，然后验证、分类并修复它们。虽然我们并非拥有所有答案，但我们将分享团队如何扩展发现漏洞的规模，以及在后续阶段中有哪些帮助。_今天就可以使用附带的代码库，其中包括用于交互式工作流的技能和一个用于自主扫描的演示框架；在你阅读时，我们将指出实现每一步骤的技能。_

**查找与修复循环**

发现并修复最多漏洞的团队都采用了一种现有最佳实践的变体。我们将它们提炼为六个步骤：

1. 威胁模型： 在开始扫描之前，决定哪些情况被视为漏洞。
2. 沙箱： 构建一个沙箱环境，用于隔离代理并验证漏洞利用。
3. 发现： 让模型在你的源代码中查找漏洞。
4. 验证： 独立确认哪些发现实际上可以被利用。
5. 分类： 去重发现结果，分配严重性，并确定需要优先修复的内容。
6. 修复： 应用修复措施，确认漏洞已被消除，并搜索其他变种。

在威胁建模和沙箱构建上的一次性投资，能够推动防御循环的运行——这是一个不断重复的发现、验证、分类和修复的循环，其中瓶颈不再是发现漏洞，而是其后的所有步骤。

前两步——构建威胁模型和沙箱——是整个循环的准备工作。这些步骤通常每个代码库只进行一次，并在底层系统发生变化时重新审视。接下来的四个步骤是你将针对源代码运行的循环：发现、验证、分类和修复。

对一个代码库的首次运行通常会发现最多的问题。后续运行通常会发现更少但更复杂的漏洞，因为较简单的漏洞已经在之前的运行中被修复了。然而，不要期望第_n_次运行完全没有新的发现。模型是随机的，一个大型代码库可能会有大量漏洞，即使代码没有变化，这些漏洞也会持续出现。

在你第一次对一个代码库进行迭代时，应该多次运行这个循环，根据新发现的数量和你对该系统的风险容忍度来决定何时停止。在第一次迭代之后，继续定期扫描或在代码发生重大变化时进行扫描。

接下来，我们将详细讲解每一步，解释其重要性、产生的结果以及如何实现。

**1. 威胁模型：定义什么构成漏洞**

误报最常见的原因是模型对信任边界缺乏良好的理解。模型可能会将代码标记为存在漏洞，因为它假设客户端可能会发送损坏的值，或者攻击者可能控制配置，即使这些输入在您的环境中是 _可信的_。相反，模型可能假设一个面向互联网的服务是内部使用的，因此低估了真正的漏洞。在这两种情况下，模型对威胁模型的理解是错误的，而不是代码本身的问题。

_一个团队在他们的发现中注意到一个模式：模型在系统拥有良好记录的威胁模型、系统设计文档、需求和约束时表现最佳。当威胁模型定义良好时，模型的发现“有90%的时间是可被利用的”。_

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

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

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

其次，让模型与熟悉系统的人进行访谈。 考虑 Shostack 的四个问题：_我们正在构建什么？什么可能会出错？我们正在做什么来应对？我们做得好吗？_ 首先运行引导步骤，这样访谈者就不需要从零开始。这样，他们不需要花费数小时研究并从头构建威胁模型，而是可以从草稿开始。虽然访谈步骤是可选的，但它可以为模型提供无法从代码或文档中获得的上下文，从而改进威胁模型。

一些实践可以带来显著的差异：

• 考虑依赖项的安全策略。 许多开源项目都会发布自己的安全策略。例如，vLLM 的 `security.md`、SQLite 的 "Defense Against the Dark Arts" 以及 ImageMagick 的安全策略。你的威胁模型应直接考虑这些策略，而不是从头开始重新构建。
• 明确你信任的内容。 如果你信任配置文件或经过身份验证的客户端，请在威胁模型中记录这一点。这些假设有助于区分不可利用的错误和真正的漏洞。
• 将 `THREAT_MODEL.md` 文件包含在代码中。 将其放在仓库中，并随着代码的更改进行更新。发现代理可以在搜索前读取该文件，从而跳过已知的非问题部分。

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

_一个团队在扫描一个大型项目时，误报率高达 40%，并深入研究了原因。发现结果是可以复现的，且 PoCs 证明了可利用性。但负责代码的开发团队却将这些误判为误报，因为这些漏洞不符合项目的威胁模型。另一个团队的 CISO 简洁地总结道：“这个模型对代码有良好的理解，但对我们的情况了解不够。”_

尝试使用**威胁模型技能**。 它会逐步引导你完成本节中描述的两个步骤：bootstrap 会根据你的代码、CVE 和 git 历史生成草案，而 interview 会引导系统所有者回答 Shostack 的四个问题以进一步完善模型。输出结果是一个 THREAT_MODEL.md 文件，该文件在发现和分类步骤中使用。

**2. 沙箱：安全地运行代理并验证可利用性**

沙箱的一个目的是保护你的系统。 为了使模型能够安全且自主地运行，你需要一个强大的隔离层。没有它，代理可能会超出目标范围并执行一些意外的操作。

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

根据你的威胁模型匹配隔离级别。容器适合用于发现代理读取代码，但应在微虚拟机（如 Firecracker）或一个出站流量被锁定的完整虚拟机中运行目标及其 PoCs，以确保无法访问生产系统。而且，永远不要让代理访问凭据（如 ~/.aws、~/.ssh、.env）。

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

沙盒的另一个目的是验证漏洞的可利用性。在静态扫描过程中，模型会读取代码并推测可能出错的地方，但它无法测试某条路径是否可达，或者是否存在补偿控制。因此，模型可能会标记一些实际上并不需要关注的、不可利用的代码正确性问题。当团队构建了一个沙盒，代理可以在其中编译代码、运行测试并引爆概念验证时，不可利用的发现结果显著减少。

_一个进攻性安全团队构建了一个工具，为代理提供了一个测试环境，并设定了一个简单的验证规则：只有当代理能够构建一个概念验证并将其在测试环境中运行时，才算作真正的阳性结果。在六周后的评估中，他们认为“最大的效能杠杆是为模型提供测试环境、实际系统并运行概念验证。”_

在构建沙盒时，尽可能固定尽可能多的变量，确保每次运行都使用相同的代码和相同的环境：镜像标签、提交的 SHA 值、依赖项和构建命令。缓存本地副本，使构建过程不需要网络连接，并努力让容器具有足够的耐用性，以便多个测试循环只需加载它即可。

_一个团队的扫描发现了一个漏洞，结果发现是由于代理下载了库的一个旧版本，而不是实际部署的版本。这个错误被一位工程师发现，他在阅读转录内容时注意到下载了不同的依赖项。他们现在构建的 Docker 容器将依赖项固定为与生产环境匹配，因此发现代理和验证代理在与攻击者相同的工件上运行。_

构建与生产环境足够一致的沙盒非常重要。排除依赖项（如队列或数据存储）可能导致低估生产环境中可能存在的漏洞。相反，忽略生产环境的防御措施（如 WAF 或认证网关）会导致模型报告一些实际上已被生产环境缓解的不可利用发现。

尽管如此，如果由于云依赖、数据存储或其他现实世界的复杂性，构建一个具有代表性的沙盒不切实际，那么可以先从下面的发现步骤（discovery step）开始。你并不一定需要在沙盒中运行概念验证。前沿模型仅通过分析源代码就能有效发现漏洞。包括我们自己的团队在内的多个团队都发现这种方法非常有效。权衡在于验证阶段，如果没有运行目标，我们无法通过概念验证来证明发现结果，因此需要为验证阶段投入更多时间。你也可以在发现结果的数量足够多、值得投入时，再进一步投资构建沙盒。

请参考**harness `README.md`**``中的参考沙盒。在该实现中，代理和目标在 gVisor 隔离的容器中运行，出站流量仅限于模型 API。目标通过一个固定到特定提交的 Dockerfile 构建，`setup_sandbox.sh` 负责设置阶段。

**3. 发现：提供丰富的上下文、简短的提示和有用的工具**

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

我们在发现阶段发现，前沿模型从越来越简单的提示中受益。出人意料的是，过于具体的提示反而会降低发现效果——冗长的检查清单往往会限制模型的创造力，生成更少的新颖漏洞。以下是一些在发现阶段有帮助的提示技巧：

• 提供目标和背景。 指明“为什么”和“什么”——为什么要进行扫描、一个重要的发现是什么样子、正在扫描的系统是什么——而将“如何扫描漏洞”留给模型。前沿模型在安全任务方面越来越擅长，过于具体的提示可能会限制它们尝试的范围。
• 尝试要求特定类型的漏洞。 如果你希望专注于由先前的CVE或代码库语言指导的特定类型漏洞，请说明这一点。描述漏洞类别、它做了什么以及它通常出现在哪里，这样模型就可以在你的代码库中识别它。
• 定义输出。 要求一个结构化的报告，包含预定义的字段，并按顺序排列，使模型的推理可以逐个字段进行。示例字段包括理由、发现、影响、严重性等。包括一个退出机制，使模型可以在发现较弱的问题时提前退出。

为模型提供搜索和阅读代码库的工具，如grep、glob等。同时允许模型使用团队可能使用的特定安全工具，如SAST扫描器或模糊测试工具。询问模型完成特定任务所需的工具，并使其可用。最后，允许模型根据需要构建工具：最近的前沿模型在编写所需工具方面越来越擅长。

_除了源代码，一个渗透测试团队还为发现代理提供了发送请求、检查响应和查询流量日志的工具。结果，代理不需要猜测某个路径是否可以到达，而是可以在运行过程中逐一测试每个候选路径，从而将他们的真正阳性率提高到近100%。_

让模型对系统进行初步扫描，以划分搜索空间，例如按攻击面、端点或组件划分。然后，将这些划分结果传递给并行的发现代理，使它们不会集中于相同的浅层漏洞。最后，运行一个系统级别的扫描，利用划分级别的发现结果作为上下文来查找漏洞。

_试图进行暴力发现的团队很快就会遇到边际效益递减的问题。一个团队表示：“我们最初尝试横向扩展并发送更多代理，但发现收益有限。”另一个团队增加了关注领域和并行代理的数量，得到了“大量问题”，其中大部分是彼此的重复。_

如果你有一个可以运行目标的沙箱，请让发现代理构建一个漏洞的证明，如脚本、崩溃输入或失败测试。构建证明有助于代理迭代并明确漏洞，而该工件则为验证代理提供了具体的证据进行评估。尽管如此，代理无法复现的漏洞仍然可以报告，并标记为未经验证，以保持高召回率。

`vuln-scan`技能**`vuln-scan` skill**在这一阶段很有帮助。它会读取你的THREAT_MODEL.md，将目标划分为关注领域，并按领域分发并行的审查代理。输出结果是结构化的发现，可以直接被下一步使用。

**4. 验证：过滤掉不可利用的发现**

发现阶段注重召回率；验证阶段则注重精确率。换句话说，发现阶段应尽可能多地找出漏洞，即使这些漏洞看起来不太可能被利用；而验证阶段应排除那些实际上无法被利用的发现结果。当一个代理试图在同一个步骤中完成两者时，它可能会自我审查并排除可被利用的真实阳性结果。我们曾以一种艰难的方式学到这一点：要求发现代理也验证发现结果，导致它们过滤掉了本应由独立验证步骤确认的真实阳性结果。

验证代理应与发现代理独立。在独立的容器中运行验证器，不要共享文件系统或对话历史。如果验证器接触到发现代理的推理过程，它可能会简单地同意而不是测试该结论。因此，只给验证器提供（1）概念验证或书面发现结果，以及（2）代码库，这样它才能查找发现者可能遗漏的缓解措施（例如上游验证、授权门禁、类型约束或不可达代码）。

如果单次验证仍然允许太多无法被利用的发现结果通过，可以尝试运行多个独立的验证器。它们可以从不同角度进行分析，或使用不同的模型。然后，采用多数投票的方式决定结果。此外，还可以考虑设置一个独立的裁判，用于在发现代理和验证代理的结果之间做出判断。

提示验证代理去反驳发现代理的发现结果。让验证器假设每个发现结果是一个假阳性，并寻找该发现错误的原因。提供明确的标准，供验证代理判断该发现是否为真实阳性。这一点在发现代理的输出中没有包含概念验证（PoC）时尤为重要。目标是尽可能多地排除无法被利用的发现结果，以减少人工审查的工作量。

_在我们合作过的团队中，添加一个对抗性验证器使发现阶段中无法被利用的发现结果数量减少了一半。要求该验证器同时构建一个确认利用可能性的概念验证（PoC），使假阳性率几乎降至零。这两个步骤的结合显著减少了后续的分类和补丁处理工作量。_

如果你能够在沙盒中充分重现生产环境（参见步骤2），请提示验证代理构建并执行一个可重现的概念验证（PoC）。如果该PoC能够成功运行，就可以得出该发现是可被利用的结论。请注意，反过来并不成立——无法生成一个有效PoC并不能证明这是一个假阳性。

_一个扫描开源包的团队构建了一个验证步骤，从而形成了一个闭环：扫描包、生成概念验证，然后部署一个使用该包并触发该PoC的模拟应用。他们的看法是：“验证是最大的瓶颈，而PoC就是验证。”_

**5. 分类：按根本原因去重，按前提条件和影响排序**

虽然验证确认了一个发现是可被利用的，但分类则评估了修补的优先级。以前，当发现工作需要更多努力时，发现漏洞的工程师也会负责分类。现在，随着模型能够在午餐前找到上百个候选漏洞，分类已成为瓶颈。

正确的分类有助于防止警报疲劳。如果你提交了太多重复的或严重程度被夸大的漏洞，产品工程师可能会停止阅读这些报告，即使其中有些需要立即修复。开源维护者尤其可能因为未分类的发现而感到不堪重负，因为他们会收到许多不同用户提交的报告，而这些用户都依赖他们的软件。

_多个团队分享了相同的教训：如果我们给产品工程师一堆发现，其中大部分是不可利用的，他们会对报告失去信任并放弃。他们还会优先处理关键和高严重性的问题，以避免让下游工程师感到不堪重负。其他团队通过将模型指向他们现有的待处理列表——来自之前扫描器、之前模型、漏洞赏金收集的开放发现——在几天内清除了数百个过时的项目，取得了成功。_

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

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

如果你的框架为每个发现生成PoC和补丁，另一个去重发现的方法是检查一个发现的补丁是否也能使其他发现的PoC失效。

去重之后，根据以下因素对每个发现的严重程度进行评分：

• 可达性。 攻击者是否可以从真实入口点到达这段代码，还是只能从内部代码和端点到达？
• 攻击者控制。 不受信任的输入是否完整地到达汇点，还是上游的某些内容对其进行清理或限制？
• 前提条件。 什么条件必须存在才能触发漏洞：非默认设置、特定的功能标志、攻击者必须在短时间内触发的狭窄时间窗口？
• 身份验证。 未认证的攻击者是否可以触发它，还是需要登录用户或管理员？
• 读取与写入。 攻击者只能读取数据，还是也可以修改它？
• 影响范围。 如果PoC触发，谁会受到影响？一个用户还是所有用户，一个租户还是整个平台，用户空间还是内核？

为了将评分标准转化为分数，让模型先回答每个问题，然后再分配严重程度。首先查看证据可以防止模型锚定在漏洞类别上（“SQL注入，所以严重”），然后夸大严重程度。作为起点：没有前提条件且存在未认证远程访问的漏洞，属于严重或高严重性。一个或两个前提条件，或经过身份验证的路径，属于中等严重性。三个或更多前提条件，或仅限本地的漏洞，属于低严重性。根据你的系统调整这些阈值。

模型可能会夸大漏洞的严重性，因为它们缺乏足够的上下文信息。它们可能不知道攻击者实际控制了哪些输入，或者无法看到补偿性控制措施。例如，如果一个 SQL 注入漏洞是由未认证的请求触发的，那么它是一个关键问题；但如果是由仅管理员可访问的配置文件触发的，那可能就不是问题。对于后者，上游的 WAF 或认证机制可能阻止了攻击，但仅凭源代码是看不到这些防护措施的。

解决方法是在排查过程中提供一个威胁模型，告诉模型在你的系统中哪些类型的漏洞是需要关注的，哪些是不需要关注的。例如，明确说明“我们信任已认证的客户端”可以简化甚至消除一类关键漏洞。

_一个团队发现，除非模型有可以验证的依据，或者对威胁模型中某些内容是否属于预期有更多上下文信息，否则模型往往过于自信。他们的解决办法是让排查代理获得与发现代理相同的威胁模型。_

尝试使用**`triage` 技能**。 它同时执行验证和排查：对每个发现进行多投票验证，跨运行去重，并根据推导出的可利用性重新排序。输出是一个简短、排序、明确归属的列表，而不是原始数据的转储。

**6. 修复漏洞：闭环并提升下一轮的上下文信息**

修复漏洞是闭环并解决漏洞的关键步骤。它也有助于根据已验证的发现来改进威胁模型——更新信任边界或需要更多审查的组件，并将过去的发现作为下一次扫描的上下文信息。每一次循环都会使代码库更加稳固，并为下一次扫描提供更丰富的信息。

在修复漏洞之前，先编写一个新测试，该测试在现有代码下会失败。然后，实现修复并确认同样的测试现在通过，且没有破坏其他任何功能。（是的，这就是测试驱动开发。）如果你不添加测试，修复可能会悄然退化，而很难事后证明漏洞确实存在。

_一位渗透测试人员发现，他们生成的补丁不一致——有些好，有些坏——直到框架告诉模型通过重新运行概念验证来验证补丁是否有效。通过给模型提供反馈以进行迭代，补丁质量显著提高，节省了人工审查的时间。_

模型可能会仅仅针对某个特定调用点的发现进行修复，而不是根本原因。简单地提示模型识别并修复根本原因可能是有效的。然后，让模型在两个层次上查找变体：（1）相同模式，即其他调用点或代码库中其他位置的相同错误代码；（2）相同类别，即一个存在 SQL 注入漏洞的代码库往往会有更多 SQL 注入漏洞。使用验证后的发现和补丁更新威胁模型，以实现闭环。

在发布补丁之前，运行一次对抗性检查。让一个新的发现代理以攻击者身份探测补丁，以确认补丁是否全面。然后，简化生成的补丁，以处理过于侵入性的补丁。最小的补丁更容易审查，也不太可能引入新的错误。提示模型进行最小的更改以修复根本原因——不进行重构，不进行随手清理，不进行格式调整。

_一个团队在他们最常见的补丁失败案例中提到："推荐的补丁往往尽可能严格，以至于会破坏与其他服务的连接。虽然这可以解决当前的问题，但会破坏服务最初正常运行所依赖的依赖关系。"_

你可以通过一系列检查来验证每个补丁，从最简单的开始：

1. 构建。 补丁可以编译，并且新的测试通过。
2. 尝试复现。 原始的PoC应该停止工作。这可以发现无效的补丁。
3. 检查回归问题。 原始测试套件仍然通过。这可以发现损坏或过于严格的补丁。
4. 重新攻击。 一个全新的发现代理运行对抗性检查。这可以发现不完整的补丁。

最后，虽然模型可以生成补丁，但仍然需要由人来负责。生成的补丁可能会以可预测的方式失败——只解决症状而非根本原因，阻止合法输入，或者移除对依赖服务的访问。目标是尽可能多地验证每个补丁，从而减少人工审核所需的工作量。目标是帮助开发团队专注于模型可能不了解的细节（例如即将到来的更改、代码风格），并且只需最少的审核和更新即可。

尝试使用**`patch` 技能**。 它会使用分类结果，为每个发现生成一个候选的差异补丁，并由一个独立的审核代理检查每个补丁。

**入门指南**

亲自尝试运行这个流程。克隆 `defending-code-reference-harness` 并在 Claude Code 中运行 run /quickstart。它会引导你完成一个交互式的工作流程，从威胁建模到扫描再到分类，针对一个演示目标。该仓库还包含一个自主的测试框架和一个 /customize 技能，用于根据你的环境更新测试框架。

然后，在你自己的代码上运行它。选择一个服务或包。从代码和文档中引导生成一个威胁模型，并完成访谈。投入精力构建一个你环境的沙箱。进行扫描。使用一个独立代理验证发现的问题。根据你的标准进行分类，并审核所有评分较高的结果。生成补丁。然后定期重新扫描。

你的第一次扫描会发现比你预期更多的问题。大多数问题都需要验证和分类。在预算更多扫描之前，先为扫描后的流程分配预算。

一些你可能会发现有用的资源：

• Claude Security: Anthropic 的托管产品，用于智能代理的漏洞检测和修复。
• `defending-code-reference-harness`: 一个配套仓库，包含用于交互式工作流程的技能和用于自主运行的演示框架。
• `claude-code-security-review action`: 一个 GitHub Action，可在每次拉取请求中使用 Claude 作为安全审查者。
• Threat Intelligence Enrichment Agent: 一个食谱，用于构建一个代理，该代理可以利用威胁情报源来丰富入侵指标。
• Vulnerability Detection Agent: 一个食谱，用于构建一个代理，该代理可以构建威胁模型、扫描漏洞，并将发现结果整理成结构化报告。

**Moving forward**

我们认为，模型在代码中 发现和利用漏洞 的能力正在变得越来越强。因此，我们的职责是作为防御者，在攻击者利用这些漏洞之前，找到并修复代码中的漏洞。一些团队甚至已经将他们的框架连接到事件中，例如，漏洞赏金报告会触发自动变体分析，安全审查会触发扫描并附上候选发现结果，或者确认的漏洞会更新静态分析工具，以防止未来再次出现。

这项工作至关重要且风险极高。但如果正确执行，它将是迈向更大、更乐观转变的开端，即我们能够 _在攻击者利用漏洞之前_ 找到并修复这些漏洞。

如果您想了解我们关于网络安全工作的最新动态，请在此处 **订阅** 我们的邮件列表。

**Acknowledgements**

由 Eugene Yan 和 Henna Dattani 撰写，Michael Molash、Abel Ribbink、Justin Young、Ben Morris、David Dworken 和 Hasnain Lakhani 提供了贡献。这项工作基于我们在 Anthropic 使用模型进行安全工作的经验，以及我们的合作伙伴和客户分享的宝贵见解，对此我们深表感激。