GitHub：我们如何进行威胁建模_安全_Robert Reichel

AIGC在金融场景是如何落地的？了解详情 



 写点什么

在 GitHub，我们花了很多时间思考并构建安全产品，其中一个关键的方面就是威胁建模。在这类实践中，我们让安全团队与工程团队齐聚一堂来讨论系统，最终生成改善系统安全性的执行项目。威胁建模可以促进安全团队与工程团队进行沟通，令安全审查进程更具有主动性，并使得系统的设计更可靠也更安全。

什么是威胁建模？

在进一步讨论威胁建模的方法前，我们先要统一一下理解。定义进程的目标，有助于让大家对结果建立预期。

在 GitHub，威胁建模未必是指某个特定的工具或交付成果，而是一种过程，它会促进安全团队与工程团队就现有系统或新系统进行讨论。威胁建模是一种安全协作实习，协助我们针对新服务或已有服务，进行设计及任务计划的评估与验证。该实习涉及了在思考对服务可能产生负面影响的潜在安全漏洞时，所需要用到的结构化思维。

每个威胁建模的对话都应当至少包含下列目标：

首先，针对提议或已有的架构进行深入研究，确保所有人都理解系统的运作原理（如果没有其他问题，这就行了。请用文档记录下来运作原理）；
然后，针对整体全局进行评估，找出最可能的漏洞点。这些就是关键的交付内容；
为每个漏洞点设计可执行的修复方案。由于每个人的资源都不是无限的，很可能要安排优先级。

我们的威胁建模过程是怎么样的？

决定何时进行威胁建模

在 GitHub，我们通常会在任何对架构产生重大改变的新功能发布前，以特定节奏针对各个功能团队进行威胁建模。根据单个功能所需的工程量，你可能需要加快节奏（每隔两个月）或放慢节奏（每年一次）。如果软件审查已经设定了节奏，根据我们的发现，将其与那些已有的进程集成，有助于让大家适应新安全进程的添加。无论时间表如何，请设置指导并在实践中灵活应用。

构建威胁模型

威胁建模通常属于协作实习，因此，产品的工程团队及安全团队会聚在一起，讨论整个架构以及潜在的安全问题。我们的安全团队会预先将有效威胁建模的文档与案例提供给工程团队。我们通常要求各个工程团队提前生成模型，并涵盖系统的重要部分，作为单个的威胁建模对话来审查。提早设立这些预期（并提前预习）有助于确保会议的效果。

不过相较于特定的输出成果，这些进程和讨论更重要。在 GitHub，我们要求工程团队以微软的威胁建模工具，或开放 Web 应用程序安全项目（OWASP）的威胁建模工具 Threat Dragon（两个都是免费的！）输出威胁模型。这些工具让团队能清晰呈现威胁模型的重要信息，如 API、信任边界、依赖关系、数据存储、身份验证机制等。除了协助团队保持一致性之外，需要遵守各种安全性要求时，这些文件也能作为重要的附属内容共享给审计人员。

审查威胁模型

当审查威胁模型时，我们通常会安排一小时的会议，并将其分为两部分。每个会议的前 5-10 分钟，用来帮助工程团队理解要审查的系统的设计。这个时间段，要确保所有人的理解达成一致，将准备好的威胁模型拿出来，澄清所有存在歧义的部分，包括要使用的技术，以及任何设计习惯。在所有人都达成一致后，我们可以跳至安全讨论环节。

在安全讨论环节，我们发现：使用框架来系统处理不同的漏洞类很有效。我们经常使用的方法之一是微软的 STRIDE 模型，即欺骗、篡改、抵赖、信息披露、拒绝服务、特权提升，这是一种包含了可能在应用中发现的常见攻击向量的记忆方法。在查看总体系统时逐个检查这些类，使得安全团队能以整体方式查看正在分析的系统，并确保能涵盖最常见的威胁。谈话深入，用 STRIDE 填满提醒事项会占据大半的会议时间，然后再确认系统的更多部分。

当发现潜在的安全漏洞或设计缺陷时，安全团队会将它们与潜在的修复方案一并记录下来，从而为工程团队生成一张潜在变更的列表，留待会议后完成。我们发现，随着威胁建模成为整个 GitHub 更常见的做法，各个团队都更习惯在开发系统的阶段就让安全团队介入——这样效果更好，有助于在敲键盘前，提前发现潜在的问题，确认大多的架构变更需求。反过来，又有助于让安全团队通过安全设计原则，深入部署更好的防御。

会议结束时，我们重新历数关键的讨论结果，包括团队应当做出的发现及改进，并生成相应的追踪项目。与会者都会收到一份摘要，并随时可以就其提问，来更好地具体化要执行的项目。