The Rise of GitHub as a Major Player in the Vulnerability Disclosure Landscape

How has GitHub Changed the Way Vulnerabilities are Reported?

Over the course of a decade, our researchers have observed many shifts in the vulnerability disclosure landscape. As leaders in the vulnerability intelligence space, we have seen the fall of Bugtraq, the steady rise of Patch Tuesday, and experienced the full force of the Vulnerability Fujiwhara Effect.

However, our vulnerability researchers are seeing a continually growing trend, one that will likely continue to skyrocket as new technologies and software continue to come to market. GitHub has become a significant medium for vulnerability information and disclosures.

Despite being a software development tool, GitHub has over 94,000 references affecting over 45,000 vulnerabilities. Here is a breakdown of vulnerabilities with external references to GitHub within the last ten years, by date of first disclosure:

Based on the trend, we might have assumed that the number of GitHub vulnerabilities would have continued to increase, maybe even jump considerably in recent years. But despite 2016 – 2017’s meteoric rise, it seems that since 2018, vulnerability disclosures have plateaued. This isn’t from lackluster monitoring, since VulnDB is constantly expanding its already substantial coverage of third-party libraries and disclosures via GitHub as a whole. We’ll dig more into this trend as more data becomes available. But regardless, the message is loud and clear: GitHub has emerged as a major player in the vulnerability disclosure landscape.

The Anatomy of a GitHub Disclosure

Before we jump to conclusions for 2021, let’s take a look at last year’s GitHub vulnerabilities:

Reference types:

• Vendor Specific Solution URL – This generally includes pull requests and fixing commits. There are times where a single issue may lead to fixes in different trees via multiple pull requests.
• Bug Tracker – Our general term for a bug tracker like JIRA or Mantis. In GitHub, they are called ‘Issues’.
• General Exploit URL – This is when a repo is created that hosts exploit code for a specific, previously disclosed issue. This generally is not used for the initial disclosure, only exploit code.
• Other Advisory – A repo created to disclose a new vulnerability that may or may not contain exploit code.

Overall, these numbers are interesting and encouraging. First off, it shows that GitHub is doing exactly what it was meant to do, which is making open source projects more transparent. Seeing so many references to solutions is good for organizations aiming to remediate every vulnerability. Since these solution URLs are typically in third-party libraries, it is a great benefit to have the details to fix issues here, rather than having to scour CVE/NVD (which often does not have that information at all)!

What is the Impact of Open Source Code on Supply Chain Risk?

In the late 90’s and early 00’s, a significant number of disclosures occurred on Bugtraq and Full Disclosure mail lists. Then, as Milw0rm, Packetstorm, and Exploit Database gained popularity, disclosures shifted to those platforms. Next, our researchers noted the rise of easy-to-use blogs like WordPress and Blogspot. Since then, these personal researcher blogs have increased over time and continue to be a steady source of information for VulnDB.

Monitoring these can be tricky since new blogs are created every day and locating new ones that have vulnerabilities is a challenge. Now, it is clear that GitHub is a major player in the vulnerability disclosure landscape. But is it destined to stay, and if so, for how long?

So far, it seems that GitHub’s use for vulnerability disclosure will continue to grow in numbers. The initial jump and high numbers isn’t seen on similar developer-oriented platforms like SourceForge or Gitee, only GitHub. This speaks to GitHub’s domination of the space and accounting for backfill, we will likely see vulnerability disclosures in 2019 and 2020 rise. It will be interesting to see how 2021 ends and whether the numbers of vulnerabilities will continue to slightly trend downward, or start to climb.

If GitHub vulnerability disclosures continue to grow, or spike as we saw in 2017, that could have an impact on the security industry as a whole. If GitHub continues to be a de facto source for third-party libraries and OSS vulnerabilities, security professionals need to take note and ensure it is part of their tracking and research process.

As we saw with personal researcher blogs, it will be a challenge for organizations to keep track of GitHub’s more than 100 million repositories. If GitHub continues its vulnerability disclosure trend, developers and product security experts will need comprehensive vulnerability intelligence that is actively monitoring and tracking this source.

Frequently Asked Questions (FAQs)

Why is GitHub a major player in vulnerability disclosure and how does Flashpoint Ignite monitor it?

GitHub is a major player in vulnerability disclosure because it serves as one of the central repositories for the world’s open-source code. Flashpoint Ignite monitors GitHub by indexing commits, pull requests, and issue threads to identify “silent fixes” and security disclosures that haven’t yet been assigned a CVE ID. This allows security teams to detect vulnerabilities in their software supply chain weeks before they appear in public databases like the NVD.

GitHub Activity	Security Significance	Flashpoint Ignite Benefit
Pull Requests	Often contain fixes for critical security flaws.	Identifies remediation code before an official patch.
Issue Threads	Where researchers and developers discuss unpatched bugs.	Provides early warning of potential zero-day threats.
Commit History	Reveals the specific lines of code that were vulnerable.	Delivers technical context for custom security signatures.

How does Flashpoint help organizations find “shadow disclosures” on GitHub?

Flashpoint helps organizations find shadow disclosures by using advanced algorithms and human research to analyze code changes that are not officially labeled as security updates. Many developers fix vulnerabilities without requesting a CVE to avoid negative publicity or to move faster. Flashpoint VulnDB catalogs these events, providing our users with severity scores and technical details for thousands of “hidden” flaws that traditional vulnerability scanners completely miss.

• Silent Fix Detection: Identifies security-critical code changes disguised as “bug fixes.”
• Developer Context: Monitors the discussions between maintainers to understand the true risk of a flaw.
• Rapid Indexing: Adds new GitHub-sourced vulnerabilities to our database in near real-time.

Why is Flashpoint’s GitHub intelligence vital for open-source software (OSS) security?

Flashpoint’s vulnerability intelligence is vital for OSS security because modern applications are almost entirely dependent on open-source libraries. A single vulnerability in a widely used GitHub repository can create a massive “ripple effect” across the global supply chain. Flashpoint provides the visibility needed to track these dependencies, ensuring that organizations know exactly when a library they use has been compromised and what steps are needed to secure their environment.

OSS Risk Factor	Flashpoint Strategic Advantage
Dependency Depth	Maps flaws in sub-libraries that are often overlooked by basic tools.
Disclosure Speed	Captures security events at the source as soon as they are committed to code.
Technical Depth	Provides the raw code context needed for DevSecOps teams to verify fixes.