About security alerts for vulnerable dependencies

GitHub tracks reported vulnerabilities in certain dependencies and provides security alerts to affected repositories.

In this guide

About security vulnerabilities

A vulnerability is a problem in a project's code that could be exploited to damage the confidentiality, integrity, or availability of the project or other projects that use its code. Depending on the severity level and the way your project uses the dependency, vulnerabilities can cause a range of problems for your project or the people who use it. You can track and resolve vulnerabilities for certain types of dependencies in your GitHub repository.

GitHub's security alerts for vulnerable dependencies

GitHub tracks public vulnerabilities in packages from supported languages on MITRE's Common Vulnerabilities and Exposures (CVE) List. We also scan data in public commits on GitHub and use a combination of machine learning and human review to detect vulnerabilities that are not published in the CVE list.

When GitHub discovers or is notified of a new vulnerability, we identify public repositories (and private repositories that have opted in to vulnerability detection) that use the affected version of the dependency and send a security alert. By default, we send security alerts to owners and people with admin access in the affected repositories. You can also enable security alerts for additional people or teams working in organization-owned repositories. For more information, see "Managing alerts for vulnerable dependencies in your organization's repositories."

GitHub never publicly discloses identified vulnerabilities for any repository.

Each security alert includes a severity level and a link to the affected file in your project. When available, the alert will include further details about the vulnerability and a suggested fix.

Security alerts created from items on the CVE list will contain a link to the CVE record, where you can read more details about the vulnerability, its CVSS scores, and its qualitative severity level. The severity level is one of four possible levels defined in the Common Vulnerability Scoring System (CVSS), Section 2.1.2:

For a list of the supported languages that GitHub can detect vulnerabilities and dependencies for, see "Listing the packages that a repository depends on."

Accessing security alerts

You can see all of the alerts affecting a particular project on the repository's Alerts tab or in the repository's dependency graph. For more information, see "Viewing and updating vulnerable dependencies in your repository."

GitHub detects and alerts on vulnerable dependencies in public repositories by default. To receive security alerts for vulnerable dependencies in a private repository, an owner of or person with admin access to the repository must enable the dependency graph and vulnerability alerts in the repository. For more information, see "Opting into or out of data use for your private repository."

Configuring security alerts

By default, you will receive a weekly email summarizing security alerts for up to 10 of your repositories. You also can choose to receive security alerts individually by email, in a daily digest email, in your web notifications, or in the GitHub user interface. For more information, see "Choosing the delivery method for your notifications."

Investigating and resolving a vulnerability in a dependency

GitHub recommends keeping all dependencies up-to-date.

Note: After you learn about a vulnerable dependency in your repository, you should investigate its impact on your project and verify that the vulnerability is resolved by the version change before you update the dependency. If a safe recommended version does not exist, we recommend removing the dependency altogether in favor of a similar, safe dependency, if one is available.

  1. Read the CVE record to learn more about the vulnerability and its severity level.
  2. Check to see how the vulnerable dependency is used in your project. If the vulnerability is in code that's actively used in your project, you should prioritize the update. For example, if your project uses a vulnerable dependency in test cases, it may have less risk than a vulnerable dependency that your project uses to directly process user input.
  3. Check the documentation for the dependency's recommended version to confirm that the recommended version resolves the vulnerability, and to confirm that the new version is backward compatible with your project.
  4. Confirm that updating the version will completely resolve the vulnerability for your project.
  5. Open a pull request to update the dependency to the recommended safe version and make any changes needed for compatibility. For more information, see "Viewing and updating vulnerable dependencies in your repository."
  6. Ensure that all of your project's tests pass and confirm that the functionality you're updating works correctly, then merge the pull request. For more information see, "About status checks."
  7. Notify project collaborators, owners of any forks of your project, and any projects that depend on yours of the recommended version change and tell them how the previously vulnerable dependency affected your project. For more information, see "Listing the projects that depend on a repository."

Note: GitHub's security features, such as security alerts, do not claim to catch all vulnerabilities. Though we are always trying to update our vulnerability database and alert you with our most up-to-date information, we will not be able to catch everything or alert you to known vulnerabilities within a guaranteed time frame. These features are not substitutes for human review of each dependency for potential vulnerabilities or any other issues, and we recommend consulting with a security service or conducting a thorough vulnerability review when necessary.

Further reading

Ask a human

Can't find what you're looking for?

Contact us