50 Shades of Vulnerabilities: Uncovering Flaws in Open-Source Vulnerability Disclosures

Aqua Nautilus researchers evaluated the vulnerability disclosure process for tens of thousands of open-source projects and found flaws in the process. These flaws allowed harvesting the vulnerabilities before they were patched and announced. This could enable attackers to exploit security holes before the project’s users are alerted. 
Aqua Nautilus 研究人员评估了数以万计的开源项目的漏洞披露流程，并发现了流程中的缺陷。这些漏洞允许在修补和宣布漏洞之前收集漏洞。这可能使攻击者能够在项目用户收到警报之前利用安全漏洞。

By conducting an extensive analysis of commits, pull requests, issues on GitHub, and extracting insights from the National Vulnerabilities Database (NVD) dataset this research yielded many findings. In this blog we shed light on our work, the process, research methods, highlight the stages of vulnerability discovery, and the gravity of early exposure of vulnerabilities in open-source projects. We additionally advocate for the need for standardized responsible disclosure processes.
通过对 GitHub 上的提交、拉取请求、问题进行广泛分析，并从国家漏洞数据库 （NVD） 数据集中提取见解，这项研究产生了许多发现。在这篇博客中，我们阐明了我们的工作、过程、研究方法，强调了漏洞发现的阶段，以及开源项目中漏洞早期暴露的严重性。此外，我们还倡导需要标准化的负责任披露流程。

Vulnerabilities disclosure stages
漏洞披露阶段

To understand the current research, we’d like to clarify some definitions related to the vulnerability disclosure process:
为了理解当前的研究，我们想澄清一些与漏洞披露过程相关的定义：

1. ‘0-day’: A vulnerability that is unknown to the maintainer of the project.
   “0-day”：项目维护者未知的漏洞。
2. ‘1-day’: A vulnerability that is known to the maintainer. Typically, the CVE/announcement is publicly published. At this stage, there is typically an available patch. However, the release of this patch can sometimes be delayed by a day or, in some cases, may not be released at all.
   “1-day”：维护者已知的漏洞。通常，CVE/公告是公开发布的。在此阶段，通常会有一个可用的补丁。但是，此修补程序的发布有时会延迟一天，或者在某些情况下可能根本不发布。

In our research, we found many cases of vulnerabilities that can’t be categorized as either ‘0-day’ or ‘1-day’, because they fall between these definitions (“between the times”), we therefore conclude that the world of vulnerability disclosure is more complex than a binary distinction. Consequently, we offer two more states in the vulnerability disclosure process:
在我们的研究中，我们发现许多漏洞案例不能归类为“0 天”或“1 天”，因为它们介于这些定义之间（“时间之间”），因此我们得出结论，漏洞披露的世界比二元区分更复杂。因此，我们在漏洞披露过程中提供了另外两种状态：

‘Half-Day’ Vulnerability
“半天”漏洞

• A vulnerability that is known to the maintainer.
  维护者已知的漏洞。
• Alarmingly, information about the vulnerability is exposed to the public through platforms such as GitHub (commit/PR/issue), NVD, etc.
  令人震惊的是，有关该漏洞的信息通过 GitHub（提交/公关/问题）、NVD 等平台向公众公开。
• A commit to fixing the vulnerability may have been created, but an official release is not yet available.
  可能已创建修复漏洞的提交，但尚未发布正式版本。
• A CVE may or may not be assigned during this phase.
  在此阶段，可能会也可能不会分配 CVE。
  
  The risks of ‘Half-Day’: Attackers can harvest any indicators of a new vulnerability being formed or disclosed on public platforms (GitHub, NVD). Utilizing messages and meta-data found in PRs, commits and issues the attackers can locate references to the vulnerable code, use reported proof of concept (if exists) and even write their own exploit.
  “半天”的风险：攻击者可以收集在公共平台（GitHub、NVD）上形成或披露新漏洞的任何指标。利用 PR、提交和问题中的消息和元数据，攻击者可以找到对易受攻击代码的引用，使用报告的概念证明（如果存在），甚至编写自己的漏洞利用。
  To further illustrate our point, imagine a case where there is an open issue on GitHub about a possible vulnerability in the project. This was acknowledged by the maintainer and a commit that fixes the vulnerable code exists and refers to the issue. Nevertheless, the latest release of the project does not include the commit that resolves the vulnerability.  
  为了进一步说明我们的观点，假设 GitHub 上存在一个关于项目中可能存在的漏洞的未决问题。维护者承认了这一点，并且存在修复易受攻击代码的提交并引用了该问题。但是，该项目的最新版本不包括解决漏洞的提交。

‘0.75-Day’ Vulnerability
“0.75 天”漏洞

• A vulnerability that is known to the maintainer.
  维护者已知的漏洞。
• An official patch is available.
  官方补丁可用。
• A CVE or CPE is not available.
  CVE 或 CPE 不可用。
  
  The risks of ‘0.75-Day’: Attackers can harvest any indicators of a new vulnerability being formed or disclosed on public platforms (GitHub, NVD). Utilizing messages and meta-data found in PRs, commits and issues the attackers can locate references to the vulnerable code, use reported proof of concept (if exists) and even write their own exploit.
  “0.75 天”的风险：攻击者可以收集在公共平台（GitHub、NVD）上形成或披露的新漏洞的任何指标。利用 PR、提交和问题中的消息和元数据，攻击者可以找到对易受攻击代码的引用，使用报告的概念证明（如果存在），甚至编写自己的漏洞利用。
  The main difference between this state and ‘Half-Day’, is that even though an official patch is available, because a CVE or CPE has not been assigned yet, vulnerability scanning tools can’t detect this component in your environment, and you may not be aware you need to fix it.
  此状态与“半天”之间的主要区别在于，即使有官方补丁可用，由于尚未分配 CVE 或 CPE，漏洞扫描工具也无法在您的环境中检测到此组件，您可能不知道需要修复它。

Please note that all stages from ‘Zero-Day’ to ‘One-Day’ carry the same level of seriousness and impact for practitioners. This is because the details of the vulnerability and the patch are not publicly available, and security solutions are unable to detect or offer remediation before reaching the ‘One-Day’ status.
请注意，从“零日”到“一日”的所有阶段对从业者都具有相同程度的严肃性和影响。这是因为漏洞和补丁的详细信息尚未公开，并且安全解决方案无法在达到“一日”状态之前检测或提供补救措施。

Naturally, these are not the only scenarios that exist out there. But in our research, we found that these are the most common ones, and easiest to harvest, as we demonstrate in this blog. 
当然，这些并不是唯一存在的场景。但在我们的研究中，我们发现这些是最常见的，也是最容易收获的，正如我们在本博客中所展示的那样。

Below, we present several case studies that demonstrate the impact of our research on the open-source vulnerability disclosure process. Although there is no concrete evidence to suggest that attackers are actively exploiting this in the wild, it is reasonable to assume that threat actors may harvest information from open-source projects. They could be using this data to gain a deeper understanding of the projects and to search for potential vulnerabilities.
下面，我们介绍了几个案例研究，展示了我们的研究对开源漏洞披露过程的影响。尽管没有具体证据表明攻击者正在积极利用这一点，但可以合理地假设威胁行为者可能会从开源项目中收集信息。他们可能会使用这些数据来更深入地了解项目并寻找潜在的漏洞。

Case Studies 案例研究

In this section we shell show 2 case studies of flaws in the vulnerability disclosure process.
在本节中，我们将展示 2 个漏洞披露过程中缺陷的案例研究。

Case Study 1: Analysis of Log4Shell (CVE-2021-44228) Disclosure Process
案例研究 1：Log4Shell 分析 （CVE-2021-44228） 披露流程

To shed light on this topic, let’s examine the disclosure and patch timeline of the well-known Log4Shell vulnerability – We will highlight the inherent discrepancies in the disclosure/reporting process.
为了阐明这个话题，让我们来看看众所周知的 Log4Shell 漏洞的披露和补丁时间表——我们将强调披露/报告过程中的固有差异。

For many practitioners the Log4Shell vulnerability symbolizes as a turning point for how they view vulnerabilities. Many indicate that they had to work day and night to patch this vulnerability when it just came out. So, for a quick refresher, Log4Shell was discovered and reported to Apache by Alibaba on November 24, 2021. It then gained wider attention with a tweet on December 9, 2021, and rapidly became a significant concern. 
对于许多从业者来说，Log4Shell漏洞象征着他们如何看待漏洞的转折点。许多人表示，当这个漏洞刚刚出现时，他们不得不日以继夜地工作来修补这个漏洞。因此，为了快速复习，Log4Shell 于 2021 年 11 月 24 日被阿里巴巴发现并报告给 Apache。然后，它在 2021 年 12 月 9 日的一条推文中获得了更广泛的关注，并迅速成为一个重大问题。
We’ll investigate the activity found in the relevant repository on GitHub during this period to highlight the evolving states of the vulnerability. 
在此期间，我们将调查在 GitHub 上的相关存储库中发现的活动，以突出显示漏洞的演变状态。

As they say, a picture is worth a thousand words, so we’ll begin with a visual timeline chart, followed by a detailed breakdown of each stage.
正如他们所说，一张图片胜过千言万语，因此我们将从视觉时间线图开始，然后详细分解每个阶段。

 
 Dates may vary slightly due to discrepancies between different information sources
由于不同信息来源之间的差异，日期可能略有不同

Breakdown of the Chart: 图表明细：

1. The vulnerability was reported to the Apache team on November 24th, 2021.
   该漏洞已于 2021 年 11 月 24 日报告给 Apache 团队。
2. On November 30th, 2021, six days later, a maintainer opened a pull request on GitHub with a commit that fixed the issue. From this point on, the vulnerability and its details are available to anyone on GitHub and are practically publicly exposed.
   2021 年 11 月 30 日，六天后，一位维护者在 GitHub 上打开了一个拉取请求，其中包含修复该问题的提交。从现在开始，GitHub 上的任何人都可以访问该漏洞及其详细信息，并且实际上已经公开。
3. On December 5th, 2021, five days after the pull request, it was merged. However, no official patch was available at this time – the fix was solely in the open-source code.
   2021 年 12 月 5 日，即拉取请求五天后，它被合并。但是，目前没有可用的官方补丁 – 该修复仅在开源代码中。
4. On December 6th, 2021, a day later, the first official patch became available on Apache’s website.
   2021 年 12 月 6 日，一天后，Apache 网站上发布了第一个官方补丁。
   In summary, regarding the ‘Half-Day’ window: Over a span of 6 days (from November 30th, 2021 to December 6th, 2021) the vulnerability was exposed on public platforms (like GitHub). This timeframe allowed attackers to detect the problem, pinpoint the vulnerable code, and potentially craft an exploit before users became aware and could implement a patch. 
   综上所述，关于“半天”窗口：在 6 天的时间里（从 2021 年 11 月 30 日到 2021 年 12 月 6 日），该漏洞在公共平台（如 GitHub）上暴露。这个时间范围允许攻击者检测到问题，查明易受攻击的代码，并可能在用户意识到并实施补丁之前构建漏洞。
   It’s worth noting that, at this stage, scanning tools couldn’t detect the issue because the CVE number and CPE for the vulnerability hadn’t been created yet.
   值得注意的是，在此阶段，扫描工具无法检测到该问题，因为尚未创建漏洞的 CVE 编号和 CPE。
   So, we proceed to the ‘0.75-Day’ window.
   因此，我们进入“0.75 天”窗口。
5. On December 10th, 2021, four days later, an official CVE identifier for the vulnerability was released. This marked the first time that some vulnerability scanning tools had the necessary data to detect this vulnerability.
   2021 年 12 月 10 日，四天后，该漏洞的官方 CVE 标识符发布。这标志着一些漏洞扫描工具首次拥有检测此漏洞所需的数据。
   In summary, regarding the ‘0.75-Day’ window: Over a span of 4 days (from December 6th, 2021 to December 10th, 2021), the vulnerability was exposed on open-source platforms. An official patch was available from Apache during this time. However, attackers could still exploit this vulnerability against users who hadn’t applied the patch. This is because only after December 10th could scanning tools effectively identify this CVE in user environments.
   综上所述，关于“0.75 天”窗口：在 4 天的时间里（从 2021 年 12 月 6 日到 2021 年 12 月 10 日），该漏洞在开源平台上暴露。在此期间，Apache 提供了官方补丁。但是，攻击者仍可利用此漏洞攻击未应用修补程序的用户。这是因为只有在 12 月 10 日之后，扫描工具才能在用户环境中有效地识别此 CVE。
6. On December 13th, the CVE was assigned its score and CPE by NIST. This gave scanning tools a more detailed insight into the vulnerability’s impact on different software, products, and versions. Furthermore, it helped users prioritize this CVE in their vulnerability management system.
   12 月 13 日，NIST 为 CVE 分配了分数和 CPE。这使扫描工具能够更详细地了解漏洞对不同软件、产品和版本的影响。此外，它还帮助用户在其漏洞管理系统中确定此 CVE 的优先级。

Another example to this process flaw it the Text4Shell: CVE-2022-42889, only this time it’s even worse than the one before, as the windows in this case is much bigger and illustrates a more severe scenario.
此过程的另一个示例是 Text4Shell：CVE-2022-42889，只是这次比之前更糟糕，因为在这种情况下的窗口要大得多，并且说明了更严重的情况。
There were 75 days of ‘0.5-Day’ windows, and 14 days of ‘0.75-Day’ windows.
有 75 天的“0.5 天”窗口和 14 天的“0.75 天”窗口。

The initial pull request addressing this issue was made on July 16th, 2022. It was merged on September 23rd, 2022, and the official release for this issue was available on September 29th, 2022, marking 75 days since the first indication of this vulnerability on GitHub. Only 14 days later, on October 13th, 2022, the CVE was identified by NVD and publicly announced.
解决此问题的初始拉取请求是在 2022 年 7 月 16 日提出的。它于 2022 年 9 月 23 日合并，本期的正式版本于 2022 年 9 月 29 日发布，标志着自 GitHub 上首次显示此漏洞以来的 75 天。仅仅 14 天后，即 2022 年 10 月 13 日，CVE 被 NVD 识别并公开宣布。

Case Study 2: Half-Day and 0.75 Day at Binwalk (CVE-2022- 4510)
案例研究 2：Binwalk 的半天和 0.75 天 （CVE-2022- 4510）

If you’re unfamiliar with Binwalk, it is a tool used for searching a given binary image for embedded files and executable code. We are showcasing this CVE here because we were able to catch this case in real time and observe the behavior and timeline of this issue using our first method to harvest vulnerabilities from open source projects.
如果您不熟悉 Binwalk，它是一种用于在给定二进制图像中搜索嵌入式文件和可执行代码的工具。我们在这里展示这个 CVE，因为我们能够实时捕获此案例，并使用我们的第一种方法从开源项目中收集漏洞来观察此问题的行为和时间线。

For a quick refresher, on January 31, 2023, ONEKEY released a blog about Remote Command Execution in the Binwalk tool. In this case, at the time of publication, the vulnerability has yet to be patched. This is not a rare case and sometimes helps warn users and apply pressure on the project team to release a patch.
为了快速复习，2023 年 1 月 31 日，ONEKEY 发布了一篇关于 Binwalk 工具中远程命令执行的博客。在这种情况下，在发布时，该漏洞尚未得到修补。这种情况并不少见，有时有助于警告用户并向项目团队施加压力以发布补丁。

Below we review the process and different milestones during the vulnerability disclosure as they appear here.
下面我们回顾一下漏洞披露期间的流程和不同里程碑，因为它们显示在此处。
 

Dates may vary slightly due to discrepancies between different information sources
由于不同信息来源之间的差异，日期可能略有不同

Breakdown of the Chart: 图表明细：

1. The vulnerability was reported to ReFirmLabs on GitHub via a pull request, on October 26th, 2022.
   该漏洞于 2022 年 10 月 26 日通过拉取请求报告给 GitHub 上的 ReFirmLabs。
   The reporter mentioned that they took the liberty to report it openly since another issue (#556) was resolved in this manner, and they could not find any security/coordinated disclosure policy or contact information.
   记者提到，他们冒昧地公开报告了这个问题，因为另一个问题（#556）以这种方式得到了解决，他们找不到任何安全/协调的披露政策或联系信息。
   At this point, the issue was publicly exposed, making it possible to identify this vulnerability before its official disclosure. This pull request also included the commit containing the vulnerable code and a Proof of Concept, which could allow attackers to exploit this vulnerability.
   在这一点上，该问题已公开曝光，因此可以在正式披露之前识别此漏洞。此拉取请求还包括包含易受攻击的代码和概念证明的提交，攻击者可利用此漏洞。
2. On January 26th, 2023, 92 days later, the vulnerability was published on NVD with a description and reference to the GitHub pull request, which included a description of the vulnerability and the Proof of Concept (PoC). This allows attackers, who harvest data from NVD to learn about this vulnerability before a working patch was available to users.
   2023 年 1 月 26 日，即 92 天后，该漏洞在 NVD 上发布，并附有对 GitHub 拉取请求的描述和参考，其中包括对漏洞的描述和概念验证 （PoC）。这允许从 NVD 收集数据的攻击者在用户获得工作补丁之前了解此漏洞。
3. On February 1st, 2023, six days later, the pull request was merged, and an official patch was released.
   2023 年 2 月 1 日，六天后，拉取请求被合并，并发布了官方补丁。

In summary, regarding the ‘Half-Day’ window:  Over a span of 98 days (from October 26th, 2022, to February 1st, 2023), the vulnerability was exposed on public platforms. This timeframe allowed attackers to detect the vulnerability and possibly exploit it before users became aware and could implement a patch.
综上所述，关于“半天”窗口：在 98 天的时间里（从 2022 年 10 月 26 日到 2023 年 2 月 1 日），该漏洞在公共平台上暴露。这个时间范围允许攻击者检测到漏洞，并可能在用户意识到并实施补丁之前利用它。
These case studies are just a small part of the many cases and scenarios we come across.
这些案例研究只是我们遇到的众多案例和场景中的一小部分。

Harvesting Methods

How is it possible to identify such vulnerabilities on a large scale? Through our research, we discovered two sources that enabled us to collect data from various popular open-source projects, aiming to identify ‘Half-Day’ and ‘0.75-Day’ vulnerabilities within them over time.

Our aim is to assist practitioners in detecting and mitigating issues within their vulnerability disclosure lifecycle. To this end, we first want to bring this issue to your attention and secondly, to help you reduce the risk of exposing sensitive information about vulnerabilities during the disclosure process.

We will illustrate our methodology in two parts: first on GitHub, and then on NVD.

Harvesting Method 1: GitHub Pull Requests, Commit Messages, and Issues

On GitHub, we carried out the following steps:

1. Compiled a list of around 15,000 popular GitHub projects along with their URLs.
2. Utilized the GitHub REST API to analyze Open Pull Requests, issues, and commit messages.
3. Within the Pull Requests, issues, and commit messages, we searched for “trigger words” as listed below, which could indicate vulnerabilities or unwanted behavior.
   在拉取请求、问题和提交消息中，我们搜索了下面列出的“触发词”，这可能表示存在漏洞或不需要的行为。
   
   
   
   This word list is only a subset of the complete one. Some terms are given higher weight than others to prioritize the possibility of a real vulnerability or security issue.
   
   
4. We reduced the data volume by checking for existing releases that were published after the Pull Request, commit, or issue was merged/closed, etc. – indicating a high likelihood of an official patch for the identified “vulnerability”. We ended up with ~2,200 relevant results which were further analyzed and narrowed to ~50 (~2.3%) projects which required further in-depth analysis.
   我们通过检查在拉取请求、提交或问题合并/关闭等之后发布的现有版本来减少数据量——这表明很有可能针对已识别的“漏洞”进行官方补丁。我们最终得到了 ~2,200 个相关结果，这些结果被进一步分析并缩小到 ~50 个 （~2.3%） 项目，需要进一步深入分析。
   
   

An example of some vulnerability/issue identified by this method spans from November 2022 to February 2023.

As you can imagine, this approach yields many false positives. It’s essential to understand the context of each project, issue, and PR. Some terms that might seem indicative of a security issue, like ‘overflow’, can have various meanings. For instance, the term ‘overflow’ often appears in the context of GUI overflow, unrelated to security concerns. If you wish to replicate this process, you’ll need several GitHub tokens due to the numerous API requests. However, if you’re only focusing on a project under your responsibility, a few GitHub API tokens should suffice. Understanding the context becomes simpler in such cases. It’s also advisable to use the LLM module to process the results and filter out irrelevant ones.
可以想象，这种方法会产生许多误报。了解每个项目、问题和公关的背景至关重要。一些看似表示安全问题的术语（如“溢出”）可能具有不同的含义。例如，术语“溢出”通常出现在 GUI 溢出的上下文中，与安全问题无关。如果希望复制此过程，由于 API 请求众多，需要多个 GitHub 令牌。但是，如果您只专注于您负责的项目，那么一些 GitHub API 令牌就足够了。在这种情况下，理解上下文变得更加简单。还建议使用 LLM 模块来处理结果并过滤掉不相关的结果。

Harvesting Method 2: Monitoring NVD Early Exposure
收获方法2：监测NVD早期暴露

Sometimes, CVEs are uploaded to the NVD before an official patch is released, happening too early in the disclosure process’s lifetime – This can occur various reasons. Interestingly, some have references to their GitHub commit/PR/issue while vulnerability verification is ongoing, exposing them to attackers who could potentially “harvest“ them and develop an exploit.
有时，CVE 会在正式补丁发布之前上传到 NVD，这在披露过程的生命周期中发生得太早 – 这可能发生各种原因。有趣的是，在漏洞验证正在进行时，有些引用了他们的 GitHub 提交/PR/问题，将他们暴露给攻击者，他们可能会“收获”它们并开发漏洞。

Consider this: when you have the commit/PR that fixes a security issue, it becomes easier to understand the context of the CVE and develop an exploit because you have access to both the vulnerable code and the implemented fix, and sometimes even a Proof of Concept within the PR.
考虑一下：当您拥有修复安全问题的提交/PR 时，更容易理解 CVE 的上下文并开发漏洞利用，因为您可以访问易受攻击的代码和已实现的修复程序，有时甚至可以访问 PR 中的概念验证。

By utilizing the NVD API to fetch recently pushed CVEs and searching for GitHub references, we can then check if the commit/PR referenced by NVD has a release on GitHub that includes them. If not, this often presents a ‘Half-Day’ scenario, where a vulnerability is exposed without a patch at that stage.
通过利用 NVD API 获取最近推送的 CVE 并搜索 GitHub 引用，我们可以检查 NVD 引用的提交/PR 在 GitHub 上是否有包含它们的版本。否则，这通常会出现“半天”场景，即在该阶段没有补丁的情况下暴露漏洞。

Aqua Nautilus CVE-Half-Day-Watcher
Aqua Nautilus CVE-半日观察者

For this method, we have developed a tool that you can find on GitHub.
对于这种方法，我们开发了一个工具，您可以在 GitHub 上找到该工具。

It’s designed to scan the NVD for potential ‘0.5-Day’ vulnerabilities, going back as many days as you require. You’ll need to provide a GitHub token for the tool to query the GitHub API, specify your desired time frame for scanning the NVD, and define the minimum star rating for the projects you’re interested in.
它旨在扫描 NVD 以查找潜在的“0.5 天”漏洞，并根据需要追溯到任意天数。您需要为该工具提供 GitHub 令牌以查询 GitHub API，指定扫描 NVD 所需的时间范围，并定义您感兴趣的项目的最低星级。

Although this tool is in its PoC stage, it consistently delivers a large number of daily results. Each result has a significant likelihood of representing a ‘0.5-Day’ vulnerability, necessitating only your verification to confirm whether it is indeed one.
尽管该工具处于 PoC 阶段，但它始终如一地提供大量每日结果。每个结果都极有可能代表“0.5 天”漏洞，只需进行验证即可确认它是否确实存在漏洞。

An example of the results from November 5, 2023: Here we chose to scan a very small timeframe of two days back, and we got around 20 results of potential ‘0.5-Day’ vulnerabilities, including some from very popular projects.
2023 年 11 月 5 日的结果示例：在这里，我们选择扫描两天前的一个非常小的时间范围，我们得到了大约 20 个潜在“0.5 天”漏洞的结果，其中包括一些来自非常受欢迎的项目的结果。

In contrast to the previous method, which generated numerous false positives and required effort to determine if an issue triggered by a “trigger word” is indeed a security vulnerability, this method assures a high probability that the issues caught are genuine vulnerabilities. 
与以前的方法相比，前一种方法会产生大量误报，并且需要努力确定由“触发词”触发的问题是否确实是安全漏洞，而这种方法确保了捕获的问题很有可能是真正的漏洞。

Summary and Mitigations:
摘要和缓解措施：

Our research aims to minimize the risk of early exposure of vulnerabilities during the disclosure process.
我们的研究旨在最大限度地降低在披露过程中早期暴露漏洞的风险。
By analyzing GitHub activity and NVD entries, we’ve developed methods to detect potential security issues before they become public knowledge.
通过分析 GitHub 活动和 NVD 条目，我们开发了在潜在安全问题成为公共知识之前检测它们的方法。

Our goal is to minimize the gap between vulnerability discovery and patch release, reducing the window of opportunity for attackers.
我们的目标是最大限度地减少漏洞发现和补丁发布之间的差距，从而减少攻击者的机会窗口。

One might claim that there is already extensive discussion about the “integrity” of CVEs, accompanied by considerable criticism on this topic. People argue that there is an influx of vulnerabilities, which are often perceived as unnecessary and may generate excessive noise for security teams due to their potentially redundant impact. For instance, some CVEs may be unreachable or irrelevant in various scenarios, among other issues.
有人可能会说，关于CVE的“完整性”已经有广泛的讨论，并伴随着对这个话题的大量批评。人们认为，存在大量漏洞，这些漏洞通常被认为是不必要的，并且由于其潜在的冗余影响，可能会给安全团队带来过多的噪音。例如，除其他问题外，某些 CVE 在各种情况下可能无法访问或无关紧要。

To help the community, we would like to suggest some mitigation steps that every open-source maintainer should adopt:
为了帮助社区，我们想建议一些每个开源维护者都应该采用的缓解步骤：

• Responsible Disclosure:  负责任的披露：
  • Leverage GitHub’s private reporting feature to manage vulnerabilities discreetly.
    利用 GitHub 的私有报告功能谨慎地管理漏洞。
  • Create a responsible disclosure policy that outlines a secure process for vulnerability management.
    制定负责任的披露政策，概述漏洞管理的安全流程。
• Proactive Scanning of your Open-Source commits/issues/PRs: Conduct regular scans for trigger words in code commits, issues, and PRs to prevent early exposure.
  主动扫描您的开源提交/问题/PR：定期扫描代码提交、问题和 PR 中的触发词，以防止过早暴露。
• Runtime Protection: Our findings emphasize the crucial role of runtime protection strategies in bolstering security, particularly when a patch for a newly discovered and undisclosed vulnerability has not yet been released.
  运行时保护：我们的研究结果强调了运行时保护策略在增强安全性方面的关键作用，尤其是在尚未发布针对新发现和未披露漏洞的补丁的情况下。

By combining these strategies, we enhance the security posture against the early exploitation of vulnerabilities, ensuring a safer open-source ecosystem.
通过结合这些策略，我们增强了安全态势，防止漏洞的早期利用，确保更安全的开源生态系统。

原文始发于Ilay GoldmanYakir Kadkoda：50 Shades of Vulnerabilities: Uncovering Flaws in Open-Source Vulnerability Disclosures