Characterizing and Modeling the GitHub Security Advisories Review Pipeline
本文对 GitHub 安全公告（GHSA）审查流程开展了一项大规模实证研究，通过对 288,000 份公告的审查模式与延迟进行分析，以识别截然不同的快速与慢速处理机制，并提出排队模型以解释其底层机理。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
将互联网想象成一座由数百万不同人建造的巨大、繁忙的城市。在这座城市里，有数百万座“建筑”（软件项目），有时这些建筑存在隐藏的裂缝或损坏的锁（安全漏洞）。
为了保障城市安全，设有一个中央紧急调度中心，名为GitHub 安全公告（GHSA）。当有人发现建筑中的裂缝时，他们会向该中心提交报告。该中心的职责是审核报告，将其标记为“官方”，然后向全城广播警报，以便人们修复他们的锁。
然而，这篇论文揭示了一个关于该调度中心运作方式的惊人秘密：并非所有报告都以相同的速度被审核，提交报告的方式比你想象的更为重要。
以下是他们发现的简要故事：
1. 两条交通车道
研究人员分析了 2019 年至 2025 年间提交给调度中心的超过 288,000 份报告。他们发现，该中心的运作方式如同一条拥有两条截然不同车道的公路：
- 快车道（“本地”路线）： 如果发现裂缝的人是建筑的拥有者（项目维护者），并且他们使用一种特殊的内部表格**GRA（GitHub 存储库公告）**来提交报告，那么报告几乎会立即得到审核。这就像建筑拥有者直接从建筑内部拨打消防电话，响应是即时的。
- 慢车道（“外部”路线）： 如果报告来自外部来源，例如国家数据库（NVD），则必须在漫长而混乱的队列中等待。这就像陌生人在城镇另一端的公用电话亭拨打消防电话。即使建筑拥有者已经修复了裂缝，这份报告仍可能在调度中心正式盖章前在队列中停留数周甚至数月。
2. “快车道”未被充分利用
这里的转折是：尽管快车道要快得多，但大多数人并未使用它。
- 约 74% 的官方报告来自慢车道（NVD）。
- 仅约 26% 来自快车道（GRA）。
研究人员发现，快车道主要由建筑拥有者本人使用，他们往往刚接触该系统，此前未曾做过此类操作。而慢车道则由一小群经验丰富的“检查员”处理，他们已审核过数千份报告。
3. “补丁”与“印章”
该研究还考察了修复的时间安排。
- 在快车道中： 当建筑拥有者修复裂缝（发布“补丁”）时，官方印章（审核）通常在 2 天 内完成。修复与警报几乎同时到达。
- 在慢车道中： 即使建筑拥有者已修复裂缝，官方印章可能需要 28 天（或更久）才能到达。
这为何重要？
想象一下，一名窃贼（黑客）发现某座建筑已被修复。如果官方警报尚未盖章，城市其余部分就不知道修复方案的存在。窃贼仍可闯入，因为“官方警告”尚未发布。快车道填补了这一空白；而慢车道则让城市暴露数周之久。
4. “队列”模型
研究人员构建了一个数学模型（类似于咖啡店排队模拟）来解释这种现象。
- 他们发现，快车道完全跳过了“等候室”。
- 慢车道则强制报告在到达柜台之前，必须先坐在“等候室”（NVD 数据库）中。
- 这并非因为调度中心忽视了慢车道，而是系统构建方式使然。管道结构自然地为外部报告造成了延迟。
5. 谁在从事这项工作？
该研究还考察了参与其中的人员：
- 发现者： 发现裂缝的人通常是拥有少量在线关注度的普通人。
- 修复者： 实际修补代码的人通常是建筑拥有者，他们在社区中非常受欢迎且值得信赖。
- 审核者： 审核报告的人员构成多样。在快车道中，他们通常是建筑拥有者本人（身兼两职）。在慢车道中，他们是一个由专家组成的专门团队，此前已审核过数百份报告。
核心结论
该论文得出结论：GitHub 安全系统拥有一条极其高效的“快车道”，但目前未被充分利用。大多数报告仍走“慢车道”，导致在修复方案就绪与世界正式获知之间产生危险的延迟。
研究人员建议，如果能鼓励更多人使用内部“快车道”表格（GRA），而不是等待外部数据库，整个城市将更加安全，修复与警报之间的时间间隔将大幅缩短。他们还发布了所有数据和代码，以便他人进一步研究这一交通拥堵问题。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。