The results of dependency detection reported by GitHub may be different from the results returned by other tools. There are good reasons for this and it's helpful to understand how GitHub determines dependencies for your project.
GitHub generates and displays dependency data differently than other tools. Consequently, if you've been using another tool to identify dependencies you will almost certainly see different results. Consider the following:
GitHub Advisory Database is one of the data sources that GitHub uses to identify vulnerable dependencies. It's a free, curated database of vulnerability information for common package ecosystems on GitHub. It includes both data reported directly to GitHub from GitHub Security Advisories, as well as official feeds and community sources. This data is reviewed and curated by GitHub to ensure that false or unactionable information is not shared with the development community. For more information, see "Browsing security vulnerabilities in the GitHub Advisory Database" and "About GitHub Security Advisories."
The dependency graph parses all known package manifest files in a user’s repository. For example, for npm it will parse the package-lock.json file. It constructs a graph of all of the repository’s dependencies and public dependents. This happens when you enable the dependency graph and when anyone pushes to the default branch, and it includes commits that makes changes to a supported manifest format. For more information, see "About the dependency graph."
Dependabot de GitHub scans any push, to the default branch, that contains a manifest file. When a new vulnerability record is added, it scans all existing repositories and generates an alert for each vulnerable repository. Alertas del Dependabot de GitHub are aggregated at the repository level, rather than creating one alert per vulnerability. For more information, see "About alerts for vulnerable dependencies."
Actualizaciones de seguridad del Dependabot de GitHub are triggered when you receive an alert about a vulnerable dependency in your repository. Where possible, Dependabot de GitHub creates a pull request in your repository to upgrade the vulnerable dependency to the minimum possible secure version needed to avoid the vulnerability. For more information, see "About Actualizaciones de seguridad del Dependabot de GitHub" and "Troubleshooting Dependabot de GitHub errors."
Dependabot de GitHub doesn't scan repositories for vulnerable dependencies on a schedule, but rather when something changes. For example, a scan is triggered when a new dependency is added (GitHub checks for this on every push), or when a new vulnerability is added to the advisory database. For more information, see "About alerts for vulnerable dependencies."
It's worth noting that GitHub Security Advisories may exist for other ecosystems. The information in a security advisory is provided by the maintainers of a particular repository. This data is not curated in the same way as information for the supported ecosystems. For more information, see "About GitHub Security Advisories."
Check: Does the uncaught vulnerability apply to an unsupported ecosystem?
The dependency graph includes information on dependencies that are explicitly declared in your environment. That is, dependencies that are specified in a manifest or a lockfile. The dependency graph generally also includes transitive dependencies, even when they aren't specified in a lockfile, by looking at the dependencies of the dependencies in a manifest file.
Alertas del Dependabot de GitHub advise you about dependencies you should update, including transitive dependencies, where the version can be determined from a manifest or a lockfile. Actualizaciones de seguridad del Dependabot de GitHub only suggest a change where Dependabot de GitHub can directly "fix" the dependency, that is, when these are:
- Direct dependencies explicitly declared in a manifest or lockfile
- Transitive dependencies declared in a lockfile
The dependency graph doesn't include “loose” dependencies. “Loose” dependencies are individual files that are copied from another source and checked into the repository directly or within an archive (such as a ZIP or JAR file), rather than being referenced by in a package manager’s manifest or lockfile.
Check: Is the uncaught vulnerability for a component that's not specified in the repository's manifest or lockfile?
The dependency graph analyzes manifests as they’re pushed to GitHub. The dependency graph doesn't, therefore, have access to the build environment of the project, so it can't resolve variables used within manifests. If you use variables within a manifest to specify the name, or more commonly the version of a dependency, then that dependency will not be included in the dependency graph.
Check: Is the missing dependency declared in the manifest by using a variable for its name or version?
Yes, the dependency graph has two categories of limits:
These affect the dependency graph displayed within GitHub and also prevent Alertas del Dependabot de GitHub being created.
Manifests over 0.5 MB in size are only processed for enterprise accounts. For other accounts, manifests over 0.5 MB are ignored and will not create Alertas del Dependabot de GitHub.
By default, GitHub will not process more than 20 manifests per repository. Alertas del Dependabot de GitHub are not be created for manifests beyond this limit. If you need to increase the limit, contact GitHub Support o GitHub Premium Support.
These affect what's displayed in the dependency graph within GitHub. However, they don't affect the Alertas del Dependabot de GitHub that are created.
The Dependencies view of the dependency graph for a repository only displays 100 manifests. Typically this is adequate as it is significantly higher than the processing limit described above. In situations where the processing limit is over 100, Alertas del Dependabot de GitHub are still created for any manifests that are not shown within GitHub.
Check: Is the missing dependency in a manifest file that's over 0.5 MB, or in a repository with a large number of manifests?
The GitHub Advisory Database was launched in November 2019, and initially back-filled to include vulnerability information for the supported ecosystems, starting from 2017. When adding CVEs to the database, we prioritize curating newer CVEs, and CVEs affecting newer versions of software.
Some information on older vulnerabilities is available, especially where these CVEs are particularly widespread, however some old vulnerabilities are not included in the GitHub Advisory Database. If there's a specific old vulnerability that you need to be included in the database, contact GitHub Support o GitHub Premium Support.
Check: Does the uncaught vulnerability have a publish date earlier than 2017 in the National Vulnerability Database?
Some third-party tools use uncurated CVE data that isn't checked or filtered by a human. This means that CVEs with tagging or severity errors, or other quality issues, will cause more frequent, more noisy, and less useful alerts.
Since Dependabot de GitHub uses curated data in the GitHub Advisory Database, the volume of alerts may be lower, but the alerts you do receive will be accurate and relevant.
When a dependency has multiple vulnerabilities, only one aggregated alert is generated for that dependency, instead of one alert per vulnerability.
The Alertas del Dependabot de GitHub count in GitHub shows a total for the number of alerts, that is, the number of dependencies with vulnerabilities, not the number of vulnerabilities.
When you click to display the alert details, you can see how many vulnerabilities are included in the alert.
Check: If there is a discrepancy in the totals you are seeing, check that you are not comparing alert numbers with vulnerability numbers.