安全评审只有在所产生的需求在整个开发过程中保持可见时才有价值。我们的工程师希望确保这些需求在开发过程中持续得到贯彻，同时也能识别出任何差距。

Dropbox 如何利用 MCP 和 Dash 弥合设计与代码之间的安全鸿沟

来源：https://dropbox.tech/security/dropbox-mcp-dash-design-code-security?utm_source=x&utm_medium=social&utm_campaign=tech&utm_content=dropbox-mcp-dash

每个安全团队都熟悉这样的流程：一个新功能经过设计评审，生成威胁模型，商定缓解措施，然后开发开始。在许多情况下，当实现进入代码审查阶段（即工程师在代码上线前审查变更的过程）时，最初的安全需求在工作流中已不再可见。威胁模型（概述了潜在安全风险以及功能应包含的保护措施）通常存在于与代码本身分离的独立文档或系统中。

这种分离带来了挑战。实现往往发生在原始安全评审数周或数月之后，这使得审查者难以验证商定的安全需求是否真的得到了实现。在 Dropbox，我们想了解这种差距在实践中出现的频率。

这促使我们构建了一个结合三种技术的系统：模型上下文协议（Model Context Protocol）、基础大语言模型（我们将称之为基础模型），以及 Dash（Dropbox 内的 AI 能力，使查找和理解团队内容更加容易）。通过协同工作，这些技术能在代码审查期间自动检索相关的威胁模型，并评估代码变更是否与其中定义的需求一致。因为 Dash 已经为存储在 Dropbox 及我们连接的应用中的内容建立了索引并实现了互联，该系统可以借鉴多年的安全评审和工程文档，而无需团队手动将这些来源链接起来。

在这篇文章中，我们将介绍该系统背后的架构，分析数月威胁模型后得到的经验，以及我们认为相同的模式如何应用于其他形式的设计和合规评审。

设计与代码之间的鸿沟

组织在产品发布前很久就会做出重要决策——例如关于威胁防护的决策。话虽如此，安全评审只有在所产生的需求在整个开发过程中保持可见时才有价值。我们的工程师希望确保这些需求在开发过程中持续得到贯彻，同时也能识别出任何差距。

在安全评审期间，工程师会识别潜在风险，讨论某个功能可能如何被利用，并商定该功能应包含的保护措施。这些决策会记录在威胁模型中。但开发开始后，这些决策往往与代码本身脱节。威胁模型存在于 Wiki 或文档系统中，而代码则通过拉取请求（PR，工程师在变更合并到产品前提交审查的工作单元）来实现。除非有人明确将它们关联起来，否则审查者可能永远看不到之前商定的安全需求。

在 Dropbox，我们维护着跨越多年产品开发的威胁模型文档。每一份都代表着数小时的安全工程工作，但只有当审查者在实现阶段能够访问这些文档时，这些工作才能持续创造价值。为了解这种关联的持续性，我们研究了威胁模型与其所描述功能对应的实现 PR 之间的关系。通过调查，我们发现只有 12% 的实现 PR 回溯到了原始设计评审和威胁模型。

这种差距因评审与实现之间的时间间隔而进一步加剧。当我们测量 79 个已验证配对的设计评审归档与 PR 创建之间的时间间隔时，发现超过一半（54%）的实现 PR 是在评审归档一个多月后才打开的。中位延迟约为五周，长尾部分甚至超过 11 个月。只有 29% 的实现 PR 是在安全评审后的头两周内打开的。

换句话说，从安全需求定义到相应代码审查之间可能存在长时间的延迟。等到审查者审视实现时，安全评审期间做出的决策可能已经埋藏在他们从未打开的文档里了。

为什么现有工具无法解决这个问题
一旦我们了解了差距的规模，下一个问题就是现有安全工具能否弥合它。例如，静态分析工具会检查代码中的已知模式和潜在问题，但它们只能告诉你某个安全控制是否存在。它们无法告诉你该控制是否按照设计评审期间商定的需求来实现。它们分析的是代码本身，而不是其背后的上下文或意图。

组织通常尝试通过要求工程师将代码变更链接到设计评审，或部署机器人提醒开发者遵循评审流程来解决这个挑战。但这些方法依赖工程师记住额外的步骤，而随着时间的推移，合规性往往会下降。缺少的是一种将代码变更与已有的安全指导连接起来的方法。我们意识到问题不在于缺乏安全知识。大多数组织已经通过威胁模型投入了大量精力来记录风险和缓解措施。挑战在于如何在代码审查时让这些知识变得可用。

我们的数据还提示了另一个机会。大约 15% 的设计评审是事后归档的，即代码先构建好，安全评审随后才进行（通常是在更广泛发布之前）。这些情况表明，某些安全敏感的工作在实现时并不总是被识别为需要评审。一个能够在开发过程中（而非事后）呈现相关安全上下文的系统，可以在两个方向上提供帮助：将代码与现有评审连接起来，并在需要额外评审时提供早期信号。

使用 Dash 和 MCP 作为上下文桥梁

我们需要一种方法，将正在审查的代码与组织中其他地方已有的安全指导连接起来。Dash 提供了一个自然的起点。由于它对跨连接应用的内容建立了索引，我们收集的威胁模型已经可以与其他工程文档一起被搜索到。我们不是依赖审查者去寻找正确的安全文档，而是构建了一个系统，在代码提交审查时自动检索相关的威胁模型。

模型上下文协议（MCP）让代理能够访问所需的信息。Dash 有一个 MCP 服务器，使其索引的内容可供其他 AI 工具使用。在我们的案例中，安全审查代理利用 Dash 的 MCP 服务器来搜索和读取与 Dash 搜索相同的已连接内容，包括威胁模型和相关文档。这为代理提供了所需的上下文，而无需为每个源系统进行自定义集成。

.png/_jcr_content/renditions/Diagram%201%20(5).webp)MCP 将多个上下文源组合成单个代理会话。模型在它们之间进行推理，以识别安全需求与实现之间的差距。

当代码变更被提交审查时，代理通过 MCP 检索相关的威胁模型和其他支持性上下文。基础模型随后可以同时检查记录的需求和提议的代码变更。例如，它能识别出威胁模型要求在端点上进行身份验证，并判断引入的代码是否真正执行了该要求。

这种跨多个信息源进行推理的能力，正是这种方法与传统静态分析的区别所在。系统不仅是在检查代码，而是在将实现与先前记录的安全决策进行比较。

在开发者工作的地方满足他们
与检索架构同样重要的是我们呈现结果的位置。我们没有创建独立的安全工作流，而是将系统直接集成到代码审查中。工程师在代码合并前会进行审查，因此我们专注于将额外的安全上下文带入一个已有的流程。

这种区别很重要，因为安全团队多年来一直在构建生成警报、注释和通知的工具。反过来，开发者多年来也学会了哪些可以安全忽略。有用安全信号与噪音之间的区别在于相关性。一个与正在审查的代码直接相关的问题，远比每个变更上都出现的泛泛警告更有用。

与此同时，检索到威胁模型只是第一步。简单地把一份安全文档放到代码审查旁边，仍然需要人工阅读两者并判断它们是否一致。基础模型自动进行这种比较，识别记录需求与实现之间的潜在差距。人工审查者仍然负责最终判断，但模型消除了大量原本需要手动交叉引用工作。

实现设计与代码的可追溯性

为了验证这种方法，我们分析了我们在过去一年半中的所有 150 份安全设计评审，并将每份映射到其实现的代码变更。为此，我们使用了 Dash 的语义搜索功能，该功能基于含义而非精确关键词或显式引用来检索相关内容。连接是存在的，但它们往往不可见：

• 利用 Dash 的语义搜索（与支撑其面向用户搜索相同的检索能力），我们成功将 80% 的设计评审链接到了其实现的代码变更
• 这些代码变更中只有 12% 显式引用了设计评审
• 69% 的连接仅能通过语义搜索恢复，这意味着设计评审与实现之间的大部分关系如果仅靠手动引用将是不可见的

我们还评估了在代码审查期间呈现威胁模型上下文的效果。在我们的测试中，上下文检索持续发现了没有威胁模型时不可见的安全问题，包括缺失的控制、与已批准设计相矛盾的情况，以及对已知风险的回归。在每种情况下，代码功能上都是正确的。只有当审查者能够比较实现与原始需求时，这些差距才显现出来。

更重要的是，当我们检查安全事件时，我们发现了这样的情况：根本原因是在设计评审期间已被记录但未在实现代码中强制执行的安全需求。连接是存在的，只是恰好在关键时刻不可见。这些并非罕见的边缘情况。它们是在开发过程中与实现脱钩的直截了当的需求。

这就是审查代码与对照设计审查实现之间的区别。前者捕获错误。后者捕获安全漏洞。而只有当模型能够推理两个文档（威胁模型和拉取请求）之间的关系，而不是孤立分析任何一个时，这种对照才成为可能。

设计原则及下一步计划

随着我们将此集成到开发工作流中，我们围绕几个核心原则进行设计。在发现问题到达开发者之前，必须针对实际代码进行验证，因为误报比真报更快地摧毁信任。每个问题都应能追溯到特定的需求和源文档，以便审查者自己验证推理过程。大多数问题应作为建议而非阻塞，只有针对已批准设计与实现之间的确认差距才升级处理。而且，由于需求会随时间演变，系统必须考虑过时的上下文，而不是盲目应用过时的指导。

该架构也并非安全领域所独有。它是一个通用解决方案，适用于任何制定设计文档并需要验证其在实现中得到反映的团队。例如，隐私团队可以在代码涉及用户数据流时呈现数据分类需求。指定某个字段不得记录的隐私评审，可以对照将来处理该字段的代码变更进行检查。平台团队可以在接口变更时呈现 API 契约和兼容性需求。合规团队可以在代码处理受监管司法管辖区数据时呈现监管要求。

其中的通用模式很直接：组织已经记录了需求，但这些需求往往与做出实现决策的工作流脱钩。通过结合可搜索的组织知识、基于 MCP 的检索以及能够跨多个上下文源推理的基础模型，可以自动将实现与意图进行比较。

扫描工具和威胁模型已经存在。但我们缺少的是在正确时刻将它们连接起来的方法。MCP 使得这种连接在技术上可行。Dash 使之变得实用。而基础模型使之有用，将“这里有一份相关文档”转变为“这里是需求与实现之间的具体差距”。虽然安全是我们的首个用例，但同样的模式可以帮助任何团队确保在规划和评审期间做出的决策能够反映在他们最终构建的系统中。

致谢：Wei Dai, Jan Nunez, Nicholas Plewtong, Jonathan Hawes, Po-Ning Tseng, Adrian Wood, Steven Kisely, Adam Pindelski, Qingbo Jiang, 以及 Dash 团队。

~ ~ ~

如果你对构建创新的产品、体验和基础设施感到兴奋，欢迎加入我们，共同塑造未来！请访问jobs.dropbox.com (https://jobs.dropbox.com/) 查看我们的空缺职位。