产品安全事件响应团队 (PSIRT) 是由安全专业人员组成的团队，他们在幕后辛勤工作，以保护公司的软件产品和服务。PSIRT 与计算机安全事件响应团队 (CSIRT) 不同，后者通常被称为信息安全团队。区别很简单但很明显：CSIRT 专注于响应影响公司基础设施、数据或用户的事件。PSIRT 专注于响应影响公司构建的产品的事件，最常见的是发现漏洞或安全缺陷，以及随后采取的管理或修复行动。
PSIRT 工具
我已经在 PSIRT 工作了 20 多年，最初是作为 Mandriva PSIRT 的负责人（尽管当时我们不这么称呼它），目前在红帽工作。虽然今天有所改变，但与 CSIRT 可用的众多工具相比，PSIRT 可使用的工具从来都不多。当然，我们有静态代码分析 (SCA)、静态应用程序安全测试 (SAST) 和动态应用程序安全测试 (DAST) 工具来识别我们产品中已知和未知的漏洞。但是，一直没有一种很好的方法来管理围绕这些漏洞的数据，因此大多数 PSIRT 依赖于自制工具或将一些功能附加到并非为此用途设计的现有工具上。
例如，当我大约 14 年前刚加入红帽时，我直接使用 Bugzilla 实例来跟踪和记录错误和漏洞信息。那时它非常简单——有一个 CVE 错误，其中包含漏洞的详细信息，然后为产品团队创建子错误以跟踪修复。当我们只需要担心 OpenShift 和 JBoss 企业应用平台时，这种方法很有效。随着我们开始开发和支持更多产品，我们发现手动执行此操作无法与如此小的团队规模相匹配。我们编写了一系列 Python 脚本，亲切地称为安全缺陷管理器 (SFM)，这些脚本通过 API 调用来操作 Bugzilla，以创建错误、添加评论和其他元数据。这种情况发生在缺陷被报告、公开、影响和评分指标、受影响的产品以及其他有用的数据时。这些数据都没有得到错误跟踪系统的正确支持，而是以自定义格式塞入其他字段中，容易受到人为干预。虽然简陋，但这些脚本在一段时间内确实完成了我们需要它们完成的工作。但是，随着我们想要收集更多元数据，并且需要支持越来越多的产品，SFM 感觉有点过时了。毕竟，谁想在命令行上完成所有这些工作呢？
几年前，我们努力创建一个新工具。我们开发了 SFM2，这是一个基于 Web 的单应用程序，它完成了 SFM 所做的一切以及更多。它具有更好的搜索功能，这有助于处理我们必须跟踪和处理的不断增长的 CVE 数量。它提供了更好的质量检查，确保我们不会遗漏任何东西，因为处理越来越多的漏洞和越来越多的产品变得越来越复杂。我们知道其他 PSIRT 可能对这个工具感兴趣，并且在一段时间内，我们一直希望将其模块化并使其开源可用。但它仍然受限于特定的 Bugzilla 自定义。这使得任何人（除了我们）都难以或不可能使用它。
SFM2 的演变
这非常令人沮丧，因为我们实际上开发了 内部开源，这是蒂姆·奥莱利在二十多年前创造的一个术语。一切都是用开放语言编写的，并以开源方式构建的。但是我们无法分享它，也没有人可以从我们的工作中受益，我们也无法从他人的经验和意见中受益。我们知道还有其他公司正在处理其产品以及现在的托管或托管服务中更复杂的问题。作为开源漏洞管理领域的领导者，我们的团队拥有一些出色的工具，但由于我们无意中允许功能蔓延和与自定义工具的联系阻碍了发展，我们无法与任何人分享这些工具。
因此，去年我们再次审视了这个问题。SFM2 的设计方式不允许我们很好地维护它，并且我们需要纠正一些其他缺陷——但我们遇到了瓶颈。我们需要不同的功能，并且该工具是为一种非常特定的工作方式设计的，这种工作方式需要改变才能提高效率和规模。而使用 Bugzilla 作为后端数据库（十年前运行良好）不再理想。事实上，它是我们遇到的最大障碍。
我们需要的不是一个单体应用程序，而是一组使用 API 协同工作的小型服务。一年前我们在构思这个问题时，我解释的方式是 sendmail 和 qmail 电子邮件服务器之间的区别。Sendmail 是一个单体应用程序，可以完成所有工作，而 qmail 有不同的服务，其中一个服务的输出作为另一个服务的输入传递，并且每个服务都足够独特和独立，以便于维护。毕竟，这是最初 UNIX 哲学的关键部分，我们这些从事这项工作很长时间的人仍然对此高度评价。
因此，我们着手构建四个主要应用程序：一个缺陷数据库，用于存储所有漏洞信息（取代 Bugzilla 作为我们的后端），一个该数据库的前端，使其易于添加和更新信息，一个组件注册表，可以用作我们所有产品和服务的清单，以便我们可以轻松找到任何给定组件可能存在的位置，最后是一个许可证扫描器，以确保我们满足我们的开源许可证合规性要求。核心设计原则之一是通过 API 进行主要交互方法，这样我们就可以编写一个前端，任何人都无需被迫使用（如果最终用户获得授权，他们可以重新创建旧时的 SFM 脚本，通过命令行与缺陷信息进行交互）。但更重要的是，这些服务可以直接与其他现有工具集成，使用标准化和开放的数据交换格式，而不是手动重复从一个平台到另一个平台的元数据。
此外，必须遵守的另一个核心原则是，这些工具需要在开放环境中开发。我们这样做有几个原因。首先，我们希望其他人能够使用这些工具并为之做出贡献。其次，这强制执行了一定程度的严谨性——我们不能专门为我们自己使用而设计这些工具，所以不再是内部开源。
凭借在支持开源漏洞管理方面经历不止一代而是两代工具的经验和教训，我们非常确定我们选择了正确的道路。然而，我们足够谦虚地知道，其他人可能有不同的需求，因此邀请您加入我们来开发这些工具。几乎每个人，从大型企业开源生产者，到街角的披萨店及其 Web 和移动应用程序，都是软件开发人员。因此，除了自制工具、电子表格、软件或服务的临时附加组件（并非旨在处理 PSIRT 流程）之外，还需要工具来管理漏洞。CSIRT 和开发人员有很多工具，但事件响应和协调工具却不多。
如果您有兴趣查看或使用这些工具中的任何一种，我们邀请您通过 GitHub 与我们合作。虽然我们已经研究这些工具一段时间了，但到目前为止我们只研究了四个工具中的三个。第四个工具，即缺陷数据库的前端，或在这些服务之间运行的服务层，尚未启动。
评论已关闭。