Do you worry that a CVE will hurt the reputation of your project? In reality, CVEs are a tracking number, and nothing more. Here's how we think of them at GitHub.
A CVE is a unique identifier, assigned to a security vulnerability. It’s just a tracking number, intended to make it easy to search for information about the vulnerability. Unfortunately, there are some common misconceptions about CVEs, which we believe are detrimental to progress in software security. Here are some examples:
Due to these misconceptions, vendors and open source maintainers are often hesitant to request a CVE, particularly if the vulnerability is not very severe. Here at GitHub Security Lab, we believe it’s better to be as transparent as possible—always request a CVE and publish an advisory, even for very low severity vulnerabilities, but use your advisory to describe the technical details so that your users can make their own informed decisions about whether they really need to panic.
If a vulnerability is discovered in your open source project, you can use a GitHub Security Advisory (GHSA) to alert your users. Maintainers can also request a CVE assignment from GitHub as part of their GHSA publication. Publishing your own advisory gives you the opportunity to provide an authoritative and objective description of the vulnerability. If you think the vulnerability has a very low severity and is unlikely to affect anyone in practice, then you can explain that in the severity scoring and explicitly in the advisory itself. We believe that it’s good for the reputation of a project to be transparent about any vulnerabilities, including low severity ones.
CVEs are assigned by a CVE Numbering Authority (CNA). Large software companies, like Google, Microsoft, and Apple, are often CNAs so that they can assign CVEs for vulnerabilities in their own products. CNAs operate within a given scope, so they typically do not assign CVEs for other vendors or projects as that’s commonly outside of their scope. GitHub acts as a CNA for any open source project that’s hosted on GitHub (via the GHSA system). But GitHub is not the only CNA that can assign a CVE for an open source project; other CNAs, such as MITRE and CERT/CC could also assign to open source projects based on their broad scopes, so it is quite possible that a CVE could be assigned to your project, even though you did not request it yourself by creating a GHSA. This is particularly likely to happen if you do not respond to a security researcher who finds a vulnerability in your project. And when that happens, there’s a much higher chance that inaccurate information will be published about the vulnerability.
The GitHub Advisory Database is a database of vulnerabilities affecting open source packages and projects primarily hosted on GitHub. In addition to most maintainer-created GHSAs, it also includes vulnerability advisories imported from other CNAs. Our advisory curation team reviews these advisories and improves on them by adding important vulnerability details, including mapping the affected product to a specific package. For advisories that we import from other CNAs, we typically rely on the description and severity rating provided by them. So if maintainers want to make sure that the GitHub Advisory Database contains accurate information, it’s much better for them to create or collaborate on their own advisory first!
If you believe a CVE has been assigned to your project incorrectly, you can contest it with the CNA that assigned the CVE. GitHub can only assist in contesting CVEs that have been assigned by GitHub as part of the GitHub Security Advisory process. Reasons a maintainer may want to contest a CVE include:
A maintainer cannot contest a CVE assignment just because they disagree with the severity assigned to it. You can contact the assigning CNA to discuss the severity and request that they change it based on information you provide to them, but if it’s a valid vulnerability then a CVE will still be assigned to it.
GitHub Security Lab handles your CVE request, typically within 72 hours. We provide an editorial service, which means that we don’t just assign a number, we also ensure that your request complies with the CVE Program’s rules and we write a condensed summary of the issue that’s suitable for sharing with other CVE databases, such as the National Vulnerability Database (NVD) operated by NIST. We follow a style guide to keep the condensed summary short, but also as rich as possible in order to help the community at large digest your advisory. We attempt to find pull requests, issues, and fix commits related to your advisory so that we can link to them in the CVE. We’ll also assign a severity score based on the information provided to us. We share the CVE number with you while your advisory is still in draft, but we won’t publish anything until you make your GHSA public.
More information is almost always better! When we review your CVE request, it’s very helpful to have as much information about the vulnerability as possible, so that we can write an accurate summary. The same details will also be valuable to any users of your software who are trying to assess what the impact is for them. Here are some suggestions for details to include in the description:
Information about the attack vector is particularly useful. Try to describe the scenario in which a successful attack could occur—what is the victim doing and what does the attacker do to pwn them? For example, is the software vulnerable in its default configuration, or does it require the victim to do something non-standard, such as installing an extra plugin or running an unusual command? Can the vulnerability be triggered without user interaction, or does the attacker need to trick the victim into doing something like clicking a malicious link? For maximum transparency, you could also consider publishing a proof-of-concept (PoC) exploit of the vulnerability. (If the bug is only hypothetical and you do not have a confirmed PoC then that is definitely worth mentioning in the advisory, as it lowers the risk of exploitation.) Whether to publish a PoC is a judgment call. On the one hand, it could be used to attack your users before they have a chance to patch; on the other hand, it can help people to understand the vulnerability better and allows your users to self-test for vulnerability exposure, which improves their ability to assess the risk. It may also be useful for developing mitigations or for checking whether there has already been a breach.
If in doubt, it is much better to publish a security advisory than to stay silent and hope for the best. Being transparent about potential security vulnerabilities shows that you take security seriously and helps increase trust in your project. The idea that a CVE will bring disgrace on your project is wrong: a CVE is a tracking number—nothing more, nothing less—and does not imply a severity rating. You can use the GitHub Security Advisory system to publish an advisory and request a CVE. Publishing your own advisory is the best way to ensure that the publicly available information is accurate, which will help your users to make a rational assessment of the risk.
This blog post is an in-depth walkthrough on how we perform security research leveraging GitHub features, including code scanning, CodeQL, and Codespaces.
In this post, I’ll look at CVE-2023-6241, a vulnerability in the Arm Mali GPU that allows a malicious app to gain arbitrary kernel code execution and root on an Android phone. I’ll show how this vulnerability can be exploited even when Memory Tagging Extension (MTE), a powerful mitigation, is enabled on the device.
With push protection now enabled by default, GitHub helps open source developers safeguard their secrets, and their reputations.
Madison Oliver 
