该新工具赋能用户主动发现自身或依赖项目的风险，并采取缓解措施。
译自 CVE Half-Day Watcher Closes Vulnerability Disclosure Gap，作者 Yakir Kadkoda 是 Aqua Security 研究团队 Nautilus 团队的首席安全研究员。他将漏洞研究专业知识与在云原生环境、供应链中发现和分析新安全威胁和攻击向量的重点结合起来。
安全研究人员发现了开源项目中公开披露漏洞的一个关键缺陷。这个缺陷带来了巨大风险，因为它使攻击者能在漏洞被正式修补和公布之前利用这些漏洞。基本上，在披露过程中但尚未发布正式 CVE 通告和提供补丁之前，攻击者就可以利用这些漏洞。
通过全面分析 GitHub 上的提交、拉取请求和问题，同时从 NVD(国家漏洞数据库)数据集中提取见解，可以在披露阶段识别漏洞。
开源社区注重透明度和协作。但是，这种开放性有时会反噬，特别是涉及安全漏洞时。一个广泛使用的开源项目中的安全缺陷的过早披露，可能会带来深远的后果。这可能会变成与时间赛跑，开发者争取修补漏洞，而攻击者同时努力找到并利用它。
为了关注这个问题，我们深入研究 Log4Shell 漏洞的披露和修补时间线。我们将强调披露和报告程序中的固有差异。
对许多从业者来说，Log4Shell 漏洞标志着他们对漏洞风险认知的一个关键时刻。在最初发现时，许多从业者都不遗余力地修补了这个漏洞。简要回顾一下，阿里巴巴于 2021 年 11 月 24 日发现了 Log4Shell 并报告给了 Apache。通过 2021 年 12 月 9 日的一条推文引起了更广泛的关注，迅速演变成一个重大问题。
我们将分析相关 GitHub 存储库在此期间的活动，以突出漏洞的演变阶段。
俗话说，一张图片胜过千言万语，所以我们将从可视化时间线图开始，然后详细分解每个阶段。
图表分解:
- 该漏洞于 2021 年 11 月 24 日报告给了 Apache 团队。
- 六天后，于 11 月 30 日，一个维护者在 GitHub 上打开了一个拉取请求，其中包含解决该问题的提交。此时，GitHub 上的任何人都可以访问该漏洞及其详细信息，实际上它已经公开曝光。
- 在拉取请求后的 5 天，12 月 5 日，它被合并了。但是，此时还没有正式补丁可用，修复仅存在于开源代码中。
- 一天后，12 月 6 日，Apache 网站上提供了第一个正式补丁。
总结: 漏洞在诸如 GitHub 等公共平台上曝光了 6 天(2021 年 11 月 30 日至 12 月 6 日)。这段时间为攻击者提供了检测问题、识别易受攻击的代码并在用户意识到并部署补丁之前潜在制作利用程序的机会。
值得注意的是，在这一阶段，由于缺乏 CVE 编号和漏洞的 CPE，扫描工具无法检测到该问题。
- 12 月 10 日，也就是 4 天后，为该漏洞发布了正式的 CVE 标识符。这标志着一些漏洞扫描工具首次拥有检测该漏洞所需的数据。
总结: 在 4 天的时间里(2021 年 12 月 6 日至 10 日)，该漏洞在开源平台上暴露。Apache 在此期间可以使用官方补丁。但是，攻击者仍然可以针对尚未应用补丁的用户利用该漏洞，因为在 12 月 10 日之前，扫描工具只能在用户环境中有效识别该 CVE。
12 月 13 日，NIST 为 CVE 分配了评分和 CPE。这为扫描工具提供了有关漏洞对各种软件、产品和版本影响的更详细信息。此外，它还帮助用户在漏洞管理系统中优先考虑此 CVE。
Log4Shell 只是展示现有差距的一个众所周知的例子。另一个更近期的例子是 Azure CLI CVE-2023-36052，它在微软发布补丁之前的 189 天内在 GitHub 问题中公开暴露。这种延长的暴露时间为攻击者提供了充分的机会来利用该漏洞。
直到现在，还没有办法缩短披露过程中的这一关键差距。
为了解决这个令人担忧的问题，我们开发了 CVE 半日观察员。该工具强调了早期 CVE 披露的相关风险，跟踪漏洞实例以确认项目是否过早披露。它的操作方式是扫描 NVD 以获取新的 CVE，并检查与新 CVE 相关的 GitHub 活动，如与新 CVE 相关的提交、拉取请求或问题。它会验证在最初指出漏洞后，是否为报告的问题实现了补丁。这使得用户能够主动识别并降低项目或他们依赖的项目中的风险。
CVE 半日观察员旨在关注这些风险，说明如何轻松发现和潜在利用已披露的漏洞。这种情况强调了在敏感的漏洞分类和披露阶段避免公开披露安全问题的重要性。提高认识是降低这些风险的第一步。通过了解漏洞，用户可以采取各种行动来保护自己和自己的项目。
欲了解更多信息，请访问 GitHub 上的该工具并阅读我们的博客。