GitHub helps you secure your supply chain, from understanding the dependencies in your environment, to knowing about vulnerabilities in those dependencies, and patching them.
When developing a software project, you likely use other software to build and run your application, such as open-source libraries, frameworks or other tools. These resources are collectively referred to as your “dependencies”, because your project depends on them to function properly. Your project could rely on hundreds of these dependencies, forming what is known as your "supply chain".
Your supply chain can pose a security problem. If one of your dependencies has a known security weakness or a bug, malicious actors could exploit this vulnerability to, for example, insert malicious code ("malware"), steal sensitive data, or cause some other type of disruption to your project. This type of threat is called a "supply chain attack". Having vulnerable dependencies in your supply chain compromises the security of your own project, and you put your users at risk, too.
One of the most important things you can do to protect your supply chain is to patch your vulnerable dependencies and replace any malware.
You add dependencies directly to your supply chain when you specify them in a manifest file or a lockfile. Dependencies can also be included transitively, that is, even if you don’t specify a particular dependency, but a dependency of yours uses it, then you’re also dependent on that dependency.
GitHub offers a range of features to help you understand the dependencies in your environment, know about vulnerabilities in those dependencies, and patch them.
The supply chain features on GitHub are:
The dependency graph is central to supply chain security. The dependency graph identifies all upstream dependencies and public downstream dependents of a repository or package. Your repository’s dependency graph tracks and displays its dependencies and some of their properties, like vulnerability information.
The following supply chain features on GitHub rely on the information provided by the dependency graph.
Dependabot version updates don't use the dependency graph and rely on the semantic versioning of dependencies instead. Dependabot version updates help you keep your dependencies updated, even when they don’t have any vulnerabilities.
For best practice guides on end-to-end supply chain security including the protection of personal accounts, code, and build processes, see Securing your end-to-end supply chain.
To generate the dependency graph, GitHub looks at a repository’s explicit dependencies declared in the manifest and lockfiles. When enabled, the dependency graph automatically parses all known package manifest files in the repository, and uses this to construct a graph with known dependency names and versions.
You can use the dependency submission API to submit dependencies from the package manager or ecosystem of your choice, even if the ecosystem is not supported by dependency graph for manifest or lock file analysis.
Dependencies submitted to a project using the dependency submission API will show which detector was used for their submission and when they were submitted. For more information on the dependency submission API, see Using the dependency submission API.
For more information about the dependency graph, see Dependency graph.
Dependency review helps reviewers and contributors understand dependency changes and their security impact in every pull request.
For more information about dependency review, see Dependency review.
Dependabot keeps your dependencies up to date by informing you of any security vulnerabilities in your dependencies and automatically opening pull requests to upgrade your dependencies. Dependabot pull requests will target the next available secure version when a Dependabot alert is triggered, or to the latest version when a release is published.
The term "Dependabot" encompasses the following features:
Pull requests opened by Dependabot can trigger workflows that run actions. For more information, see Automating Dependabot with GitHub Actions.
By default:
If GitHub Actions is enabled for the repository, GitHub runs Dependabot updates on GitHub Actions.
If GitHub Actions is not enabled for the repository, GitHub generates Dependabot alerts using its built-in Dependabot application.
For more information, see Dependabot on GitHub Actions runners.
Dependabot security updates can fix vulnerable dependencies in GitHub Actions. When security updates are enabled, Dependabot will automatically raise a pull request to update vulnerable GitHub Actions used in your workflows to the minimum patched version. For more information, see Dependabot security updates.
Dependabot alerts highlight repositories affected by a newly discovered vulnerability based on the dependency graph and the GitHub Advisory Database, which contains advisories for known vulnerabilities.
Dependabot performs a scan to detect insecure dependencies and sends Dependabot alerts when:
Dependabot alerts are displayed on the Security and quality tab for the repository and in the repository's dependency graph. The alert includes a link to the affected file in the project, and information about a fixed version.
For more information, see Dependabot alerts.
Dependabot malware alerts flag malicious dependencies in your repositories. Dependabot generates alerts using the GitHub Advisory Database, which contains advisories for known vulnerabilities and malicious packages.
Dependabot scans for malicious packages and sends alerts when:
You can view malware alerts for a repository:
Each alert includes a link to the affected file in the project, as well as the patch version number for the package (if available).
There are two types of Dependabot updates: Dependabot security updates and version updates. Dependabot generates automatic pull requests to update your dependencies in both cases, but there are several differences.
Dependabot security updates:
Dependabot version updates:
For more information about Dependabot updates, see Dependabot security updates and Dependabot version updates.
Repositories can enable immutable releases to prevent the assets and associated Git tag of a release from being changed after publication. This reduces the risk of supply chain attacks by preventing attackers from injecting vulnerabilities into releases you consume. It also means projects that rely on specific releases are less likely to break.
Creating an immutable release automatically generates an attestation for the release. You can use this attestation to make sure the release and its artifacts match the published information.
Software providers can generate attestations for software built with GitHub Actions. Attestations are cryptographically signed claims that establish the build's provenance (the source code and workflow run used to build it) or associated software bill of materials (SBOM).
You can increase supply chain security by verifying attestations for your dependencies. Although attestations do not guarantee security, they give you information about where and how software was built, so you can be more confident that your dependencies haven't been tampered with. You can gate deployments using a tool like the Kubernetes admissions controller to prevent unattested builds from being deployed.
When you use GitHub Actions to generate attestations for your organization's own builds, the built artifacts are automatically uploaded to the linked artifacts page. This platform allows you to view the storage and deployment records of all linked artifacts, so you can find the source code and workflow run used to build an artifact or filter security alerts based on deployment context.