Group user docs on code security into a new "product" (#18196)
This commit is contained in:
Felicity Chapman
@@ -1,55 +0,0 @@
|
||||
---
|
||||
title: About Dependabot version updates
|
||||
intro: 'You can use {% data variables.product.prodname_dependabot %} to keep the packages you use updated to the latest versions.'
|
||||
redirect_from:
|
||||
- /github/administering-a-repository/about-dependabot
|
||||
- /github/administering-a-repository/about-github-dependabot
|
||||
- /github/administering-a-repository/about-github-dependabot-version-updates
|
||||
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
{% data reusables.dependabot.beta-note %}
|
||||
|
||||
### About {% data variables.product.prodname_dependabot_version_updates %}
|
||||
|
||||
{% data variables.product.prodname_dependabot %} takes the effort out of maintaining your dependencies. You can use it to ensure that your repository automatically keeps up with the latest releases of the packages and applications it depends on.
|
||||
|
||||
You enable {% data variables.product.prodname_dependabot_version_updates %} by checking a configuration file into your repository. The configuration file specifies the location of the manifest, or of other package definition files, stored in your repository. {% data variables.product.prodname_dependabot %} uses this information to check for outdated packages and applications. {% data variables.product.prodname_dependabot %} determines if there is a new version of a dependency by looking at the semantic versioning ([semver](https://semver.org/)) of the dependency to decide whether it should update to that version. For certain package managers, {% data variables.product.prodname_dependabot_version_updates %} also supports vendoring. Vendored (or cached) dependencies are dependencies that are checked in to a specific directory in a repository rather than referenced in a manifest. Vendored dependencies are available at build time even if package servers are unavailable. {% data variables.product.prodname_dependabot_version_updates %} can be configured to check vendored dependencies for new versions and update them if necessary.
|
||||
|
||||
When {% data variables.product.prodname_dependabot %} identifies an outdated dependency, it raises a pull request to update the manifest to the latest version of the dependency. For vendored dependencies, {% data variables.product.prodname_dependabot %} raises a pull request to replace the outdated dependency with the new version directly. You check that your tests pass, review the changelog and release notes included in the pull request summary, and then merge it. For more information, see "[Enabling and disabling version updates](/github/administering-a-repository/enabling-and-disabling-version-updates)."
|
||||
|
||||
If you enable security updates, {% data variables.product.prodname_dependabot %} also raises pull requests to update vulnerable dependencies. For more information, see "[About {% data variables.product.prodname_dependabot_security_updates %}](/github/managing-security-vulnerabilities/about-dependabot-security-updates)."
|
||||
|
||||
{% data reusables.dependabot.pull-request-security-vs-version-updates %}
|
||||
|
||||
{% data reusables.dependabot.dependabot-tos %}
|
||||
|
||||
### Frequency of {% data variables.product.prodname_dependabot %} pull requests
|
||||
|
||||
You specify how often to check each ecosystem for new versions in the configuration file: daily, weekly, or monthly.
|
||||
|
||||
{% data reusables.dependabot.initial-updates %}
|
||||
|
||||
If you've enabled security updates, you'll sometimes see extra pull requests for security updates. These are triggered by a {% data variables.product.prodname_dependabot %} alert for a dependency on your default branch. {% data variables.product.prodname_dependabot %} automatically raises a pull request to update the vulnerable dependency.
|
||||
|
||||
### Supported repositories and ecosystems
|
||||
|
||||
You can configure version updates for repositories that contain a dependency manifest or lock file for one of the supported package managers. For some package managers, you can also configure vendoring for dependencies. For more information, see "[Configuration options for dependency updates](/github/administering-a-repository/configuration-options-for-dependency-updates#vendor)."
|
||||
|
||||
{% note %}
|
||||
|
||||
{% data reusables.dependabot.private-dependencies-note %}
|
||||
|
||||
{% data variables.product.prodname_dependabot %} doesn't support private {% data variables.product.prodname_dotcom %} dependencies for all package managers. See the details in the table below.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% data reusables.dependabot.supported-package-managers %}
|
||||
|
||||
If your repository already uses an integration for dependency management, you will need to disable this before enabling {% data variables.product.prodname_dependabot %}. For more information, see "[About integrations](/github/customizing-your-github-workflow/about-integrations)."
|
||||
|
||||
### About notifications for {% data variables.product.prodname_dependabot %} version updates
|
||||
|
||||
You can filter your notifications on {% data variables.product.company_short %} to show {% data variables.product.prodname_dependabot %} version updates. For more information, see "[Managing notifications from your inbox](/github/managing-subscriptions-and-notifications-on-github/managing-notifications-from-your-inbox#dependabot-custom-filters)."
|
||||
@@ -1,78 +0,0 @@
|
||||
---
|
||||
title: About secret scanning
|
||||
intro: '{% data variables.product.product_name %} scans repositories for known types of secrets, to prevent fraudulent use of secrets that were committed accidentally.'
|
||||
product: '{% data reusables.gated-features.secret-scanning %}'
|
||||
redirect_from:
|
||||
- /github/administering-a-repository/about-token-scanning
|
||||
- /articles/about-token-scanning
|
||||
- /articles/about-token-scanning-for-private-repositories
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=3.0'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
{% data reusables.secret-scanning.beta %}
|
||||
{% data reusables.secret-scanning.enterprise-enable-secret-scanning %}
|
||||
|
||||
If your project communicates with an external service, you might use a token or private key for authentication. Tokens and private keys are examples of secrets that a service provider can issue. If you check a secret into a repository, anyone who has read access to the repository can use the secret to access the external service with your privileges. We recommend that you store secrets in a dedicated, secure location outside of the repository for your project.
|
||||
|
||||
Service providers can partner with {% data variables.product.company_short %} to provide their secret formats for scanning.{% if currentVersion == "free-pro-team@latest" %} For more information, see "[Secret scanning](/developers/overview/secret-scanning)."
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.secret-scanning.about-secret-scanning %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
### About {% data variables.product.prodname_secret_scanning %} for public repositories
|
||||
|
||||
{% data variables.product.prodname_secret_scanning_caps %} is automatically enabled on public repositories. When you push to a public repository, {% data variables.product.product_name %} scans the content of the commits for secrets. If you switch a private repository to public, {% data variables.product.product_name %} scans the entire repository for secrets.
|
||||
|
||||
When {% data variables.product.prodname_secret_scanning %} detects a set of credentials, we notify the service provider who issued the secret. The service provider validates the credential and then decides whether they should revoke the secret, issue a new secret, or reach out to you directly, which will depend on the associated risks to you or the service provider. For an overview of how we work with token-issuing partners, see "[Secret scanning](/developers/overview/secret-scanning)."
|
||||
|
||||
{% data variables.product.product_name %} currently scans public repositories for secrets issued by the following service providers.
|
||||
|
||||
{% data reusables.secret-scanning.partner-secret-list-public-repo %}
|
||||
|
||||
### About {% data variables.product.prodname_secret_scanning %} for private repositories
|
||||
{% endif %}
|
||||
|
||||
{% if currentVersion ver_gt "enterprise-server@2.22" or currentVersion == "github-ae@latest" %}
|
||||
### About {% data variables.product.prodname_secret_scanning %} on {% data variables.product.product_name %}
|
||||
|
||||
{% data variables.product.prodname_secret_scanning_caps %} is available on all organization-owned repositories as part of {% data variables.product.prodname_GH_advanced_security %}. It is not available on user-owned repositories.
|
||||
{% endif %}
|
||||
|
||||
If you're a repository administrator or an organization owner, you can enable {% data variables.product.prodname_secret_scanning %} for {% if currentVersion == "free-pro-team@latest" %} private{% endif %} repositories that are owned by organizations. You can enable {% data variables.product.prodname_secret_scanning %} for all your repositories, or for all new repositories within your organization.{% if currentVersion == "free-pro-team@latest" %} {% data variables.product.prodname_secret_scanning_caps %} is not available for user-owned private repositories.{% endif %} For more information, see "[Managing security and analysis settings for your repository](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository)" and "[Managing security and analysis settings for your organization](/github/setting-up-and-managing-organizations-and-teams/managing-security-and-analysis-settings-for-your-organization)."
|
||||
|
||||
When you push commits to a{% if currentVersion == "free-pro-team@latest" %} private{% endif %} repository with {% data variables.product.prodname_secret_scanning %} enabled, {% data variables.product.prodname_dotcom %} scans the contents of the commits for secrets.
|
||||
|
||||
When {% data variables.product.prodname_secret_scanning %} detects a secret in a{% if currentVersion == "free-pro-team@latest" %} private{% endif %} repository, {% data variables.product.prodname_dotcom %} generates an alert.
|
||||
|
||||
- {% data variables.product.prodname_dotcom %} sends an email alert to the repository administrators and organization owners.
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" or currentVersion == 'github-ae@next' %}
|
||||
- {% data variables.product.prodname_dotcom %} sends an email alert to the contributor who committed the secret to the repository, with a link to the related {% data variables.product.prodname_secret_scanning %} alert. The commit author can then view the alert in the repository, and resolve the alert.
|
||||
{% endif %}
|
||||
- {% data variables.product.prodname_dotcom %} displays an alert in the repository.{% if currentVersion == "enterprise-server@3.0" %} For more information, see "[Managing alerts from {% data variables.product.prodname_secret_scanning %}](/github/administering-a-repository/managing-alerts-from-secret-scanning)."{% endif %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" or currentVersion == 'github-ae@next' %}
|
||||
For more information about viewing and resolving {% data variables.product.prodname_secret_scanning %} alerts, see "[Managing alerts from {% data variables.product.prodname_secret_scanning %}](/github/administering-a-repository/managing-alerts-from-secret-scanning)."{% endif %}
|
||||
|
||||
Repository administrators and organization owners can grant users and teams access to {% data variables.product.prodname_secret_scanning %} alerts. For more information, see "[Managing security and analysis settings for your repository](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository#granting-access-to-security-alerts)."
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
|
||||
To monitor results from {% data variables.product.prodname_secret_scanning %} across your private repositories or your organization, you can use the {% data variables.product.prodname_secret_scanning %} API. For more information about API endpoints, see "[{% data variables.product.prodname_secret_scanning_caps %}](/rest/reference/secret-scanning)."{% endif %}
|
||||
|
||||
{% data variables.product.prodname_dotcom %} currently scans{% if currentVersion == "free-pro-team@latest" %} private{% endif %} repositories for secrets issued by the following service providers.
|
||||
|
||||
{% data reusables.secret-scanning.partner-secret-list-private-repo %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** {% data variables.product.prodname_secret_scanning_caps %} does not currently allow you to define your own patterns for detecting secrets.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[About securing your repository](/github/administering-a-repository/about-securing-your-repository)"
|
||||
- "[Keeping your account and data secure](/github/authenticating-to-github/keeping-your-account-and-data-secure)"
|
||||
@@ -1,81 +0,0 @@
|
||||
---
|
||||
title: About securing your repository
|
||||
intro: '{% data variables.product.product_name %} provides a number of ways that you can help keep your repository secure.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=3.0'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
### Setting up your repository securely
|
||||
|
||||
The first step to securing a repository is to set up who can see and modify your code. For more information, see "[Managing repository settings](/github/administering-a-repository/managing-repository-settings)."
|
||||
|
||||
### Securing your repository
|
||||
|
||||
{% data variables.product.prodname_dotcom %} has a growing set of security features that help you keep your code secure. You can find these on the **Security** tab for your repository.
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
#### Available for all repositories
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
- **Security policy**
|
||||
|
||||
Make it easy for people to confidentially report security vulnerabilities they've found in your repository. For more information, see "[Adding a security policy to your repository](/github/managing-security-vulnerabilities/adding-a-security-policy-to-your-repository)."
|
||||
|
||||
- **Security advisories**
|
||||
|
||||
Privately discuss and fix security vulnerabilities in your repository's code. You can then publish a security advisory to alert your community to the vulnerability and encourage them to upgrade. For more information, see "[About {% data variables.product.prodname_security_advisories %}](/github/managing-security-vulnerabilities/about-github-security-advisories)."
|
||||
|
||||
- **{% data variables.product.prodname_dependabot_alerts %} and security updates**
|
||||
|
||||
View alerts about dependencies that are known to contain security vulnerabilities, and choose whether to have pull requests generated automatically to update these dependencies. For more information, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies)"
|
||||
and "[About {% data variables.product.prodname_dependabot_security_updates %}](/github/managing-security-vulnerabilities/about-dependabot-security-updates)."
|
||||
{% endif %}
|
||||
|
||||
{% if currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
- **{% data variables.product.prodname_dependabot_alerts %}**
|
||||
|
||||
View alerts about dependencies that are known to contain security vulnerabilities, and manage these alerts. For more information, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies)."
|
||||
{% endif %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
- **{% data variables.product.prodname_dependabot %} version updates**
|
||||
|
||||
Use {% data variables.product.prodname_dependabot %} to automatically raise pull requests to keep your dependencies up-to-date. This helps reduce your exposure to older versions of dependencies. Using newer versions makes it easier to apply patches if security vulnerabilities are discovered, and also makes it easier for {% data variables.product.prodname_dependabot_security_updates %} to successfully raise pull requests to upgrade vulnerable dependencies. For more information, see "[About {% data variables.product.prodname_dependabot_version_updates %}](/github/administering-a-repository/about-dependabot-version-updates)."
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" or currentVersion == "github-ae@latest" %}
|
||||
|
||||
#### Available {% if currentVersion == "free-pro-team@latest" %}for public repositories and for repositories {% endif %}with {% data variables.product.prodname_advanced_security %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
These features are available {% if currentVersion == "free-pro-team@latest" %}for all public repositories, and for private repositories owned by organizations with {% else %}if you have {% endif %}an {% data variables.product.prodname_advanced_security %} license. {% data reusables.advanced-security.more-info-ghas %}
|
||||
{% endif %}
|
||||
|
||||
- **{% data variables.product.prodname_code_scanning_capc %} alerts**
|
||||
|
||||
Automatically detect security vulnerabilities and coding errors in new or modified code. Potential problems are highlighted, with detailed information, allowing you to fix the code before it's merged into your default branch. For more information, see "[About code scanning](/github/finding-security-vulnerabilities-and-errors-in-your-code/about-code-scanning)."
|
||||
|
||||
- **Detected secrets**
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}For private repositories, view {% else %}View {% endif %}any secrets that {% data variables.product.prodname_dotcom %} has found in your code. You should treat tokens or credentials that have been checked into the repository as compromised. For more information, see "[About secret scanning](/github/administering-a-repository/about-secret-scanning)."
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
- **Dependency review** - Show the full impact of changes to dependencies and see details of any vulnerable versions before you merge a pull request. For more information, see "[Reviewing dependency changes in a pull request](/github/collaborating-with-issues-and-pull-requests/reviewing-dependency-changes-in-a-pull-request)."
|
||||
{% endif %}
|
||||
|
||||
{% if currentVersion != "github-ae@latest" %}
|
||||
### Exploring dependencies
|
||||
{% data variables.product.prodname_dotcom %}'s dependency graph allows you to explore:
|
||||
|
||||
* Ecosystems and packages that your repository depends on
|
||||
* Repositories and packages that depend on your repository
|
||||
|
||||
You must enable the dependency graph before {% data variables.product.prodname_dotcom %} can generate {% data variables.product.prodname_dependabot_alerts %} for dependencies with security vulnerabilities. {% if currentVersion == "free-pro-team@latest" %}Enabling the dependency graph also enables {% data variables.product.prodname_dotcom %} to run dependency reviews of pull requests.{% endif %}
|
||||
|
||||
You can find the dependency graph on the **Insights** tab for your repository. For more information, see "[About the dependency graph](/github/visualizing-repository-data-with-graphs/about-the-dependency-graph)."
|
||||
{% endif %}
|
||||
@@ -1,908 +0,0 @@
|
||||
---
|
||||
title: Configuration options for dependency updates
|
||||
intro: 'Detailed information for all the options you can use to customize how {% data variables.product.prodname_dependabot %} maintains your repositories.'
|
||||
permissions: 'People with write permissions to a repository can configure {% data variables.product.prodname_dependabot %} for the repository.'
|
||||
miniTocMaxHeadingLevel: 4
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
{% data reusables.dependabot.beta-note %}
|
||||
|
||||
### About the *dependabot.yml* file
|
||||
|
||||
The {% data variables.product.prodname_dependabot %} configuration file, *dependabot.yml*, uses YAML syntax. If you're new to YAML and want to learn more, see "[Learn YAML in five minutes](https://www.codeproject.com/Articles/1214409/Learn-YAML-in-five-minutes)."
|
||||
|
||||
You must store this file in the `.github` directory of your repository. When you add or update the *dependabot.yml* file, this triggers an immediate check for version updates. Any options that also affect security updates are used the next time a security alert triggers a pull request for a security update. For more information, see "[Enabling and disabling version updates](/github/administering-a-repository/enabling-and-disabling-version-updates)" and "[Configuring {% data variables.product.prodname_dependabot_security_updates %}](/github/managing-security-vulnerabilities/configuring-dependabot-security-updates)."
|
||||
|
||||
The *dependabot.yml* file has two mandatory top-level keys: `version`, and `updates`. You can, optionally, include a top-level `registries` key. The file must start with `version: 2`.
|
||||
|
||||
### Configuration options for updates
|
||||
|
||||
The top-level `updates` key is mandatory. You use it to configure how {% data variables.product.prodname_dependabot %} updates the versions or your project's dependencies. Each entry configures the update settings for a particular package manager. You can use the following options.
|
||||
|
||||
| Option | Required | Description |
|
||||
|:---|:---:|:---|
|
||||
| [`package-ecosystem`](#package-ecosystem) | **X** | Package manager to use |
|
||||
| [`directory`](#directory) | **X** | Location of package manifests |
|
||||
| [`schedule.interval`](#scheduleinterval) | **X** | How often to check for updates |
|
||||
| [`allow`](#allow) | | Customize which updates are allowed |
|
||||
| [`assignees`](#assignees) | | Assignees to set on pull requests |
|
||||
| [`commit-message`](#commit-message) | | Commit message preferences |
|
||||
| [`ignore`](#ignore) | | Ignore certain dependencies or versions |
|
||||
| [`insecure-external-code-execution`](#insecure-external-code-execution) | | Allow or deny code execution in manifest files |
|
||||
| [`labels`](#labels) | | Labels to set on pull requests |
|
||||
| [`milestone`](#milestone) | | Milestone to set on pull requests |
|
||||
| [`open-pull-requests-limit`](#open-pull-requests-limit) | | Limit number of open pull requests for version updates|
|
||||
| [`pull-request-branch-name.separator`](#pull-request-branch-nameseparator) | | Change separator for pull request branch names |
|
||||
| [`rebase-strategy`](#rebase-strategy) | | Disable automatic rebasing |
|
||||
| [`registries`](#registries) | | Private registries that {% data variables.product.prodname_dependabot %} can access|
|
||||
| [`reviewers`](#reviewers) | | Reviewers to set on pull requests |
|
||||
| [`schedule.day`](#scheduleday) | | Day of week to check for updates |
|
||||
| [`schedule.time`](#scheduletime) | | Time of day to check for updates (hh:mm) |
|
||||
| [`schedule.timezone`](#scheduletimezone) | | Timezone for time of day (zone identifier) |
|
||||
| [`target-branch`](#target-branch) | | Branch to create pull requests against |
|
||||
| [`vendor`](#vendor) | | Update vendored or cached dependencies |
|
||||
| [`versioning-strategy`](#versioning-strategy) | | How to update manifest version requirements |
|
||||
|
||||
These options fit broadly into the following categories.
|
||||
|
||||
- Essential set up options that you must include in all configurations: [`package-ecosystem`](#package-ecosystem), [`directory`](#directory),[`schedule.interval`](#scheduleinterval).
|
||||
- Options to customize the update schedule: [`schedule.time`](#scheduletime), [`schedule.timezone`](#scheduletimezone), [`schedule.day`](#scheduleday).
|
||||
- Options to control which dependencies are updated: [`allow`](#allow), [`ignore`](#ignore), [`vendor`](#vendor).
|
||||
- Options to add metadata to pull requests: [`reviewers`](#reviewers), [`assignees`](#assignees), [`labels`](#labels), [`milestone`](#milestone).
|
||||
- Options to change the behavior of the pull requests: [`target-branch`](#target-branch), [`versioning-strategy`](#versioning-strategy), [`commit-message`](#commit-message), [`rebase-strategy`](#rebase-strategy), [`pull-request-branch-name.separator`](#pull-request-branch-nameseparator).
|
||||
|
||||
In addition, the [`open-pull-requests-limit`](#open-pull-requests-limit) option changes the maximum number of pull requests for version updates that {% data variables.product.prodname_dependabot %} can open.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Some of these configuration options may also affect pull requests raised for security updates of vulnerable package manifests.
|
||||
|
||||
Security updates are raised for vulnerable package manifests only on the default branch. When configuration options are set for the same branch (true unless you use `target-branch`), and specify a `package-ecosystem` and `directory` for the vulnerable manifest, then pull requests for security updates use relevant options.
|
||||
|
||||
In general, security updates use any configuration options that affect pull requests, for example, adding metadata or changing their behavior. For more information about security updates, see "[Configuring {% data variables.product.prodname_dependabot_security_updates %}](/github/managing-security-vulnerabilities/configuring-dependabot-security-updates)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
#### `package-ecosystem`
|
||||
|
||||
**Required**. You add one `package-ecosystem` element for each package manager that you want {% data variables.product.prodname_dependabot %} to monitor for new versions. The repository must also contain a dependency manifest or lock file for each of these package managers. If you want to enable vendoring for a package manager that supports it, the vendored dependencies must be located in the required directory. For more information, see [`vendor`](#vendor) below.
|
||||
|
||||
{% data reusables.dependabot.supported-package-managers %}
|
||||
|
||||
```yaml
|
||||
# Basic set up for three package managers
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
|
||||
# Maintain dependencies for GitHub Actions
|
||||
- package-ecosystem: "github-actions"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
|
||||
# Maintain dependencies for npm
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
|
||||
# Maintain dependencies for Composer
|
||||
- package-ecosystem: "composer"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
```
|
||||
|
||||
#### `directory`
|
||||
|
||||
**Required**. You must define the location of the package manifests for each package manager (for example, the *package.json* or *Gemfile*). You define the directory relative to the root of the repository for all ecosystems except GitHub Actions. For GitHub Actions, set the directory to `/` to check for workflow files in `.github/workflows`.
|
||||
|
||||
```yaml
|
||||
# Specify location of manifest files for each package manager
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "composer"
|
||||
# Files stored in repository root
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
|
||||
- package-ecosystem: "npm"
|
||||
# Files stored in `app` directory
|
||||
directory: "/app"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
|
||||
- package-ecosystem: "github-actions"
|
||||
# Workflow files stored in the
|
||||
# default location of `.github/workflows`
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
```
|
||||
|
||||
#### `schedule.interval`
|
||||
|
||||
**Required**. You must define how often to check for new versions for each package manager. By default, this is at 5am UTC. To modify this, use [`schedule.time`](#scheduletime) and [`schedule.timezone`](#scheduletimezone).
|
||||
|
||||
- `daily`—runs on every weekday, Monday to Friday.
|
||||
- `weekly`—runs once each week. By default, this is on Monday. To modify this, use [`schedule.day`](#scheduleday).
|
||||
- `monthly`—runs once each month. This is on the first day of the month.
|
||||
|
||||
```yaml
|
||||
# Set update schedule for each package manager
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
|
||||
- package-ecosystem: "github-actions"
|
||||
directory: "/"
|
||||
schedule:
|
||||
# Check for updates to GitHub Actions every weekday
|
||||
interval: "daily"
|
||||
|
||||
- package-ecosystem: "composer"
|
||||
directory: "/"
|
||||
schedule:
|
||||
# Check for updates managed by Composer once a week
|
||||
interval: "weekly"
|
||||
```
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note**: `schedule` defines when {% data variables.product.prodname_dependabot %} attempts a new update. However, it's not the only time you may receive pull requests. Updates can be triggered based on changes to your `dependabot.yml` file, changes to your manifest file(s) after a failed update, or {% data variables.product.prodname_dependabot_security_updates %}. For more information, see "[Frequency of {% data variables.product.prodname_dependabot %} pull requests](/github/administering-a-repository/about-dependabot-version-updates#frequency-of-dependabot-pull-requests)" and "[About {% data variables.product.prodname_dependabot_security_updates %}](/github/managing-security-vulnerabilities/about-dependabot-security-updates)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
#### `allow`
|
||||
|
||||
{% data reusables.dependabot.default-dependencies-allow-ignore %}
|
||||
|
||||
Use the `allow` option to customize which dependencies are updated. This has no impact on security updates for vulnerable dependencies. You can use the following options:
|
||||
|
||||
- `dependency-name`—use to allow updates for dependencies with matching names, optionally using `*` to match zero or more characters. For Java dependencies, the format of the `dependency-name` attribute is: `groupId:artifactId`, for example: `org.kohsuke:github-api`.
|
||||
- `dependency-type`—use to allow updates for dependencies of specific types.
|
||||
|
||||
| Dependency types | Supported by package managers | Allow updates |
|
||||
|------------------|-------------------------------|--------|
|
||||
| `direct` | All | All explicitly defined dependencies. |
|
||||
| `indirect` | `bundler`, `pip`, `composer`, `cargo` | Dependencies of direct dependencies (also known as sub-dependencies, or transient dependencies).|
|
||||
| `all` | All | All explicitly defined dependencies. For `bundler`, `pip`, `composer`, `cargo`, also the dependencies of direct dependencies.|
|
||||
| `production` | `bundler`, `composer`, `mix`, `maven`, `npm`, `pip` | Only dependencies in the "Product dependency group". |
|
||||
| `development`| `bundler`, `composer`, `mix`, `maven`, `npm`, `pip` | Only dependencies in the "Development dependency group". |
|
||||
|
||||
```yaml
|
||||
# Use `allow` to specify which dependencies to maintain
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
allow:
|
||||
# Allow updates for Lodash
|
||||
- dependency-name: "lodash"
|
||||
# Allow updates for React and any packages starting "react"
|
||||
- dependency-name: "react*"
|
||||
|
||||
- package-ecosystem: "composer"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
allow:
|
||||
# Allow both direct and indirect updates for all packages
|
||||
- dependency-type: "all"
|
||||
|
||||
- package-ecosystem: "pip"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
allow:
|
||||
# Allow only direct updates for
|
||||
# Django and any packages starting "django"
|
||||
- dependency-name: "django*"
|
||||
dependency-type: "direct"
|
||||
# Allow only production updates for Sphinx
|
||||
- dependency-name: "sphinx"
|
||||
dependency-type: "production"
|
||||
```
|
||||
|
||||
#### `assignees`
|
||||
|
||||
Use `assignees` to specify individual assignees for all pull requests raised for a package manager.
|
||||
|
||||
{% data reusables.dependabot.option-affects-security-updates %}
|
||||
|
||||
```yaml
|
||||
# Specify assignees for pull requests
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Add assignees
|
||||
assignees:
|
||||
- "octocat"
|
||||
```
|
||||
|
||||
#### `commit-message`
|
||||
|
||||
By default, {% data variables.product.prodname_dependabot %} attempts to detect your commit message preferences and use similar patterns. Use the `commit-message` option to specify your preferences explicitly.
|
||||
|
||||
Supported options
|
||||
|
||||
- `prefix` specifies a prefix for all commit messages.
|
||||
- `prefix-development` specifies a separate prefix for all commit messages that update dependencies in the Development dependency group. When you specify a value for this option, the `prefix` is used only for updates to dependencies in the Production dependency group. This is supported by: `bundler`, `composer`, `mix`, `maven`, `npm`, and `pip`.
|
||||
- `include: "scope"` specifies that any prefix is followed by a list of the dependencies updated in the commit.
|
||||
|
||||
{% data reusables.dependabot.option-affects-security-updates %}
|
||||
|
||||
```yaml
|
||||
# Customize commit messages
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
commit-message:
|
||||
# Prefix all commit messages with "npm"
|
||||
prefix: "npm"
|
||||
|
||||
- package-ecosystem: "composer"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Prefix all commit messages with "Composer"
|
||||
# include a list of updated dependencies
|
||||
commit-message:
|
||||
prefix: "Composer"
|
||||
include: "scope"
|
||||
|
||||
- package-ecosystem: "pip"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Include a list of updated dependencies
|
||||
# with a prefix determined by the dependency group
|
||||
commit-message:
|
||||
prefix: "pip prod"
|
||||
prefix-development: "pip dev"
|
||||
include: "scope"
|
||||
```
|
||||
|
||||
#### `ignore`
|
||||
|
||||
{% data reusables.dependabot.warning-ignore-option %}
|
||||
|
||||
##### Checking for existing ignore preferences
|
||||
|
||||
Before you add an `ignore` option to the configuration file, check whether you've previously used any of the `@dependabot ignore` commands on a security update or version update pull request. {% data variables.product.prodname_dependabot %} stores these preferences for each package manager centrally and this information is overwritten by the `ignore` option. For more information about the `@dependabot ignore` commands, see "[Managing pull requests for dependency updates](/github/administering-a-repository/managing-pull-requests-for-dependency-updates)."
|
||||
|
||||
You can check whether a repository has stored preferences by searching the repository for `"@dependabot ignore" in:comments`. If you review any pull requests in the results, you can decide whether or not to specify those ignored dependencies or versions in the configuration file.
|
||||
|
||||
##### Specifying dependencies and versions to ignore
|
||||
|
||||
{% data reusables.dependabot.default-dependencies-allow-ignore %}
|
||||
|
||||
You can use the `ignore` option to customize which dependencies are updated. The `ignore` option supports the following options.
|
||||
|
||||
- `dependency-name`—use to ignore updates for dependencies with matching names, optionally using `*` to match zero or more characters. For Java dependencies, the format of the `dependency-name` attribute is: `groupId:artifactId`, for example: `org.kohsuke:github-api`.
|
||||
- `versions`—use to ignore specific versions or ranges of versions. If you want to define a range, use the standard pattern for the package manager (for example: `^1.0.0` for npm, or `~> 2.0` for Bundler).
|
||||
|
||||
{% data reusables.dependabot.option-affects-security-updates %}
|
||||
|
||||
```yaml
|
||||
# Use `ignore` to specify dependencies that should not be updated
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
ignore:
|
||||
- dependency-name: "express"
|
||||
# For Express, ignore all updates for version 4 and 5
|
||||
versions: ["4.x", "5.x"]
|
||||
# For Lodash, ignore all updates
|
||||
- dependency-name: "lodash"
|
||||
```
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note**: {% data variables.product.prodname_dependabot %} can only run version updates on manifest or lock files if it can access all of the dependencies in the file, even if you add inaccessible dependencies to the `ignore` option of your configuration file. For more information, see "[Managing security and analysis settings for your organization](/github/setting-up-and-managing-organizations-and-teams/managing-security-and-analysis-settings-for-your-organization#allowing-dependabot-to-access-private-dependencies)" and "[Troubleshooting {% data variables.product.prodname_dependabot %} errors](/github/managing-security-vulnerabilities/troubleshooting-dependabot-errors#dependabot-cant-resolve-your-dependency-files)."
|
||||
|
||||
|
||||
{% endnote %}
|
||||
|
||||
#### `insecure-external-code-execution`
|
||||
|
||||
Package managers with the `package-ecosystem` values `bundler`, `mix`, and `pip` may execute external code in the manifest as part of the version update process. This might allow a compromised package to steal credentials or gain access to configured registries. When you add a [`registries`](#registries) setting within an `updates` configuration, {% data variables.product.prodname_dependabot %} automatically prevents external code execution, in which case the version update may fail. You can choose to override this behavior and allow external code execution for `bundler`, `mix`, and `pip` package managers by setting `insecure-external-code-execution` to `allow`.
|
||||
|
||||
You can explicitly deny external code execution, irrespective of whether there is a `registries` setting for this update configuration, by setting `insecure-external-code-execution` to `deny`.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
# Allow external code execution when updating dependencies from private registries
|
||||
|
||||
version: 2
|
||||
registries:
|
||||
ruby-github:
|
||||
type: rubygems-server
|
||||
url: https://rubygems.pkg.github.com/octocat/github_api
|
||||
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
|
||||
updates:
|
||||
- package-ecosystem: "bundler"
|
||||
directory: "/rubygems-server"
|
||||
insecure-external-code-execution: allow
|
||||
registries: "*"
|
||||
schedule:
|
||||
interval: "monthly"
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### `labels`
|
||||
|
||||
{% data reusables.dependabot.default-labels %}
|
||||
|
||||
Use `labels` to override the default labels and specify alternative labels for all pull requests raised for a package manager. If any of these labels is not defined in the repository, it is ignored.
|
||||
To disable all labels, including the default labels, use `labels: [ ]`.
|
||||
|
||||
{% data reusables.dependabot.option-affects-security-updates %}
|
||||
|
||||
```yaml
|
||||
# Specify labels for pull requests
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Specify labels for npm pull requests
|
||||
labels:
|
||||
- "npm"
|
||||
- "dependencies"
|
||||
```
|
||||
|
||||
#### `milestone`
|
||||
|
||||
Use `milestone` to associate all pull requests raised for a package manager with a milestone. You need to specify the numeric identifier of the milestone and not its label. If you view a milestone, the final part of the page URL, after `milestone`, is the identifier. For example: `https://github.com/<org>/<repo>/milestone/3`.
|
||||
|
||||
{% data reusables.dependabot.option-affects-security-updates %}
|
||||
|
||||
```yaml
|
||||
# Specify a milestone for pull requests
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Associate pull requests with milestone "4"
|
||||
milestone: 4
|
||||
```
|
||||
|
||||
#### `open-pull-requests-limit`
|
||||
|
||||
By default, {% data variables.product.prodname_dependabot %} opens a maximum of five pull requests for version updates. Once there are five open pull requests, new requests are blocked until you merge or close some of the open requests, after which new pull requests can be opened on subsequent updates. Use `open-pull-requests-limit` to change this limit. This also provides a simple way to temporarily disable version updates for a package manager.
|
||||
|
||||
This option has no impact on security updates, which have a separate, internal limit of ten open pull requests.
|
||||
|
||||
```yaml
|
||||
# Specify the number of open pull requests allowed
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Disable version updates for npm dependencies
|
||||
open-pull-requests-limit: 0
|
||||
|
||||
- package-ecosystem: "pip"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Allow up to 10 open pull requests for pip dependencies
|
||||
open-pull-requests-limit: 10
|
||||
```
|
||||
|
||||
#### `pull-request-branch-name.separator`
|
||||
|
||||
{% data variables.product.prodname_dependabot %} generates a branch for each pull request. Each branch name includes `dependabot`, and the package manager and dependency that are updated. By default, these parts are separated by a `/` symbol, for example: `dependabot/npm_and_yarn/next_js/acorn-6.4.1`.
|
||||
|
||||
Use `pull-request-branch-name.separator` to specify a different separator. This can be one of: `"-"`, `_` or `/`. The hyphen symbol must be quoted because otherwise it's interpreted as starting an empty YAML list.
|
||||
|
||||
{% data reusables.dependabot.option-affects-security-updates %}
|
||||
|
||||
```yaml
|
||||
# Specify a different separator for branch names
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
pull-request-branch-name:
|
||||
# Separate sections of the branch name with a hyphen
|
||||
# for example, `dependabot-npm_and_yarn-next_js-acorn-6.4.1`
|
||||
separator: "-"
|
||||
```
|
||||
|
||||
#### `rebase-strategy`
|
||||
|
||||
By default, {% data variables.product.prodname_dependabot %} automatically rebases open pull requests when it detects conflicts. Use `rebase-strategy` to disable this behavior.
|
||||
|
||||
Available rebase strategies
|
||||
|
||||
- `disabled` to disable automatic rebasing.
|
||||
- `auto` to use the default behavior and rebase open pull requests when conflicts are detected.
|
||||
|
||||
{% data reusables.dependabot.option-affects-security-updates %}
|
||||
|
||||
```yaml
|
||||
# Disable automatic rebasing
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Disable rebasing for npm pull requests
|
||||
rebase-strategy: "disabled"
|
||||
```
|
||||
|
||||
#### `registries`
|
||||
|
||||
To allow {% data variables.product.prodname_dependabot %} to access a private package registry when performing a version update, you must include a `registries` setting within the relevant `updates` configuration. You can allow all of the defined registries to be used by setting `registries` to `"*"`. Alternatively, you can list the registries that the update can use. To do this, use the name of the registry as defined in the top-level `registries` section of the _dependabot.yml_ file.
|
||||
|
||||
To allow {% data variables.product.prodname_dependabot %} to use `bundler`, `mix`, and `pip` package managers to update dependencies in private registries, you can choose to allow external code execution. For more information, see [`insecure-external-code-execution`](#insecure-external-code-execution).
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
# Allow {% data variables.product.prodname_dependabot %} to use one of the two defined private registries
|
||||
# when updating dependency versions for this ecosystem
|
||||
|
||||
version: 2
|
||||
registries:
|
||||
maven-github:
|
||||
type: maven-repository
|
||||
url: https://maven.pkg.github.com/octocat
|
||||
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
|
||||
npm-npmjs:
|
||||
type: npm-registry
|
||||
url: https://registry.npmjs.org
|
||||
username: octocat
|
||||
password: ${{secrets.MY_NPM_PASSWORD}}
|
||||
updates:
|
||||
- package-ecosystem: "gitsubmodule"
|
||||
directory: "/"
|
||||
registries:
|
||||
- maven-github
|
||||
schedule:
|
||||
interval: "monthly"
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### `reviewers`
|
||||
|
||||
Use `reviewers` to specify individual reviewers or teams of reviewers for all pull requests raised for a package manager. You must use the full team name, including the organization, as if you were @mentioning the team.
|
||||
|
||||
{% data reusables.dependabot.option-affects-security-updates %}
|
||||
|
||||
```yaml
|
||||
# Specify reviewers for pull requests
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "pip"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Add reviewers
|
||||
reviewers:
|
||||
- "octocat"
|
||||
- "my-username"
|
||||
- "my-org/python-team"
|
||||
```
|
||||
|
||||
#### `schedule.day`
|
||||
|
||||
When you set a `weekly` update schedule, by default, {% data variables.product.prodname_dependabot %} checks for new versions on Monday at 05:00 UTC. Use `schedule.day` to specify an alternative day to check for updates.
|
||||
|
||||
Supported values
|
||||
|
||||
- `monday`
|
||||
- `tuesday`
|
||||
- `wednesday`
|
||||
- `thursday`
|
||||
- `friday`
|
||||
- `saturday`
|
||||
- `sunday`
|
||||
|
||||
```yaml
|
||||
# Specify the day for weekly checks
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
# Check for npm updates on Sundays
|
||||
day: "sunday"
|
||||
```
|
||||
|
||||
#### `schedule.time`
|
||||
|
||||
By default, {% data variables.product.prodname_dependabot %} checks for new versions at 05:00 UTC. Use `schedule.time` to specify an alternative time of day to check for updates (format: `hh:mm`).
|
||||
|
||||
```yaml
|
||||
# Set a time for checks
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Check for npm updates at 9am UTC
|
||||
time: "09:00"
|
||||
```
|
||||
|
||||
#### `schedule.timezone`
|
||||
|
||||
By default, {% data variables.product.prodname_dependabot %} checks for new versions at 05:00 UTC. Use `schedule.timezone` to specify an alternative time zone. The time zone identifier must be from the Time Zone database maintained by [iana](https://www.iana.org/time-zones). For more information, see [List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).
|
||||
|
||||
```yaml
|
||||
# Specify the timezone for checks
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
time: "09:00"
|
||||
# Use Japan Standard Time (UTC +09:00)
|
||||
timezone: "Asia/Tokyo"
|
||||
```
|
||||
|
||||
#### `target-branch`
|
||||
|
||||
By default, {% data variables.product.prodname_dependabot %} checks for manifest files on the default branch and raises pull requests for version updates against this branch. Use `target-branch` to specify a different branch for manifest files and for pull requests. When you use this option, the settings for this package manager will no longer affect any pull requests raised for security updates.
|
||||
|
||||
```yaml
|
||||
# Specify a non-default branch for pull requests for pip
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "pip"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Raise pull requests for version updates
|
||||
# to pip against the `develop` branch
|
||||
target-branch: "develop"
|
||||
# Labels on pull requests for version updates only
|
||||
labels:
|
||||
- "pip dependencies"
|
||||
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
# Check for npm updates on Sundays
|
||||
day: "sunday"
|
||||
# Labels on pull requests for security and version updates
|
||||
labels:
|
||||
- "npm dependencies"
|
||||
```
|
||||
|
||||
#### `vendor`
|
||||
|
||||
Use the `vendor` option to tell {% data variables.product.prodname_dependabot %} to vendor dependencies when updating them. Don't use this option if you're using `gomod` as {% data variables.product.prodname_dependabot %} automatically detects vendoring for this tool.
|
||||
|
||||
```yaml
|
||||
# Configure version updates for both dependencies defined in manifests and vendored dependencies
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "bundler"
|
||||
# Raise pull requests to update vendored dependencies that are checked in to the repository
|
||||
vendor: true
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
```
|
||||
|
||||
{% data variables.product.prodname_dependabot %} only updates the vendored dependencies located in specific directories in a repository.
|
||||
|
||||
| Package manager | Required file path for vendored dependencies | More information |
|
||||
|------------------|-------------------------------|--------|
|
||||
| `bundler` | The dependencies must be in the _vendor/cache_ directory.</br>Other file paths are not supported. | [`bundle cache` documentation](https://bundler.io/man/bundle-cache.1.html) |
|
||||
| `gomod` | No path requirement (dependencies are usually located in the _vendor_ directory) | [`go mod vendor` documentation](https://golang.org/ref/mod#go-mod-vendor) |
|
||||
|
||||
|
||||
#### `versioning-strategy`
|
||||
|
||||
When {% data variables.product.prodname_dependabot %} edits a manifest file to update a version, it uses the following overall strategies:
|
||||
|
||||
- For apps, the version requirements are increased, for example: npm, pip and Composer.
|
||||
- For libraries, the range of versions is widened, for example: Bundler and Cargo.
|
||||
|
||||
Use the `versioning-strategy` option to change this behavior for supported package managers.
|
||||
|
||||
{% data reusables.dependabot.option-affects-security-updates %}
|
||||
|
||||
Available update strategies
|
||||
|
||||
| Option | Supported by | Action |
|
||||
|--------|--------------|--------|
|
||||
| `lockfile-only` | `bundler`, `cargo`, `composer`, `mix`, `npm`, `pip` | Only create pull requests to update lockfiles updates. Ignore any new versions that would require package manifest changes. |
|
||||
| `auto` | `bundler`, `cargo`, `composer`, `mix`, `npm`, `pip` | Follow the default strategy described above.|
|
||||
| `widen`| `composer`, `npm` | Relax the version requirement to include both the new and old version, when possible. |
|
||||
| `increase`| `bundler`, `composer`, `npm` | Always increase the version requirement to match the new version. |
|
||||
| `increase-if-necessary` | `bundler`, `composer`, `npm` | Increase the version requirement only when required by the new version. |
|
||||
|
||||
```yaml
|
||||
# Customize the manifest version strategy
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Update the npm manifest file to relax
|
||||
# the version requirements
|
||||
versioning-strategy: widen
|
||||
|
||||
- package-ecosystem: "composer"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Increase the version requirements for Composer
|
||||
# only when required
|
||||
versioning-strategy: increase-if-necessary
|
||||
|
||||
- package-ecosystem: "pip"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Only allow updates to the lockfile for pip and
|
||||
# ignore any version updates that affect the manifest
|
||||
versioning-strategy: lockfile-only
|
||||
```
|
||||
|
||||
### Configuration options for private registries
|
||||
|
||||
The top-level `registries` key is optional. It allows you to specify authentication details that {% data variables.product.prodname_dependabot %} can use to access private package registries.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Private registries behind firewalls on private networks are not supported.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
The value of the `registries` key is an associative array, each element of which consists of a key that identifies a particular registry and a value which is an associative array that specifies the settings required to access that registry. The following *dependabot.yml* file, configures a registry identified as `dockerhub` in the `registries` section of the file and then references this in the `updates` section of the file.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
# Minimal settings to update dependencies in one private registry
|
||||
|
||||
version: 2
|
||||
registries:
|
||||
dockerhub: # Define access for a private registry
|
||||
type: docker-registry
|
||||
url: registry.hub.docker.com
|
||||
username: octocat
|
||||
password: ${{secrets.DOCKERHUB_PASSWORD}}
|
||||
updates:
|
||||
- package-ecosystem: "docker"
|
||||
directory: "/docker-registry/dockerhub"
|
||||
registries:
|
||||
- dockerhub # Allow version updates for dependencies in this registry
|
||||
schedule:
|
||||
interval: "monthly"
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
You use the following options to specify access settings. Registry settings must contain a `type` and a `url`, and typically either a `username` and `password` combination or a `token`.
|
||||
|
||||
| Option | Description |
|
||||
|:---|:---|
|
||||
| `type` | Identifies the type of registry. See the full list of types below. |
|
||||
| `url` | The URL to use to access the dependencies in this registry. The protocol is optional. If not specified, `https://` is assumed. {% data variables.product.prodname_dependabot %} adds or ignores trailing slashes as required. |
|
||||
| `username` | The username that {% data variables.product.prodname_dependabot %} uses to access the registry. |
|
||||
| `password` | A reference to a {% data variables.product.prodname_dependabot %} secret containing the password for the specified user. For more information, see "[Managing encrypted secrets for Dependabot](/github/administering-a-repository/managing-encrypted-secrets-for-dependabot)." |
|
||||
| `token` | A reference to a {% data variables.product.prodname_dependabot %} secret containing an access token for this registry. For more information, see "[Managing encrypted secrets for Dependabot](/github/administering-a-repository/managing-encrypted-secrets-for-dependabot)." |
|
||||
| `replaces-base` | For registries with `type: python-index`, if the boolean value is `true`, pip resolves dependencies by using the specified URL rather than the base URL of the Python Package Index (by default `https://pypi.org/simple`). |
|
||||
|
||||
|
||||
Each configuration `type` requires you to provide particular settings. Some types allow more than one way to connect. The following sections provide details of the settings you should use for each `type`.
|
||||
|
||||
#### `composer-repository`
|
||||
|
||||
The `composer-repository` type supports username and password.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
registries:
|
||||
composer:
|
||||
type: composer-repository
|
||||
url: https://repo.packagist.com/example-company/
|
||||
username: octocat
|
||||
password: ${{secrets.MY_PACKAGIST_PASSWORD}}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### `docker-registry`
|
||||
|
||||
The `docker-registry` type supports username and password.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
registries:
|
||||
dockerhub:
|
||||
type: docker-registry
|
||||
url: https://registry.hub.docker.com
|
||||
username: octocat
|
||||
password: ${{secrets.MY_DOCKERHUB_PASSWORD}}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### `git`
|
||||
|
||||
The `git` type supports username and password.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
registries:
|
||||
github-octocat:
|
||||
type: git
|
||||
url: https://github.com
|
||||
username: x-access-token
|
||||
password: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### `maven-repository`
|
||||
|
||||
The `maven-repository` type supports username and password, or token.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
registries:
|
||||
maven-artifactory:
|
||||
type: maven-repository
|
||||
url: https://artifactory.example.com
|
||||
username: octocat
|
||||
password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
registries:
|
||||
maven-github:
|
||||
type: maven-repository
|
||||
url: https://maven.pkg.github.com/octocat
|
||||
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### `npm-registry`
|
||||
|
||||
The `npm-registry` type supports username and password, or token.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
registries:
|
||||
npm-npmjs:
|
||||
type: npm-registry
|
||||
url: https://registry.npmjs.org
|
||||
username: octocat
|
||||
password: ${{secrets.MY_NPM_PASSWORD}}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
registries:
|
||||
npm-github:
|
||||
type: npm-registry
|
||||
url: https://npm.pkg.github.com
|
||||
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### `nuget-feed`
|
||||
|
||||
The `nuget-feed` type supports username and password, or token.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
registries:
|
||||
nuget-example:
|
||||
type: nuget-feed
|
||||
url: https://nuget.example.com/v3/index.json
|
||||
username: octocat@example.com
|
||||
password: ${{secrets.MY_NUGET_PASSWORD}}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
registries:
|
||||
nuget-azure-devops:
|
||||
type: nuget-feed
|
||||
url: https://pkgs.dev.azure.com/.../_packaging/My_Feed/nuget/v3/index.json
|
||||
token: ${{secrets.MY_AZURE_DEVOPS_TOKEN}}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### `python-index`
|
||||
|
||||
The `python-index` type supports username and password, or token.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
registries:
|
||||
python-example:
|
||||
type: python-index
|
||||
url: https://example.com/_packaging/my-feed/pypi/example
|
||||
username: octocat
|
||||
password: ${{secrets.MY_BASIC_AUTH_PASSWORD}}
|
||||
replaces-base: true
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
registries:
|
||||
python-azure:
|
||||
type: python-index
|
||||
url: https://pkgs.dev.azure.com/octocat/_packaging/my-feed/pypi/example
|
||||
token: ${{secrets.MY_AZURE_DEVOPS_TOKEN}}
|
||||
replaces-base: true
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### `rubygems-server`
|
||||
|
||||
The `rubygems-server` type supports username and password, or token.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
registries:
|
||||
ruby-example:
|
||||
type: rubygems-server
|
||||
url: https://rubygems.example.com
|
||||
username: octocat@example.com
|
||||
password: ${{secrets.MY_RUBYGEMS_PASSWORD}}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
registries:
|
||||
ruby-github:
|
||||
type: rubygems-server
|
||||
url: https://rubygems.pkg.github.com/octocat/github_api
|
||||
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
|
||||
```
|
||||
{% endraw %}
|
||||
@@ -1,77 +0,0 @@
|
||||
---
|
||||
title: Configuring secret scanning for your repositories
|
||||
intro: 'You can configure how {% data variables.product.prodname_dotcom %} scans your repositories for secrets.'
|
||||
permissions: 'People with admin permissions to a repository can enable {% data variables.product.prodname_secret_scanning %} for the repository.'
|
||||
redirect_from:
|
||||
- /github/administering-a-repository/configuring-secret-scanning-for-private-repositories
|
||||
product: '{% data reusables.gated-features.secret-scanning %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=3.0'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
{% data reusables.secret-scanning.beta %}
|
||||
{% data reusables.secret-scanning.enterprise-enable-secret-scanning %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
{% note %}
|
||||
|
||||
**Note:** {% data variables.product.prodname_secret_scanning_caps %} is enabled by default on public repositories and cannot be turned off. You can configure {% data variables.product.prodname_secret_scanning %} for your private repositories only.
|
||||
|
||||
{% endnote %}
|
||||
{% endif %}
|
||||
|
||||
### Enabling {% data variables.product.prodname_secret_scanning %} for {% if currentVersion == "free-pro-team@latest" %}private {% endif %}repositories
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.navigate-to-security-and-analysis %}
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
|
||||
4. You may need to enable {% data variables.product.prodname_GH_advanced_security %} to activate the button for "{% data variables.product.prodname_secret_scanning_caps %}". To the right of "{% data variables.product.prodname_GH_advanced_security %}", click **Enable**.
|
||||
|
||||
5. Click **Enable {% data variables.product.prodname_GH_advanced_security %} for this repository** to confirm the action.
|
||||
|
||||
6. When you enable {% data variables.product.prodname_GH_advanced_security %} this may automatically enable {% data variables.product.prodname_secret_scanning %} for the repository (this is controlled by the organization configuration). If "{% data variables.product.prodname_secret_scanning_caps %}" is shown with an **Enable** button, you still need to enable {% data variables.product.prodname_secret_scanning %} by clicking **Enable**. If you see a **Disable** button, {% data variables.product.prodname_secret_scanning %} is already enabled.
|
||||
|
||||
{% elsif currentVersion == "enterprise-server@3.0" %}
|
||||
7. To the right of "{% data variables.product.prodname_secret_scanning_caps %}", click **Enable**.
|
||||
|
||||
{% endif %}
|
||||
{% if currentVersion == "github-ae@latest" %}
|
||||
1. Before you can enable {% data variables.product.prodname_secret_scanning %}, you need to enable {% data variables.product.prodname_GH_advanced_security %} first. To the right of "{% data variables.product.prodname_GH_advanced_security %}", click **Enable**.
|
||||
|
||||
2. Click **Enable {% data variables.product.prodname_GH_advanced_security %} for this repository** to confirm the action.
|
||||
|
||||
3. To the right of "{% data variables.product.prodname_secret_scanning_caps %}", click **Enable**.
|
||||
|
||||
{% endif %}
|
||||
|
||||
### Excluding alerts from {% data variables.product.prodname_secret_scanning %} in {% if currentVersion == "free-pro-team@latest" %}private {% endif %}repositories
|
||||
|
||||
You can use a *secret_scanning.yml* file to exclude directories from {% data variables.product.prodname_secret_scanning %}. For example, you can exclude directories that contain tests or randomly generated content.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.files.add-file %}
|
||||
3. In the file name field, type *.github/secret_scanning.yml*.
|
||||
4. Under **Edit new file**, type `paths-ignore:` followed by the paths you want to exclude from {% data variables.product.prodname_secret_scanning %}.
|
||||
``` yaml
|
||||
paths-ignore:
|
||||
- "foo/bar/*.js"
|
||||
```
|
||||
|
||||
You can use special characters, such as `*` to filter paths. For more information about filter patterns, see "[Workflow syntax for GitHub Actions](/actions/reference/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet)."
|
||||
|
||||
{% note %}
|
||||
|
||||
**Notes:**
|
||||
- If there are more than 1,000 entries in `paths-ignore`, {% data variables.product.prodname_secret_scanning %} will only exclude the first 1,000 directories from scans.
|
||||
- If *secret_scanning.yml* is larger than 1 MB, {% data variables.product.prodname_secret_scanning %} will ignore the entire file.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
You can also ignore individual alerts from {% data variables.product.prodname_secret_scanning %}. For more information, see "[Managing alerts from {% data variables.product.prodname_secret_scanning %}](/github/administering-a-repository/managing-alerts-from-secret-scanning#managing-alerts)."
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[Managing security and analysis settings for your organization](/github/setting-up-and-managing-organizations-and-teams/managing-security-and-analysis-settings-for-your-organization)"
|
||||
@@ -1,127 +0,0 @@
|
||||
---
|
||||
title: Customizing dependency updates
|
||||
intro: 'You can customize how {% data variables.product.prodname_dependabot %} maintains your dependencies.'
|
||||
permissions: 'People with write permissions to a repository can configure {% data variables.product.prodname_dependabot %} for the repository.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
{% data reusables.dependabot.beta-note %}
|
||||
|
||||
### About customizing dependency updates
|
||||
|
||||
After you've enabled version updates, you can customize how {% data variables.product.prodname_dependabot %} maintains your dependencies by adding further options to the *dependabot.yml* file. For example, you could:
|
||||
|
||||
- Specify which day of the week to open pull requests for version updates: `schedule.day`
|
||||
- Set reviewers, assignees, and labels for each package manager: `reviewers`, `assignees`, and `labels`
|
||||
- Define a versioning strategy for changes to each manifest file: `versioning-strategy`
|
||||
- Change the maximum number of open pull requests for version updates from the default of 5: `open-pull-requests-limit`
|
||||
- Open pull requests for version updates to target a specific branch, instead of the default branch: `target-branch`
|
||||
|
||||
For more information about the configuration options, see "[Configuration options for dependency updates](/github/administering-a-repository/configuration-options-for-dependency-updates)."
|
||||
|
||||
When you update the *dependabot.yml* file in your repository, {% data variables.product.prodname_dependabot %} runs an immediate check with the new configuration. Within minutes you will see an updated list of dependencies on the **{% data variables.product.prodname_dependabot %}** tab, this may take longer if the repository has many dependencies. You may also see new pull requests for version updates. For more information, see "[Listing dependencies configured for version updates](/github/administering-a-repository/listing-dependencies-configured-for-version-updates)."
|
||||
|
||||
### Impact of configuration changes on security updates
|
||||
|
||||
If you customize the *dependabot.yml* file, you may notice some changes to the pull requests raised for security updates. These pull requests are always triggered by a security advisory for a dependency, rather than by the {% data variables.product.prodname_dependabot %} schedule. However, they inherit relevant configuration settings from the *dependabot.yml* file unless you specify a different target branch for version updates.
|
||||
|
||||
For an example, see "[Setting custom labels](#setting-custom-labels)" below.
|
||||
|
||||
### Modifying scheduling
|
||||
|
||||
When you set a `daily` update schedule, by default, {% data variables.product.prodname_dependabot %} checks for new versions at 05:00 UTC. You can use `schedule.time` to specify an alternative time of day to check for updates (format: `hh:mm`).
|
||||
|
||||
The example *dependabot.yml* file below expands the npm configuration to specify when {% data variables.product.prodname_dependabot %} should check for version updates to dependencies.
|
||||
|
||||
```yaml
|
||||
# dependabot.yml file with
|
||||
# customized schedule for version updates
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
# Keep npm dependencies up to date
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
# Check the npm registry for updates at 2am UTC
|
||||
schedule:
|
||||
interval: "daily"
|
||||
time: "02:00"
|
||||
```
|
||||
|
||||
### Setting reviewers and assignees
|
||||
|
||||
By default, {% data variables.product.prodname_dependabot %} raises pull requests without any reviewers or assignees.
|
||||
|
||||
You can use `reviewers` and `assignees` to specify reviewers and assignees for all pull requests raised for a package manager. When you specify a team, you must use the full team name, as if you were @mentioning the team (including the organization).
|
||||
|
||||
The example *dependabot.yml* file below changes the npm configuration so that all pull requests opened with version and security updates for npm will have two reviewers and one assignee.
|
||||
|
||||
```yaml
|
||||
# dependabot.yml file with
|
||||
# reviews and an assignee for all npm pull requests
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
# Keep npm dependencies up to date
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Raise all npm pull requests with reviewers
|
||||
reviewers:
|
||||
- "my-org/team-name"
|
||||
- "octocat"
|
||||
# Raise all npm pull requests with an assignee
|
||||
assignees:
|
||||
- "user-name"
|
||||
```
|
||||
|
||||
### Setting custom labels
|
||||
|
||||
{% data reusables.dependabot.default-labels %}
|
||||
|
||||
You can use `labels` to override the default labels and specify alternative labels for all pull requests raised for a package manager. You can't create new labels in the *dependabot.yml* file, so the alternative labels must already exist in the repository.
|
||||
|
||||
The example *dependabot.yml* file below changes the npm configuration so that all pull requests opened with version and security updates for npm will have custom labels. It also changes the Docker configuration to check for version updates against a custom branch and to raise pull requests with custom labels against that custom branch. The changes to Docker will not affect security update pull requests because security updates are always made against the default branch.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** The new `target-branch` must contain a Dockerfile to update, otherwise this change will have the effect of disabling version updates for Docker.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
```yaml
|
||||
# dependabot.yml file with
|
||||
# customized npm configuration
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
# Keep npm dependencies up to date
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Raise all npm pull requests with custom labels
|
||||
labels:
|
||||
- "npm dependencies"
|
||||
- "triage-board"
|
||||
|
||||
# Keep Docker dependencies up to date
|
||||
- package-ecosystem: "docker"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Raise pull requests for Docker version updates
|
||||
# against the "develop" branch. The Docker configuration
|
||||
# no longer affects security update pull requests.
|
||||
target-branch: "develop"
|
||||
# Use custom labels on pull requests for Docker version updates
|
||||
labels:
|
||||
- "Docker dependencies"
|
||||
- "triage-board"
|
||||
```
|
||||
|
||||
### More examples
|
||||
|
||||
For more examples, see "[Configuration options for dependency updates](/github/administering-a-repository/configuration-options-for-dependency-updates)."
|
||||
@@ -1,125 +0,0 @@
|
||||
---
|
||||
title: Enabling and disabling version updates
|
||||
intro: 'You can configure your repository so that {% data variables.product.prodname_dependabot %} automatically updates the packages you use.'
|
||||
permissions: 'People with write permissions to a repository can enable or disable {% data variables.product.prodname_dependabot_version_updates %} for the repository.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
{% data reusables.dependabot.beta-note-no-link %}
|
||||
|
||||
### About version updates for dependencies
|
||||
|
||||
You enable {% data variables.product.prodname_dependabot_version_updates %} by checking a *dependabot.yml* configuration file in to your repository's `.github` directory. {% data variables.product.prodname_dependabot %} then raises pull requests to keep the dependencies you configure up-to-date. For each package manager's dependencies that you want to update, you must specify the location of the package manifest files and how often to check for updates to the dependencies listed in those files. For information about enabling security updates, see "[Configuring {% data variables.product.prodname_dependabot_security_updates %}](/github/managing-security-vulnerabilities/configuring-dependabot-security-updates)."
|
||||
|
||||
{% data reusables.dependabot.initial-updates %} For more information, see "[Customizing dependency updates](/github/administering-a-repository/customizing-dependency-updates)."
|
||||
|
||||
{% data reusables.dependabot.private-dependencies-note %} Additionally, {% data variables.product.prodname_dependabot %} doesn't support private {% data variables.product.prodname_dotcom %} dependencies for all package managers. For more information, see "[About Dependabot version updates](/github/administering-a-repository/about-dependabot-version-updates#supported-repositories-and-ecosystems)."
|
||||
|
||||
### Enabling {% data variables.product.prodname_dependabot_version_updates %}
|
||||
|
||||
{% data reusables.dependabot.create-dependabot-yml %} For information, see "[Configuration options for dependency updates](/github/administering-a-repository/configuration-options-for-dependency-updates)."
|
||||
1. Add a `version`.
|
||||
1. Optionally, if you have dependencies in a private registry, add a `registries` section containing authentication details.
|
||||
1. Add an `updates` section, with an entry for each package manager you want {% data variables.product.prodname_dependabot %} to monitor.
|
||||
1. For each package manager, use:
|
||||
- `package-ecosystem` to specify the package manager.
|
||||
- `directory` to specify the location of the manifest or other definition files.
|
||||
- `schedule.interval` to specify how often to check for new versions.
|
||||
{% data reusables.dependabot.check-in-dependabot-yml %}
|
||||
|
||||
#### Example *dependabot.yml* file
|
||||
|
||||
The example *dependabot.yml* file below configures version updates for two package managers: npm and Docker. When this file is checked in, {% data variables.product.prodname_dependabot %} checks the manifest files on the default branch for outdated dependencies. If it finds outdated dependencies, it will raise pull requests against the default branch to update the dependencies.
|
||||
|
||||
```yaml
|
||||
# Basic dependabot.yml file with
|
||||
# minimum configuration for two package managers
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
# Enable version updates for npm
|
||||
- package-ecosystem: "npm"
|
||||
# Look for `package.json` and `lock` files in the `root` directory
|
||||
directory: "/"
|
||||
# Check the npm registry for updates every day (weekdays)
|
||||
schedule:
|
||||
interval: "daily"
|
||||
|
||||
# Enable version updates for Docker
|
||||
- package-ecosystem: "docker"
|
||||
# Look for a `Dockerfile` in the `root` directory
|
||||
directory: "/"
|
||||
# Check for updates once a week
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
```
|
||||
|
||||
In the example above, if the Docker dependencies were very outdated, you might want to start with a `daily` schedule until the dependencies are up-to-date, and then drop back to a weekly schedule.
|
||||
|
||||
#### Enabling version updates on forks
|
||||
|
||||
If you want to enable version updates on forks, there's an extra step. Version updates are not automatically enabled on forks when a *dependabot.yml* configuration file is present. This ensures that fork owners don't unintentionally enable version updates when they pull changes including a *dependabot.yml* configuration file from the original repository.
|
||||
|
||||
On a fork, you also need to explicitly enable {% data variables.product.prodname_dependabot %}.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.accessing-repository-graphs %}
|
||||
{% data reusables.repositories.click-dependency-graph %}
|
||||
{% data reusables.dependabot.click-dependabot-tab %}
|
||||
5. Under "Enable Dependabot", click **Enable Dependabot**.
|
||||
|
||||
### Checking the status of version updates
|
||||
|
||||
After you enable version updates, you'll see a new **Dependabot** tab in the dependency graph for the repository. This tab shows which package managers {% data variables.product.prodname_dependabot %} is configured to monitor and when {% data variables.product.prodname_dependabot %} last checked for new versions.
|
||||
|
||||
|
||||
|
||||
For information, see "[Listing dependencies configured for version updates](/github/administering-a-repository/listing-dependencies-configured-for-version-updates)."
|
||||
|
||||
### Disabling {% data variables.product.prodname_dependabot_version_updates %}
|
||||
|
||||
You can disable version updates entirely by deleting the *dependabot.yml* file from your repository. More usually, you want to disable updates temporarily for one or more dependencies, or package managers.
|
||||
|
||||
- Package managers: disable by setting `open-pull-requests-limit: 0` or by commenting out the relevant `package-ecosystem` in the configuration file.
|
||||
- Specific dependencies: disable by adding `ignore` attributes for packages or applications that you want to exclude from updates.
|
||||
|
||||
When you disable dependencies, you can use wild cards to match a set of related libraries. You can also specify which versions to exclude. This is particularly useful if you need to block updates to a library, pending work to support a breaking change to its API, but want to get any security fixes to the version you use.
|
||||
|
||||
#### Example disabling version updates for some dependencies
|
||||
|
||||
The example *dependabot.yml* file below includes examples of the different ways to disable updates to some dependencies, while allowing other updates to continue.
|
||||
|
||||
```yaml
|
||||
# dependabot.yml file with updates
|
||||
# disabled for Docker and limited for npm
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
# Configuration for Dockerfile
|
||||
- package-ecosystem: "docker"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
# Disable all pull requests for Docker dependencies
|
||||
open-pull-requests-limit: 0
|
||||
|
||||
# Configuration for npm
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
# Overwrite any ignores created using `@dependabot ignore` commands
|
||||
ignore:
|
||||
# Ignore updates to packages that start 'aws'
|
||||
# Wildcards match zero or more arbitrary characters
|
||||
- dependency-name: "aws*"
|
||||
# Ignore some updates to the 'express' package
|
||||
- dependency-name: "express"
|
||||
# Ignore only new versions for 4.x and 5.x
|
||||
versions: ["4.x", "5.x"]
|
||||
```
|
||||
|
||||
{% data reusables.dependabot.warning-ignore-option %}
|
||||
|
||||
For more information about checking for existing ignore preferences, see "[Configuration options for dependency updates](/github/administering-a-repository/configuration-options-for-dependency-updates#ignore)."
|
||||
@@ -25,6 +25,7 @@ versions:
|
||||
{% link_in_list /disabling-or-limiting-github-actions-for-a-repository %}{% if currentVersion == "free-pro-team@latest" %}
|
||||
{% link_in_list /enabling-or-disabling-github-discussions-for-a-repository %}{% endif %}
|
||||
{% link_in_list /managing-git-lfs-objects-in-archives-of-your-repository %}
|
||||
{% link_in_list /managing-security-and-analysis-settings-for-your-repository %}
|
||||
{% link_in_list /enabling-anonymous-git-read-access-for-a-repository %}
|
||||
{% link_in_list /configuring-autolinks-to-reference-external-resources %}
|
||||
{% link_in_list /renaming-a-repository %}
|
||||
@@ -53,18 +54,3 @@ versions:
|
||||
{% link_in_list /linking-to-releases %}
|
||||
{% link_in_list /comparing-releases %}
|
||||
{% link_in_list /automation-for-release-forms-with-query-parameters %}
|
||||
{% topic_link_in_list /securing-your-repository %}
|
||||
{% link_in_list /about-securing-your-repository %}
|
||||
{% link_in_list /about-secret-scanning %}
|
||||
{% link_in_list /configuring-secret-scanning-for-your-repositories %}
|
||||
{% link_in_list /managing-alerts-from-secret-scanning %}
|
||||
{% link_in_list /managing-security-and-analysis-settings-for-your-repository %}
|
||||
{% topic_link_in_list /keeping-your-dependencies-updated-automatically %}
|
||||
{% link_in_list /about-dependabot-version-updates %}
|
||||
{% link_in_list /enabling-and-disabling-version-updates %}
|
||||
{% link_in_list /listing-dependencies-configured-for-version-updates %}
|
||||
{% link_in_list /managing-pull-requests-for-dependency-updates %}
|
||||
{% link_in_list /managing-encrypted-secrets-for-dependabot %}
|
||||
{% link_in_list /customizing-dependency-updates %}
|
||||
{% link_in_list /configuration-options-for-dependency-updates %}
|
||||
{% link_in_list /keeping-your-actions-up-to-date-with-dependabot %}
|
||||
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
title: Keeping your actions up to date with Dependabot
|
||||
intro: 'You can use {% data variables.product.prodname_dependabot %} to keep the actions you use updated to the latest versions.'
|
||||
redirect_from:
|
||||
- /github/administering-a-repository/keeping-your-actions-up-to-date-with-github-dependabot
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
{% data reusables.dependabot.beta-note %}
|
||||
|
||||
### About {% data variables.product.prodname_dependabot_version_updates %} for actions
|
||||
|
||||
Actions are often updated with bug fixes and new features to make automated processes more reliable, faster, and safer. When you enable {% data variables.product.prodname_dependabot_version_updates %} for {% data variables.product.prodname_actions %}, {% data variables.product.prodname_dependabot %} will help ensure that references to actions in a repository's *workflow.yml* file are kept up to date. For each action in the file, {% data variables.product.prodname_dependabot %} checks the action's reference (typically a version number or commit identifier associated with the action) against the latest version. If a more recent version of the action is available, {% data variables.product.prodname_dependabot %} will send you a pull request that updates the reference in the workflow file to the latest version. For more information about {% data variables.product.prodname_dependabot_version_updates %}, see "[About {% data variables.product.prodname_dependabot_version_updates %}](/github/administering-a-repository/about-dependabot-version-updates)." For more information about configuring workflows for {% data variables.product.prodname_actions %}, see "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."
|
||||
|
||||
{% data reusables.actions.workflow-runs-dependabot-note %}
|
||||
|
||||
### Enabling {% data variables.product.prodname_dependabot_version_updates %} for actions
|
||||
|
||||
{% data reusables.dependabot.create-dependabot-yml %} If you have already enabled {% data variables.product.prodname_dependabot_version_updates %} for other ecosystems or package managers, simply open the existing *dependabot.yml* file.
|
||||
1. Specify `"github-actions"` as a `package-ecosystem` to monitor.
|
||||
1. Set the `directory` to `"/"` to check for workflow files in `.github/workflows`.
|
||||
1. Set a `schedule.interval` to specify how often to check for new versions.
|
||||
{% data reusables.dependabot.check-in-dependabot-yml %} If you have edited an existing file, save your changes.
|
||||
|
||||
You can also enable {% data variables.product.prodname_dependabot_version_updates %} on forks. For more information, see "[Enabling and disabling version updates](/github/administering-a-repository/enabling-and-disabling-version-updates#enabling-version-updates-on-forks)."
|
||||
|
||||
#### Example *dependabot.yml* file for {% data variables.product.prodname_actions %}
|
||||
|
||||
The example *dependabot.yml* file below configures version updates for {% data variables.product.prodname_actions %}. The `directory` must be set to `"/"` to check for workflow files in `.github/workflows`. The `schedule.interval` is set to `"daily"`. After this file has been checked in or updated, {% data variables.product.prodname_dependabot %} checks for new versions of your actions. {% data variables.product.prodname_dependabot %} will raise pull requests for version updates for any outdated actions that it finds. After the initial version updates, {% data variables.product.prodname_dependabot %} will continue to check for outdated versions of actions once a day.
|
||||
|
||||
```yaml
|
||||
# Set update schedule for GitHub Actions
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
|
||||
- package-ecosystem: "github-actions"
|
||||
directory: "/"
|
||||
schedule:
|
||||
# Check for updates to GitHub Actions every weekday
|
||||
interval: "daily"
|
||||
```
|
||||
|
||||
### Configuring {% data variables.product.prodname_dependabot_version_updates %} for actions
|
||||
|
||||
When enabling {% data variables.product.prodname_dependabot_version_updates %} for actions, you must specify values for `package-ecosystem`, `directory`, and `schedule.interval`. There are many more optional properties that you can set to further customize your version updates. For more information, see "[Configuration options for dependency updates](/github/administering-a-repository/configuration-options-for-dependency-updates)."
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[About GitHub Actions](/actions/getting-started-with-github-actions/about-github-actions)"
|
||||
@@ -1,8 +0,0 @@
|
||||
---
|
||||
title: Keeping your dependencies updated automatically
|
||||
intro: '{% data variables.product.prodname_dependabot %} can maintain your repository''s dependencies automatically.'
|
||||
mapTopic: true
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: Listing dependencies configured for version updates
|
||||
intro: 'You can view the dependencies that {% data variables.product.prodname_dependabot %} monitors for updates.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
{% data reusables.dependabot.beta-note %}
|
||||
|
||||
### Viewing dependencies monitored by {% data variables.product.prodname_dependabot %}
|
||||
|
||||
After you've enabled version updates, you can confirm that your configuration is correct using the **{% data variables.product.prodname_dependabot %}** tab in the dependency graph for the repository. For more information, see "[Enabling and disabling version updates](/github/administering-a-repository/enabling-and-disabling-version-updates)."
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.accessing-repository-graphs %}
|
||||
{% data reusables.repositories.click-dependency-graph %}
|
||||
{% data reusables.dependabot.click-dependabot-tab %}
|
||||
5. Optionally, to view the files monitored for a package manager, click the associated {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %}.
|
||||
|
||||
|
||||
If any dependencies are missing, check the log files for errors. If any package managers are missing, review the configuration file.
|
||||
|
||||
### Viewing {% data variables.product.prodname_dependabot %} log files
|
||||
|
||||
1. On the **{% data variables.product.prodname_dependabot %}** tab, click **Last checked *TIME* ago** to see the log file that {% data variables.product.prodname_dependabot %} generated during the last check for version updates.
|
||||
|
||||
2. Optionally, to rerun the version check, click **Check for updates**.
|
||||
|
||||
@@ -1,47 +0,0 @@
|
||||
---
|
||||
title: Managing alerts from secret scanning
|
||||
intro: You can view and close alerts for secrets checked in to your repository.
|
||||
product: '{% data reusables.gated-features.secret-scanning %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=3.0'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
{% data reusables.secret-scanning.beta %}
|
||||
|
||||
### Managing alerts
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
3. In the left sidebar, click **Secret scanning alerts**.
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
|
||||
{% endif %}
|
||||
{% if currentVersion == "github-ae@latest" %}
|
||||
|
||||
{% endif %}
|
||||
4. Under "Secret scanning" click the alert you want to view.
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
|
||||
{% endif %}
|
||||
{% if currentVersion ver_gt "enterprise-server@2.22" %}
|
||||
|
||||
{% endif %}
|
||||
{% if currentVersion == "github-ae@latest" %}
|
||||
|
||||
{% endif %}
|
||||
5. Optionally, use the "Mark as" drop-down menu and click a reason for resolving an alert.
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
|
||||
{% endif %}
|
||||
{% if currentVersion ver_gt "enterprise-server@2.22" or currentVersion == "github-ae@latest" %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
### Securing compromised secrets
|
||||
|
||||
Once a secret has been committed to a repository, you should consider the secret compromised. {% data variables.product.prodname_dotcom %} recommends the following actions for compromised secrets:
|
||||
|
||||
- For a compromised {% data variables.product.prodname_dotcom %} personal access token, delete the compromised token, create a new token, and update any services that use the old token. For more information, see "[Creating a personal access token for the command line](/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line)."
|
||||
- For all other secrets, first verify that the secret committed to {% data variables.product.product_name %} is valid. If so, create a new secret, update any services that use the old secret, and then delete the old secret.
|
||||
@@ -1,72 +0,0 @@
|
||||
---
|
||||
title: Managing encrypted secrets for Dependabot
|
||||
intro: You can store sensitive information, like passwords and access tokens, as encrypted secrets and then reference these in the {% data variables.product.prodname_dependabot %} configuration file.
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
### About encrypted secrets for {% data variables.product.prodname_dependabot %}
|
||||
|
||||
{% data variables.product.prodname_dependabot %} secrets are encrypted credentials that you create at either the organization level or the repository level.
|
||||
When you add a secret at the organization level, you can specify which repositories can access the secret. You can use secrets to allow {% data variables.product.prodname_dependabot %} to update dependencies located in private package registries. When you add a secret it's encrypted before it reaches {% data variables.product.prodname_dotcom %} and it remains encrypted until it's used by {% data variables.product.prodname_dependabot %} to access a private package registry.
|
||||
|
||||
After you add a {% data variables.product.prodname_dependabot %} secret, you can reference it in the _dependabot.yml_ configuration file like this: {% raw %}`${{secrets.NAME}}`{% endraw %}, where "NAME" is the name you chose for the secret. For example:
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
For more information, see "[Configuration options for dependency updates](/github/administering-a-repository/configuration-options-for-dependency-updates#configuration-options-for-private-registries)."
|
||||
|
||||
#### Naming your secrets
|
||||
|
||||
The name of a {% data variables.product.prodname_dependabot %} secret:
|
||||
* Can only contain alphanumeric characters (`[A-Z]`, `[0-9]`) or underscores (`_`). Spaces are not allowed. If you enter lowercase letters these are changed to uppercase.
|
||||
* Must not start with the `GITHUB_` prefix.
|
||||
* Must not start with a number.
|
||||
|
||||
### Adding a repository secret for {% data variables.product.prodname_dependabot %}
|
||||
|
||||
{% data reusables.github-actions.permissions-statement-secrets-repository %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.github-actions.sidebar-secret %}
|
||||
{% data reusables.dependabot.dependabot-secrets-button %}
|
||||
1. Click **New repository secret**.
|
||||
1. Type a name for your secret in the **Name** input box.
|
||||
1. Enter the value for your secret.
|
||||
1. Click **Add secret**.
|
||||
|
||||
The name of the secret is listed on the Dependabot secrets page. You can click **Update** to change the secret value. You can click **Remove** to delete the secret.
|
||||
|
||||
|
||||
|
||||
### Adding an organization secret for {% data variables.product.prodname_dependabot %}
|
||||
|
||||
When creating a secret in an organization, you can use a policy to limit which repositories can access that secret. For example, you can grant access to all repositories, or limit access to only private repositories or a specified list of repositories.
|
||||
|
||||
{% data reusables.github-actions.permissions-statement-secrets-organization %}
|
||||
|
||||
{% data reusables.organizations.navigate-to-org %}
|
||||
{% data reusables.organizations.org_settings %}
|
||||
{% data reusables.github-actions.sidebar-secret %}
|
||||
{% data reusables.dependabot.dependabot-secrets-button %}
|
||||
1. Click **New organization secret**.
|
||||
1. Type a name for your secret in the **Name** input box.
|
||||
1. Enter the **Value** for your secret.
|
||||
1. From the **Repository access** dropdown list, choose an access policy.
|
||||
1. If you chose **Selected repositories**:
|
||||
|
||||
* Click {% octicon "gear" aria-label="The Gear icon" %}.
|
||||
* Choose the repositories that can access this secret.
|
||||
|
||||
* Click **Update selection**.
|
||||
|
||||
1. Click **Add secret**.
|
||||
|
||||
The name of the secret is listed on the Dependabot secrets page. You can click **Update** to change the secret value or its access policy. You can click **Remove** to delete the secret.
|
||||
|
||||
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
title: Managing pull requests for dependency updates
|
||||
intro: 'You manage pull requests raised by {% data variables.product.prodname_dependabot %} in much the same way as other pull requests, but there are some extra options.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
{% data reusables.dependabot.beta-note %}
|
||||
|
||||
### About {% data variables.product.prodname_dependabot %} pull requests
|
||||
|
||||
{% data reusables.dependabot.pull-request-introduction %}
|
||||
|
||||
When {% data variables.product.prodname_dependabot %} raises a pull request, you're notified by your chosen method for the repository. Each pull request contains detailed information about the proposed change, taken from the package manager. These pull requests follow the normal checks and tests defined in your repository. In addition, where enough information is available, you'll see a compatibility score. This may also help you decide whether or not to merge the change. For information about this score, see "[About {% data variables.product.prodname_dependabot_security_updates %}](/github/managing-security-vulnerabilities/about-dependabot-security-updates)."
|
||||
|
||||
If you have many dependencies to manage, you may want to customize the configuration for each package manager so that pull requests have specific reviewers, assignees, and labels. For more information, see "[Customizing dependency updates](/github/administering-a-repository/customizing-dependency-updates)."
|
||||
|
||||
### Viewing {% data variables.product.prodname_dependabot %} pull requests
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
1. Any pull requests for security and version updates are easy to identify.
|
||||
- The author is [dependabot](https://github.com/dependabot), the bot account used by {% data variables.product.prodname_dependabot %}.
|
||||
- By default, they have the `dependencies` label.
|
||||
|
||||
### Changing the rebase strategy for {% data variables.product.prodname_dependabot %} pull requests
|
||||
|
||||
By default, {% data variables.product.prodname_dependabot %} automatically rebases pull requests to resolve any conflicts. If you'd prefer to handle merge conflicts manually, you can disable this using the `rebase-strategy` option. For details, see "[Configuration options for dependency updates](/github/administering-a-repository/configuration-options-for-dependency-updates#rebase-strategy)."
|
||||
|
||||
### Managing {% data variables.product.prodname_dependabot %} pull requests with comment commands
|
||||
|
||||
{% data variables.product.prodname_dependabot %} responds to simple commands in comments. Each pull request contains details of the commands you can use to process the pull request, for example: to merge, squash, reopen, close, or rebase the pull request. The aim is to make it as easy as possible for you to triage these automatically generated pull requests.
|
||||
|
||||
If you run any of the commands for ignoring dependencies or versions, {% data variables.product.prodname_dependabot %} stores the preferences for the repository centrally. While this is a quick solution, for repositories with more than one contributor it is better to explicitly define the dependencies and versions to ignore in the configuration file. This makes it easy for all contributors to see why a particular dependency isn't being updated automatically. For more information, see "[Configuration options for dependency updates](/github/administering-a-repository/configuration-options-for-dependency-updates#ignore)."
|
||||
@@ -4,6 +4,7 @@ intro: 'If a pull request contains changes to dependencies, you can view a summa
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
<!--Marketing-LINK: From /features/security/software-supply-chain page "Sign up for the dependency review beta" and "Reviewing dependency changes in a pull request".-->
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -5,9 +5,7 @@ product: '{% data reusables.gated-features.code-scanning %}'
|
||||
redirect_from:
|
||||
- /github/managing-security-vulnerabilities/about-automated-code-scanning
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
|
||||
{% data reusables.code-scanning.beta %}
|
||||
|
||||
@@ -4,9 +4,7 @@ shortTitle: About integration
|
||||
intro: 'You can perform {% data variables.product.prodname_code_scanning %} externally and then display the results in {% data variables.product.prodname_dotcom %}, or set up webhooks that listen to {% data variables.product.prodname_code_scanning %} activity in your repository.'
|
||||
product: '{% data reusables.gated-features.code-scanning %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
|
||||
{% data reusables.code-scanning.beta %}
|
||||
|
||||
@@ -5,8 +5,6 @@ intro: 'You can find vulnerabilities and errors in your project''s code on {% da
|
||||
mapTopic: true
|
||||
product: '{% data reusables.gated-features.code-scanning %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
|
||||
|
||||
@@ -5,9 +5,7 @@ product: '{% data reusables.gated-features.code-scanning %}'
|
||||
permissions: 'People with write permissions to a repository can configure {% data variables.product.prodname_code_scanning %} for the repository.'
|
||||
miniTocMaxHeadingLevel: 4
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
|
||||
{% data reusables.code-scanning.beta %}
|
||||
|
||||
@@ -7,9 +7,7 @@ miniTocMaxHeadingLevel: 4
|
||||
redirect_from:
|
||||
- /github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning-in-your-ci-system
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
|
||||
{% data reusables.code-scanning.beta-codeql-runner %}
|
||||
|
||||
@@ -8,9 +8,7 @@ redirect_from:
|
||||
- /github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning-for-compiled-languages
|
||||
- /github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-the-codeql-action-for-compiled-languages
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
|
||||
{% data reusables.code-scanning.beta %}
|
||||
|
||||
@@ -5,9 +5,7 @@ product: '{% data reusables.gated-features.code-scanning %}'
|
||||
redirect_from:
|
||||
- /github/managing-security-vulnerabilities/finding-security-vulnerabilities-in-your-projects-code
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
|
||||
### Table of Contents
|
||||
|
||||
@@ -7,8 +7,6 @@ product: '{% data reusables.gated-features.code-scanning %}'
|
||||
redirect_from:
|
||||
- /github/finding-security-vulnerabilities-and-errors-in-your-code/managing-results-from-code-scanning
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
|
||||
|
||||
@@ -5,9 +5,7 @@ intro: 'From the security view, you can view, fix, {% if currentVersion == "ente
|
||||
product: '{% data reusables.gated-features.code-scanning %}'
|
||||
permissions: 'If you have write permission to a repository you can manage {% data variables.product.prodname_code_scanning %} alerts for that repository.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
redirect_from:
|
||||
- /github/managing-security-vulnerabilities/managing-alerts-from-automated-code-scanning
|
||||
- /github/finding-security-vulnerabilities-and-errors-in-your-code/managing-alerts-from-code-scanning
|
||||
|
||||
@@ -4,9 +4,7 @@ shortTitle: '{% data variables.product.prodname_code_scanning_capc %} in a conta
|
||||
intro: 'You can run {% data variables.product.prodname_code_scanning %} in a container by ensuring that all processes run in the same container.'
|
||||
product: '{% data reusables.gated-features.code-scanning %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
|
||||
{% data reusables.code-scanning.beta %}
|
||||
|
||||
@@ -6,9 +6,7 @@ product: '{% data reusables.gated-features.code-scanning %}'
|
||||
redirect_from:
|
||||
- /github/finding-security-vulnerabilities-and-errors-in-your-code/running-code-scanning-in-your-ci-system
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
<!--UI-LINK: When GitHub Enterprise Server doesn't have GitHub Actions set up, the Security > Code scanning alerts view links to this article.-->
|
||||
|
||||
|
||||
@@ -6,9 +6,7 @@ product: '{% data reusables.gated-features.code-scanning %}'
|
||||
redirect_from:
|
||||
- /github/finding-security-vulnerabilities-and-errors-in-your-code/about-sarif-support-for-code-scanning
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
|
||||
{% data reusables.code-scanning.beta %}
|
||||
|
||||
@@ -9,9 +9,7 @@ redirect_from:
|
||||
- /github/finding-security-vulnerabilities-and-errors-in-your-code/enabling-code-scanning
|
||||
- /github/finding-security-vulnerabilities-and-errors-in-your-code/enabling-code-scanning-for-a-repository
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
|
||||
{% data reusables.code-scanning.beta %}
|
||||
|
||||
@@ -5,9 +5,7 @@ intro: 'When {% data variables.product.prodname_code_scanning %} identifies a pr
|
||||
product: '{% data reusables.gated-features.code-scanning %}'
|
||||
permissions: 'If you have read permission for a repository, you can see annotations on pull requests. With write permission, you can see detailed information and resolve {% data variables.product.prodname_code_scanning %} alerts for that repository.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
|
||||
{% data reusables.code-scanning.beta %}
|
||||
|
||||
@@ -6,9 +6,7 @@ product: '{% data reusables.gated-features.code-scanning %}'
|
||||
redirect_from:
|
||||
- /github/finding-security-vulnerabilities-and-errors-in-your-code/troubleshooting-code-scanning-in-your-ci-system
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
|
||||
{% data reusables.code-scanning.beta-codeql-runner %}
|
||||
|
||||
@@ -6,9 +6,7 @@ product: '{% data reusables.gated-features.code-scanning %}'
|
||||
redirect_from:
|
||||
- /github/finding-security-vulnerabilities-and-errors-in-your-code/troubleshooting-code-scanning
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
|
||||
{% data reusables.code-scanning.beta %}
|
||||
|
||||
@@ -7,9 +7,7 @@ product: '{% data reusables.gated-features.code-scanning %}'
|
||||
redirect_from:
|
||||
- /github/managing-security-vulnerabilities/uploading-a-code-scanning-analysis-to-github
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
|
||||
{% data reusables.code-scanning.beta %}
|
||||
|
||||
@@ -5,8 +5,6 @@ intro: 'The {% data variables.product.prodname_codeql_runner %} allows you to us
|
||||
mapTopic: true
|
||||
product: '{% data reusables.gated-features.code-scanning %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
enterprise-server: '2.22'
|
||||
---
|
||||
|
||||
|
||||
@@ -51,9 +51,10 @@ versions:
|
||||
{% link_in_list /administering-a-repository %}
|
||||
|
||||
{% link_in_list /visualizing-repository-data-with-graphs %}
|
||||
{% link_in_list /managing-security-vulnerabilities %}
|
||||
|
||||
{% link_in_list /finding-security-vulnerabilities-and-errors-in-your-code %}
|
||||
{% if currentVersion == "enterprise-server@2.22" %}
|
||||
{% link_in_list /managing-security-vulnerabilities %}
|
||||
{% link_in_list /finding-security-vulnerabilities-and-errors-in-your-code %}{% endif %}
|
||||
|
||||
{% link_in_list /managing-files-in-a-repository %}
|
||||
|
||||
|
||||
@@ -5,8 +5,7 @@ redirect_from:
|
||||
- /articles/about-security-alerts-for-vulnerable-dependencies
|
||||
- /github/managing-security-vulnerabilities/about-security-alerts-for-vulnerable-dependencies
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
enterprise-server: '<=2.22'
|
||||
---
|
||||
|
||||
### About vulnerable dependencies
|
||||
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
title: About Dependabot security updates
|
||||
intro: '{% data variables.product.prodname_dependabot %} can fix vulnerable dependencies for you by raising pull requests with security updates.'
|
||||
shortTitle: About Dependabot security updates
|
||||
redirect_from:
|
||||
- /github/managing-security-vulnerabilities/about-github-dependabot-security-updates
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
### About {% data variables.product.prodname_dependabot_security_updates %}
|
||||
|
||||
{% data variables.product.prodname_dependabot_security_updates %} make it easier for you to fix vulnerable dependencies in your repository. If you enable this feature, when a {% data variables.product.prodname_dependabot %} alert is raised for a vulnerable dependency in the dependency graph of your repository, {% data variables.product.prodname_dependabot %} automatically tries to fix it. For more information, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies)" and "[Configuring {% data variables.product.prodname_dependabot_security_updates %}](/github/managing-security-vulnerabilities/configuring-dependabot-security-updates)."
|
||||
|
||||
{% data variables.product.prodname_dependabot %} checks whether it's possible to upgrade the vulnerable dependency to a fixed version without disrupting the dependency graph for the repository. Then {% data variables.product.prodname_dependabot %} raises a pull request to update the dependency to the minimum version that includes the patch and links the pull request to the {% data variables.product.prodname_dependabot %} alert, or reports an error on the alert. For more information, see "[Troubleshooting {% data variables.product.prodname_dependabot %} errors](/github/managing-security-vulnerabilities/troubleshooting-dependabot-errors)."
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note**
|
||||
|
||||
The {% data variables.product.prodname_dependabot_security_updates %} feature is available for repositories where you have enabled the dependency graph and {% data variables.product.prodname_dependabot_alerts %}. You will see a {% data variables.product.prodname_dependabot %} alert for every vulnerable dependency identified in your full dependency graph. However, security updates are triggered only for dependencies that are specified in a manifest or lock file. {% data variables.product.prodname_dependabot %} is unable to update an indirect or transitive dependency that is not explicitly defined. For more information, see "[About the dependency graph](/github/visualizing-repository-data-with-graphs/about-the-dependency-graph#dependencies-included)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
You can enable a related feature, {% data variables.product.prodname_dependabot_version_updates %}, so that {% data variables.product.prodname_dependabot %} raises pull requests to update the manifest to the latest version of the dependency, whenever it detects an outdated dependency. For more information, see "[About {% data variables.product.prodname_dependabot %} version updates](/github/administering-a-repository/about-dependabot-version-updates)."
|
||||
|
||||
{% data reusables.dependabot.pull-request-security-vs-version-updates %}
|
||||
|
||||
### About pull requests for security updates
|
||||
|
||||
Each pull request contains everything you need to quickly and safely review and merge a proposed fix into your project. This includes information about the vulnerability like release notes, changelog entries, and commit details. Details of which vulnerability a pull request resolves are hidden from anyone who does not have access to {% data variables.product.prodname_dependabot_alerts %} for the repository.
|
||||
|
||||
When you merge a pull request that contains a security update, the corresponding {% data variables.product.prodname_dependabot %} alert is marked as resolved for your repository. For more information about {% data variables.product.prodname_dependabot %} pull requests, see "[Managing pull requests for dependency updates](/github/administering-a-repository/managing-pull-requests-for-dependency-updates)."
|
||||
|
||||
{% data reusables.dependabot.automated-tests-note %}
|
||||
|
||||
### About compatibility scores
|
||||
|
||||
{% data variables.product.prodname_dependabot_security_updates %} may include compatibility scores to let you know whether updating a vulnerability could cause breaking changes to your project. These are calculated from CI tests in other public repositories where the same security update has been generated. An update's compatibility score is the percentage of CI runs that passed when updating between specific versions of the dependency.
|
||||
|
||||
### About notifications for {% data variables.product.prodname_dependabot %} security updates
|
||||
|
||||
You can filter your notifications on {% data variables.product.company_short %} to show {% data variables.product.prodname_dependabot %} security updates. For more information, see "[Managing notifications from your inbox](/github/managing-subscriptions-and-notifications-on-github/managing-notifications-from-your-inbox#dependabot-custom-filters)."
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
title: About GitHub Security Advisories
|
||||
intro: 'You can use {% data variables.product.prodname_security_advisories %} to privately discuss, fix, and publish information about security vulnerabilities in your repository.'
|
||||
redirect_from:
|
||||
- /articles/about-maintainer-security-advisories
|
||||
- /github/managing-security-vulnerabilities/about-maintainer-security-advisories
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
{% data reusables.repositories.security-advisory-admin-permissions %}
|
||||
|
||||
{% data reusables.security-advisory.security-researcher-cannot-create-advisory %}
|
||||
|
||||
### About {% data variables.product.prodname_security_advisories %}
|
||||
|
||||
{% data variables.product.prodname_security_advisories %} allows repository maintainers to privately discuss and fix a security vulnerability in a project. After collaborating on a fix, repository maintainers can publish the security advisory to publicly disclose the security vulnerability to the project's community. By publishing security advisories, repository maintainers make it easier for their community to update package dependencies and research the impact of the security vulnerabilities.
|
||||
|
||||
With {% data variables.product.prodname_security_advisories %}, you can:
|
||||
|
||||
1. Create a draft security advisory, and use the draft to privately discuss the impact of the vulnerability on your project.
|
||||
2. Privately collaborate to fix the vulnerability in a temporary private fork.
|
||||
3. Publish the security advisory to alert your community of the vulnerability.
|
||||
|
||||
{% data reusables.repositories.security-advisories-republishing %}
|
||||
|
||||
To get started, see "[Creating a security advisory](/github/managing-security-vulnerabilities/creating-a-security-advisory)."
|
||||
|
||||
You can give credit to individuals who contributed to a security advisory. For more information, see "[Editing a security advisory](/github/managing-security-vulnerabilities/editing-a-security-advisory#about-credits-for-security-advisories)."
|
||||
|
||||
{% data reusables.repositories.security-guidelines %}
|
||||
|
||||
{% data reusables.repositories.github-security-lab %}
|
||||
|
||||
### CVE identification numbers
|
||||
|
||||
{% data variables.product.prodname_security_advisories %} builds upon the foundation of the Common Vulnerabilities and Exposures (CVE) list. {% data variables.product.prodname_dotcom %} is a CVE Numbering Authority (CNA) and is authorized to assign CVE identification numbers. For more information, see "[About CVE](https://cve.mitre.org/about/index.html)" and "[CVE Numbering Authorities](https://cve.mitre.org/cve/cna.html)" on the CVE website.
|
||||
|
||||
When you create a security advisory for a public repository on {% data variables.product.prodname_dotcom %}, you have the option of providing an existing CVE identification number for the security vulnerability. {% data reusables.repositories.request-security-advisory-cve-id %}
|
||||
|
||||
Once you've published the security advisory and {% data variables.product.prodname_dotcom %} has assigned a CVE identification number to the vulnerability, {% data variables.product.prodname_dotcom %} publishes the CVE to the MITRE database.
|
||||
For more information, see "[Publishing a security advisory](/github/managing-security-vulnerabilities/publishing-a-security-advisory#requesting-a-cve-identification-number)."
|
||||
|
||||
### {% data variables.product.prodname_dependabot_alerts %} for published security advisories
|
||||
|
||||
{% data reusables.repositories.github-reviews-security-advisories %}
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
title: About managing vulnerable dependencies
|
||||
intro: '{% data variables.product.prodname_dotcom %} helps you to avoid using third-party software that contains known vulnerabilities.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
{% data variables.product.prodname_dotcom %} provides the following tools for removing and avoiding vulnerable dependencies.
|
||||
|
||||
#### Dependency graph
|
||||
The dependency graph is a summary of the manifest and lock files stored in a repository. It shows you the ecosystems and packages your codebase depends on (its dependencies) and the repositories and packages that depend on your project (its dependents). The information in the dependency graph is used by dependency review and {% data variables.product.prodname_dependabot %}.
|
||||
For more information, see "[About the dependency graph](/github/visualizing-repository-data-with-graphs/about-the-dependency-graph)."
|
||||
|
||||
#### Dependency review
|
||||
By checking the dependency reviews on pull requests you can avoid introducing vulnerabilities from dependencies into your codebase. If the pull requests adds a vulnerable dependency, or changes a dependency to a vulnerable version, this is highlighted in the dependency review. You can change the dependency to a patched version before merging the pull request. For more information, see "[Reviewing dependency changes in a pull request](/github/collaborating-with-issues-and-pull-requests/reviewing-dependency-changes-in-a-pull-request)."
|
||||
|
||||
#### {% data variables.product.prodname_dependabot_alerts %}
|
||||
{% data variables.product.prodname_dotcom %} can create {% data variables.product.prodname_dependabot_alerts %} when it detects vulnerable dependencies in your repository. The alert is displayed on the Security tab for the repository. The alert includes a link to the affected file in the project, and information about a fixed version. {% data variables.product.prodname_dotcom %} also notifies the maintainers of the repository, according to their notification preferences. For more information, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies)."
|
||||
|
||||
#### {% data variables.product.prodname_dependabot_security_updates %}
|
||||
When {% data variables.product.prodname_dotcom %} generates a {% data variables.product.prodname_dependabot %} alert for a vulnerable dependency in your repository, {% data variables.product.prodname_dependabot %} can automatically try to fix it for you. {% data variables.product.prodname_dependabot_security_updates %} are automatically generated pull requests that update a vulnerable dependency to a fixed version. For more information, see "[About {% data variables.product.prodname_dependabot_security_updates %}](/github/managing-security-vulnerabilities/about-dependabot-security-updates)."
|
||||
|
||||
|
||||
#### {% data variables.product.prodname_dependabot_version_updates %}
|
||||
Enabling {% data variables.product.prodname_dependabot_version_updates %} takes the effort out of maintaining your dependencies. With {% data variables.product.prodname_dependabot_version_updates %}, whenever {% data variables.product.prodname_dotcom %} identifies an outdated dependency, it raises a pull request to update the manifest to the latest version of the dependency. By contrast, {% data variables.product.prodname_dependabot_security_updates %} only raises pull requests to fix vulnerable dependencies. For more information, see "[About Dependabot version updates](/github/administering-a-repository/about-dependabot-version-updates)."
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
title: Adding a collaborator to a security advisory
|
||||
intro: You can add other users or teams to collaborate on a security advisory with you.
|
||||
redirect_from:
|
||||
- /articles/adding-a-collaborator-to-a-maintainer-security-advisory
|
||||
- /github/managing-security-vulnerabilities/adding-a-collaborator-to-a-maintainer-security-advisory
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
People with admin permissions to a security advisory can add collaborators to the security advisory.
|
||||
|
||||
### Adding a collaborator to a security advisory
|
||||
|
||||
Collaborators have write permissions to the security advisory. For more information, see "[Permission levels for security advisories](/github/managing-security-vulnerabilities/permission-levels-for-security-advisories)."
|
||||
|
||||
{% note %}
|
||||
|
||||
{% data reusables.repositories.security-advisory-collaborators-public-repositories %} For more information about removing a collaborator on a security advisory, see "[Removing a collaborator from a security advisory](/github/managing-security-vulnerabilities/removing-a-collaborator-from-a-security-advisory)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
{% data reusables.repositories.sidebar-advisories %}
|
||||
4. In the "Security Advisories" list, click the security advisory you'd like to add a collaborator to.
|
||||
5. On the right side of the page, under "Collaborators", type the name of the user or team you'd like to add to the security advisory.
|
||||
|
||||
6. Click **Add**.
|
||||
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[Permission levels for security advisories](/github/managing-security-vulnerabilities/permission-levels-for-security-advisories)"
|
||||
- "[Collaborating in a temporary private fork to resolve a security vulnerability](/github/managing-security-vulnerabilities/collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability)"
|
||||
- "[Removing a collaborator from a security advisory](/github/managing-security-vulnerabilities/removing-a-collaborator-from-a-security-advisory)"
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
title: Adding a security policy to your repository
|
||||
intro: You can give instructions for how to responsibly report a security vulnerability in your project by adding a security policy to your repository.
|
||||
redirect_from:
|
||||
- /articles/adding-a-security-policy-to-your-repository
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
### About security policies
|
||||
|
||||
To give people instructions for responsibly reporting security vulnerabilities in your project, you can add a _SECURITY.md_ file to your repository's root, `docs`, or `.github` folder. When someone creates an issue in your repository, they will see a link to your project's security policy.
|
||||
|
||||
You can create a default security policy for your organization or user account. For more information, see "[Creating a default community health file](/github/building-a-strong-community/creating-a-default-community-health-file)."
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip:** To help people find your security policy, you can link to your _SECURITY.md_ file from other places in your repository, such as your README file. For more information, see "[About READMEs](/articles/about-readmes)."
|
||||
|
||||
{% endtip %}
|
||||
|
||||
After someone reports a security vulnerability in your project, you can use {% data variables.product.prodname_security_advisories %} to disclose, fix, and publish information about the vulnerability. For more information, see "[About {% data variables.product.prodname_security_advisories %}](/github/managing-security-vulnerabilities/about-github-security-advisories)."
|
||||
|
||||
{% data reusables.repositories.github-security-lab %}
|
||||
|
||||
### Adding a security policy to your repository
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
3. In the left sidebar, click **Policy**.
|
||||
|
||||
4. Click **Start setup**.
|
||||
|
||||
5. In the new _SECURITY.md_ file, add information about supported versions of your project and how to report a vulnerability.
|
||||
{% data reusables.files.write_commit_message %}
|
||||
{% data reusables.files.choose-commit-email %}
|
||||
{% data reusables.files.choose_commit_branch %}
|
||||
{% data reusables.files.propose_file_change %}
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[About securing your repository](/github/administering-a-repository/about-securing-your-repository)"
|
||||
- "[Setting up your project for healthy contributions](/github/building-a-strong-community/setting-up-your-project-for-healthy-contributions)"
|
||||
- [{% data variables.product.prodname_security %}]({% data variables.product.prodname_security_link %})
|
||||
@@ -1,83 +0,0 @@
|
||||
---
|
||||
title: Browsing security vulnerabilities in the GitHub Advisory Database
|
||||
intro: 'The {% data variables.product.prodname_advisory_database %} allows you to browse or search for vulnerabilities that affect open source projects on {% data variables.product.company_short %}.'
|
||||
shortTitle: Browsing the Advisory Database
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
### About security vulnerabilities
|
||||
|
||||
{% data reusables.repositories.a-vulnerability-is %}
|
||||
|
||||
{% data variables.product.product_name %} will send you {% data variables.product.prodname_dependabot_alerts %} if we detect that any of the vulnerabilities from the {% data variables.product.prodname_advisory_database %} affect the packages that your repository depends on. For more information, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies)."
|
||||
|
||||
### About the {% data variables.product.prodname_advisory_database %}
|
||||
|
||||
The {% data variables.product.prodname_advisory_database %} contains a curated list of security vulnerabilities that have been mapped to packages tracked by the {% data variables.product.company_short %} dependency graph. {% data reusables.repositories.tracks-vulnerabilities %}
|
||||
|
||||
Each security advisory contains information about the vulnerability, including the description, severity, affected package, package ecosystem, affected versions and patched versions, impact, and optional information such as references, workarounds, and credits. In addition, advisories from the National Vulnerability Database list contain a link to the CVE record, where you can read more details about the vulnerability, its CVSS scores, and its qualitative severity level. For more information, see the "[National Vulnerability Database](https://nvd.nist.gov/)" from the National Institute of Standards and Technology.
|
||||
|
||||
The severity level is one of four possible levels defined in the "[Common Vulnerability Scoring System (CVSS), Section 5](https://www.first.org/cvss/specification-document)."
|
||||
- Low
|
||||
- Medium/Moderate
|
||||
- High
|
||||
- Critical
|
||||
|
||||
The {% data variables.product.prodname_advisory_database %} uses the CVSS levels described above. If {% data variables.product.company_short %} obtains a CVE, the {% data variables.product.prodname_advisory_database %} uses CVSS version 3.1. If the CVE is imported, the {% data variables.product.prodname_advisory_database %} supports both CVSS versions 3.0 and 3.1.
|
||||
|
||||
{% data reusables.repositories.github-security-lab %}
|
||||
|
||||
### Accessing an advisory in the {% data variables.product.prodname_advisory_database %}
|
||||
|
||||
1. Navigate to https://github.com/advisories.
|
||||
2. Optionally, to filter the list, use any of the drop-down menus.
|
||||
|
||||
3. Click on any advisory to view details.
|
||||
|
||||
{% note %}
|
||||
|
||||
The database is also accessible using the GraphQL API. For more information, see the "[`security_advisory` webhook event](/webhooks/event-payloads/#security_advisory)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
### Searching the {% data variables.product.prodname_advisory_database %}
|
||||
|
||||
You can search the database, and use qualifiers to narrow your search. For example, you can search for advisories created on a certain date, in a specific ecosystem, or in a particular library.
|
||||
|
||||
{% data reusables.time_date.date_format %} {% data reusables.time_date.time_format %}
|
||||
|
||||
{% data reusables.search.date_gt_lt %}
|
||||
|
||||
| Qualifier | Example |
|
||||
| ------------- | ------------- |
|
||||
| `GHSA-ID`| [**GHSA-49wp-qq6x-g2rf**](https://github.com/advisories?query=GHSA-49wp-qq6x-g2rf) will show the advisory with this {% data variables.product.prodname_advisory_database %} ID. |
|
||||
| `CVE-ID`| [**CVE-2020-28482**](https://github.com/advisories?query=CVE-2020-28482) will show the advisory with this CVE ID number. |
|
||||
| `ecosystem:ECOSYSTEM`| [**ecosystem:npm**](https://github.com/advisories?utf8=%E2%9C%93&query=ecosystem%3Anpm) will show only advisories affecting NPM packages. |
|
||||
| `severity:LEVEL`| [**severity:high**](https://github.com/advisories?utf8=%E2%9C%93&query=severity%3Ahigh) will show only advisories with a high severity level. |
|
||||
| `affects:LIBRARY`| [**affects:lodash**](https://github.com/advisories?utf8=%E2%9C%93&query=affects%3Alodash) will show only advisories affecting the lodash library. |
|
||||
| `cwe:ID`| [**cwe:352**](https://github.com/advisories?query=cwe%3A352) will show only advisories with this CWE number. |
|
||||
| `credit:USERNAME`| [**credit:octocat**](https://github.com/advisories?query=credit%3Aoctocat) will show only advisories credited to the "octocat" user account. |
|
||||
| `sort:created-asc`| [**sort:created-asc**](https://github.com/advisories?utf8=%E2%9C%93&query=sort%3Acreated-asc) will sort by the oldest advisories first. |
|
||||
| `sort:created-desc`| [**sort:created-desc**](https://github.com/advisories?utf8=%E2%9C%93&query=sort%3Acreated-desc) will sort by the newest advisories first. |
|
||||
| `sort:updated-asc`| [**sort:updated-asc**](https://github.com/advisories?utf8=%E2%9C%93&query=sort%3Aupdated-asc) will sort by the least recently updated first. |
|
||||
| `sort:updated-desc`| [**sort:updated-desc**](https://github.com/advisories?utf8=%E2%9C%93&query=sort%3Aupdated-desc) will sort by the most recently updated first. |
|
||||
| `is:withdrawn`| [**is:withdrawn**](https://github.com/advisories?utf8=%E2%9C%93&query=is%3Awithdrawn) will show only advisories that have been withdrawn. |
|
||||
| `created:YYYY-MM-DD`| [**created:2021-01-13**](https://github.com/advisories?utf8=%E2%9C%93&query=created%3A2021-01-13) will show only advisories created on this date. |
|
||||
| `updated:YYYY-MM-DD`| [**updated:2021-01-13**](https://github.com/advisories?utf8=%E2%9C%93&query=updated%3A2021-01-13) will show only advisories updated on this date. |
|
||||
|
||||
### Viewing your vulnerable repositories
|
||||
|
||||
For any vulnerability in the {% data variables.product.prodname_advisory_database %}, you can see which of your repositories have a {% data variables.product.prodname_dependabot %} alert for that vulnerability. To see a vulnerable repository, you must have access to {% data variables.product.prodname_dependabot_alerts %} for that repository. For more information, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies#access-to-dependabot-alerts)."
|
||||
|
||||
1. Navigate to https://github.com/advisories.
|
||||
2. Click an advisory.
|
||||
3. At the top of the advisory page, click **Dependabot alerts**.
|
||||
|
||||
4. Optionally, to filter the list, use the search bar or the drop-down menus. The "Organization" drop-down menu allows you to filter the {% data variables.product.prodname_dependabot_alerts %} per owner (organization or user).
|
||||
|
||||
5. For more details about the vulnerability, and for advice on how to fix the vulnerable repository, click the repository name.
|
||||
|
||||
### Further reading
|
||||
|
||||
- MITRE's [definition of "vulnerability"](https://cve.mitre.org/about/terminology.html#vulnerability)
|
||||
@@ -1,83 +0,0 @@
|
||||
---
|
||||
title: Collaborating in a temporary private fork to resolve a security vulnerability
|
||||
intro: You can create a temporary private fork to privately collaborate on fixing a security vulnerability in your repository.
|
||||
redirect_from:
|
||||
- /articles/collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
### Prerequisites
|
||||
|
||||
Before you can collaborate in a temporary private fork, you must create a draft security advisory. For more information, see "[Creating a security advisory](/github/managing-security-vulnerabilities/creating-a-security-advisory)."
|
||||
|
||||
### Creating a temporary private fork
|
||||
|
||||
Anyone with admin permissions to a security advisory can create a temporary private fork.
|
||||
|
||||
To keep information about vulnerabilities secure, integrations, including CI, cannot access temporary private forks.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
{% data reusables.repositories.sidebar-advisories %}
|
||||
4. In the "Security Advisories" list, click the security advisory you'd like to create a temporary private fork in.
|
||||
|
||||
5. Click **New temporary private fork**.
|
||||
|
||||
|
||||
### Adding collaborators to a temporary private fork
|
||||
|
||||
Anyone with admin permissions to a security advisory can add additional collaborators to the security advisory, and collaborators on the security advisory can access the temporary private fork. For more information, see "[Adding a collaborator to a security advisory](/github/managing-security-vulnerabilities/adding-a-collaborator-to-a-security-advisory)."
|
||||
|
||||
### Adding changes to a temporary private fork
|
||||
|
||||
Anyone with write permissions to a security advisory can add changes to a temporary private fork.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
{% data reusables.repositories.sidebar-advisories %}
|
||||
4. In the "Security Advisories" list, click the security advisory you'd like to add changes to.
|
||||
|
||||
5. Add your changes on {% data variables.product.product_name %} or locally:
|
||||
- To add changes on {% data variables.product.product_name %}, under "Add changes to this advisory", click **the temporary private fork**. Then, create a new branch and edit files. For more information, see "[Creating and deleting branches within your repository](/articles/creating-and-deleting-branches-within-your-repository)" and "[Editing files in your repository](/articles/editing-files-in-your-repository)."
|
||||
- To add changes locally, follow the instructions under "Clone and create a new branch" and "Make your changes, then push."
|
||||
|
||||
|
||||
### Creating a pull request from a temporary private fork
|
||||
|
||||
Anyone with write permissions to a security advisory can create a pull request from a temporary private fork.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
{% data reusables.repositories.sidebar-advisories %}
|
||||
4. In the "Security Advisories" list, click the security advisory you'd like to create a pull request in.
|
||||
|
||||
5. To the right of your branch name, click **Compare & pull request**.
|
||||
|
||||
{% data reusables.repositories.pr-title-description %}
|
||||
{% data reusables.repositories.create-pull-request %}
|
||||
|
||||
{% data reusables.repositories.merge-all-pulls-together %} For more information, see "[Merging changes in a security advisory](#merging-changes-in-a-security-advisory)."
|
||||
|
||||
### Merging changes in a security advisory
|
||||
|
||||
Anyone with admin permissions to a security advisory can merge changes in a security advisory.
|
||||
|
||||
{% data reusables.repositories.merge-all-pulls-together %}
|
||||
|
||||
Before you can merge changes in a security advisory, every open pull request in the temporary private fork must be mergeable. There can be no merge conflicts, and branch protection requirements must be satisfied. To keep information about vulnerabilities secure, status checks do not run on pull requests in temporary private forks. For more information, see "[About protected branches](/articles/about-protected-branches)."
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
{% data reusables.repositories.sidebar-advisories %}
|
||||
4. In the "Security Advisories" list, click the security advisory with changes you'd like to merge.
|
||||
|
||||
5. To merge all open pull requests in the temporary private fork, click **Merge pull requests**.
|
||||
|
||||
|
||||
After you merge changes in a security advisory, you can publish the security advisory to alert your community about the security vulnerability in previous versions of your project. For more information, see "[Publishing a security advisory](/github/managing-security-vulnerabilities/publishing-a-security-advisory)."
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[Permission levels for security advisories](/github/managing-security-vulnerabilities/permission-levels-for-security-advisories)"
|
||||
- "[Publishing a security advisory](/github/managing-security-vulnerabilities/publishing-a-security-advisory)"
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
title: Configuring Dependabot security updates
|
||||
intro: 'You can use {% data variables.product.prodname_dependabot_security_updates %} or manual pull requests to easily update vulnerable dependencies.'
|
||||
shortTitle: Configuring Dependabot security updates
|
||||
redirect_from:
|
||||
- /articles/configuring-automated-security-fixes
|
||||
- /github/managing-security-vulnerabilities/configuring-automated-security-fixes
|
||||
- /github/managing-security-vulnerabilities/configuring-automated-security-updates
|
||||
- /github/managing-security-vulnerabilities/configuring-github-dependabot-security-updates
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
### About configuring {% data variables.product.prodname_dependabot_security_updates %}
|
||||
|
||||
You can enable {% data variables.product.prodname_dependabot_security_updates %} for any repository that uses {% data variables.product.prodname_dependabot_alerts %} and the dependency graph. For more information, see "[About {% data variables.product.prodname_dependabot_security_updates %}](/github/managing-security-vulnerabilities/about-dependabot-security-updates)."
|
||||
|
||||
You can disable {% data variables.product.prodname_dependabot_security_updates %} for an individual repository or for all repositories owned by your user account or organization. For more information, see "[Managing {% data variables.product.prodname_dependabot_security_updates %} for your repositories](#managing-dependabot-security-updates-for-your-repositories)" below.
|
||||
|
||||
{% data reusables.dependabot.dependabot-tos %}
|
||||
|
||||
### Supported repositories
|
||||
|
||||
{% data variables.product.prodname_dotcom %} automatically enables {% data variables.product.prodname_dependabot_security_updates %} for every repository that meets these prerequisites.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note**: You can manually enable {% data variables.product.prodname_dependabot_security_updates %}, even if the repository doesn't meet some of the prerequisites below. For example, you can enable {% data variables.product.prodname_dependabot_security_updates %} on a fork, or for a package manager that isn't directly supported by following the instructions in "[Managing {% data variables.product.prodname_dependabot_security_updates %} for your repositories](#managing-dependabot-security-updates-for-your-repositories)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
| Automatic enablement prerequisite | More information |
|
||||
| ----------------- | ----------------------- |
|
||||
| Repository is not a fork | "[About forks](/github/collaborating-with-issues-and-pull-requests/about-forks)" |
|
||||
| Repository is not archived | "[Archiving repositories](/github/creating-cloning-and-archiving-repositories/archiving-repositories)" |
|
||||
| Repository is public, or repository is private and you have enabled read-only analysis by {% data variables.product.prodname_dotcom %}, dependency graph, and vulnerability alerts in the repository's settings | "[Managing data use settings for your private repository](/github/understanding-how-github-uses-and-protects-your-data/managing-data-use-settings-for-your-private-repository)." |
|
||||
| Repository contains dependency manifest file from a package ecosystem that {% data variables.product.prodname_dotcom %} supports | "[Supported package ecosystems](/github/visualizing-repository-data-with-graphs/about-the-dependency-graph#supported-package-ecosystems)" |
|
||||
| {% data variables.product.prodname_dependabot_security_updates %} are not disabled for the repository | "[Managing {% data variables.product.prodname_dependabot_security_updates %} for your repository](#managing-dependabot-security-updates-for-your-repositories)" |
|
||||
| Repository is not already using an integration for dependency management | "[About integrations](/github/customizing-your-github-workflow/about-integrations)" |
|
||||
|
||||
If security updates are not enabled for your repository and you don't know why, first try enabling them using the instructions given in the procedural sections below. If security updates are still not working, you can [contact support](https://support.github.com/contact).
|
||||
|
||||
### Managing {% data variables.product.prodname_dependabot_security_updates %} for your repositories
|
||||
|
||||
You can enable or disable {% data variables.product.prodname_dependabot_security_updates %} for an individual repository (see below).
|
||||
|
||||
You can also enable or disable {% data variables.product.prodname_dependabot_security_updates %} for all repositories owned by your user account or organization. For more information, see "[Managing security and analysis settings for your user account](/github/setting-up-and-managing-your-github-user-account/managing-security-and-analysis-settings-for-your-user-account)" or "[Managing security and analysis settings for your organization](/github/setting-up-and-managing-organizations-and-teams/managing-security-and-analysis-settings-for-your-organization)."
|
||||
|
||||
{% data variables.product.prodname_dependabot_security_updates %} require specific repository settings. For more information, see "[Supported repositories](#supported-repositories)."
|
||||
|
||||
#### Enabling or disabling {% data variables.product.prodname_dependabot_security_updates %} for an individual repository
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.navigate-to-security-and-analysis %}
|
||||
1. Under "Configure security and analysis features", to the right of "{% data variables.product.prodname_dependabot %} security updates", click **Enable** or **Disable**.
|
||||
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies)"
|
||||
- "[Managing data use settings for your private repository](/github/understanding-how-github-uses-and-protects-your-data/managing-data-use-settings-for-your-private-repository)"
|
||||
- "[Supported package ecosystems](/github/visualizing-repository-data-with-graphs/about-the-dependency-graph#supported-package-ecosystems)"
|
||||
@@ -3,8 +3,7 @@ title: Configuring notifications for vulnerable dependencies
|
||||
shortTitle: Configuring notifications
|
||||
intro: 'Optimize how you receive notifications about {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" %}{% data variables.product.prodname_dependabot %}{% else %}security{% endif %} alerts.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.21'
|
||||
enterprise-server: '<=2.22'
|
||||
---
|
||||
|
||||
### About notifications for vulnerable dependencies
|
||||
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
title: Creating a security advisory
|
||||
intro: You can create a draft security advisory to privately discuss and fix a security vulnerability in your open source project.
|
||||
redirect_from:
|
||||
- /articles/creating-a-maintainer-security-advisory
|
||||
- /github/managing-security-vulnerabilities/creating-a-maintainer-security-advisory
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
Anyone with admin permissions to a repository can create a security advisory.
|
||||
|
||||
{% data reusables.security-advisory.security-researcher-cannot-create-advisory %}
|
||||
|
||||
### Creating a security advisory
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
{% data reusables.repositories.sidebar-advisories %}
|
||||
4. Click **New draft security advisory**.
|
||||
|
||||
5. Type a title for your security advisory.
|
||||
{% data reusables.repositories.security-advisory-edit-details %}
|
||||
{% data reusables.repositories.security-advisory-edit-severity %}
|
||||
{% data reusables.repositories.security-advisory-edit-cwe-cve %}
|
||||
{% data reusables.repositories.security-advisory-edit-description %}
|
||||
11. Click **Create draft security advisory**.
|
||||
|
||||
|
||||
### Next steps
|
||||
|
||||
- Comment on the draft security advisory to discuss the vulnerability with your team.
|
||||
- Add collaborators to the security advisory. For more information, see "[Adding a collaborator to a security advisory](/github/managing-security-vulnerabilities/adding-a-collaborator-to-a-maintainer-security-advisory)."
|
||||
- Privately collaborate to fix the vulnerability in a temporary private fork. For more information, see "[Collaborating in a temporary private fork to resolve a security vulnerability](/github/managing-security-vulnerabilities/collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability)."
|
||||
- Add individuals who should receive credit for contributing to the security advisory. For more information, see "[Editing a security advisory](/github/managing-security-vulnerabilities/editing-a-security-advisory#about-credits-for-security-advisories)."
|
||||
- Publish the security advisory to notify your community of the security vulnerability. For more information, see "[Publishing a security advisory](/github/managing-security-vulnerabilities/publishing-a-security-advisory)."
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
title: Editing a security advisory
|
||||
intro: You can edit the metadata and description for a security advisory if you need to update details or correct errors.
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
People with admin permissions to a security advisory can edit the security advisory.
|
||||
|
||||
### About credits for security advisories
|
||||
|
||||
You can credit people who helped discover, report, or fix a security vulnerability. If you credit someone, they can choose to accept or decline credit.
|
||||
|
||||
If someone accepts credit, the person's username appears in the "Credits" section of the security advisory. Anyone with read access to the repository can see the advisory and the people who accepted credit for it.
|
||||
|
||||
### Editing a security advisory
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
{% data reusables.repositories.sidebar-advisories %}
|
||||
4. In the "Security Advisories" list, click the security advisory you'd like to edit.
|
||||
5. In the upper-right corner of the details for the security advisory, click {% octicon "pencil" aria-label="The edit icon" %}.
|
||||
|
||||
{% data reusables.repositories.security-advisory-edit-details %}
|
||||
{% data reusables.repositories.security-advisory-edit-severity %}
|
||||
{% data reusables.repositories.security-advisory-edit-cwe-cve %}
|
||||
{% data reusables.repositories.security-advisory-edit-description %}
|
||||
11. Optionally, edit the "Credits" for the security advisory.
|
||||
|
||||
12. Click **Update security advisory**.
|
||||
|
||||
13. The people listed in the "Credits" section will receive an email or web notification inviting them to accept credit. If a person accepts, their username will be publicly visible once the security advisory is published.
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[Withdrawing a security advisory](/github/managing-security-vulnerabilities/withdrawing-a-security-advisory)"
|
||||
@@ -3,30 +3,11 @@ title: Managing security vulnerabilities
|
||||
redirect_from:
|
||||
- /categories/managing-security-vulnerabilities
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
enterprise-server: '<=2.22'
|
||||
---
|
||||
|
||||
|
||||
### Table of Contents
|
||||
{% topic_link_in_list /managing-security-vulnerabilities-in-your-project %}
|
||||
{% link_in_list /adding-a-security-policy-to-your-repository %}
|
||||
{% link_in_list /about-github-security-advisories %}
|
||||
{% link_in_list /permission-levels-for-security-advisories %}
|
||||
{% link_in_list /creating-a-security-advisory %}
|
||||
{% link_in_list /adding-a-collaborator-to-a-security-advisory %}
|
||||
{% link_in_list /removing-a-collaborator-from-a-security-advisory %}
|
||||
{% link_in_list /collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability %}
|
||||
{% link_in_list /publishing-a-security-advisory %}
|
||||
{% link_in_list /editing-a-security-advisory %}
|
||||
{% link_in_list /withdrawing-a-security-advisory %}
|
||||
{% topic_link_in_list /managing-vulnerabilities-in-your-projects-dependencies %}
|
||||
{% link_in_list /about-managing-vulnerable-dependencies %}
|
||||
{% link_in_list /browsing-security-vulnerabilities-in-the-github-advisory-database %}
|
||||
{% link_in_list /about-alerts-for-vulnerable-dependencies %}
|
||||
{% link_in_list /configuring-notifications-for-vulnerable-dependencies %}
|
||||
{% link_in_list /about-dependabot-security-updates %}
|
||||
{% link_in_list /configuring-dependabot-security-updates %}
|
||||
{% link_in_list /viewing-and-updating-vulnerable-dependencies-in-your-repository %}
|
||||
{% link_in_list /troubleshooting-the-detection-of-vulnerable-dependencies %}
|
||||
{% link_in_list /troubleshooting-dependabot-errors %}
|
||||
|
||||
@@ -1,10 +0,0 @@
|
||||
---
|
||||
title: Managing security vulnerabilities in your project
|
||||
intro: 'You can discover, discuss, fix, and disclose security vulnerabilities in your repositories.'
|
||||
mapTopic: true
|
||||
redirect_from:
|
||||
- /articles/managing-security-vulnerabilities-in-your-project
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
@@ -8,7 +8,6 @@ redirect_from:
|
||||
- /articles/managing-security-vulnerabilities-in-your-projects-dependencies/
|
||||
- /articles/managing-vulnerabilities-in-your-projects-dependencies
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
enterprise-server: '<=2.22'
|
||||
---
|
||||
|
||||
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
title: Permission levels for security advisories
|
||||
intro: The actions you can take in a security advisory depend on whether you have admin or write permissions to the security advisory.
|
||||
redirect_from:
|
||||
- /articles/permission-levels-for-maintainer-security-advisories
|
||||
- /github/managing-security-vulnerabilities/permission-levels-for-maintainer-security-advisories
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
### Permissions overview
|
||||
|
||||
{% data reusables.repositories.security-advisory-admin-permissions %} For more information about adding a collaborator to a security advisory, see "[Adding a collaborator to a security advisory](/github/managing-security-vulnerabilities/adding-a-collaborator-to-a-security-advisory)."
|
||||
|
||||
Action | Write permissions | Admin permissions |
|
||||
------ | ----------------- | ----------------- |
|
||||
See a draft security advisory | X | X |
|
||||
Add collaborators to the security advisory (see "[Adding a collaborator to a security advisory](/github/managing-security-vulnerabilities/adding-a-collaborator-to-a-security-advisory)") | | X |
|
||||
Edit and delete any comments in the security advisory | X | X |
|
||||
Create a temporary private fork in the security advisory (see "[Collaborating in a temporary private fork to resolve a security vulnerability](/articles/collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability)") | | X |
|
||||
Add changes to a temporary private fork in the security advisory (see "[Collaborating in a temporary private fork to resolve a security vulnerability](/articles/collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability)") | X | X |
|
||||
Create pull requests in a temporary private fork (see "[Collaborating in a temporary private fork to resolve a security vulnerability](/github/managing-security-vulnerabilities/collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability)") | X | X |
|
||||
Merge changes in the security advisory (see "[Collaborating in a temporary private fork to resolve a security vulnerability](/articles/collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability)") | | X |
|
||||
Add and edit metadata in the security advisory (see "[Publishing a security advisory](/github/managing-security-vulnerabilities/publishing-a-security-advisory)") | X | X |
|
||||
Add and remove credits for a security advisory (see "[Editing a security advisory](/github/managing-security-vulnerabilities/editing-a-security-advisory#about-credits-for-security-advisories)") | X | X |
|
||||
Close the draft security advisory | | X |
|
||||
Publish the security advisory (see "[Publishing a security advisory](/github/managing-security-vulnerabilities/publishing-a-security-advisory)") | | X |
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[Adding a collaborator to a security advisory](/github/managing-security-vulnerabilities/adding-a-collaborator-to-a-security-advisory)"
|
||||
- "[Collaborating in a temporary private fork to resolve a security vulnerability](/github/managing-security-vulnerabilities/collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability)"
|
||||
- "[Removing a collaborator from a security advisory](/github/managing-security-vulnerabilities/removing-a-collaborator-from-a-security-advisory)"
|
||||
- "[Withdrawing a security advisory](/github/managing-security-vulnerabilities/withdrawing-a-security-advisory)"
|
||||
@@ -1,88 +0,0 @@
|
||||
---
|
||||
title: Publishing a security advisory
|
||||
intro: You can publish a security advisory to alert your community about a security vulnerability in your project.
|
||||
redirect_from:
|
||||
- /articles/publishing-a-maintainer-security-advisory
|
||||
- /github/managing-security-vulnerabilities/publishing-a-maintainer-security-advisory
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
Anyone with admin permissions to a security advisory can publish the security advisory.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
Before you can publish a security advisory or request a CVE identification number, you must create a draft security advisory and provide information about the versions of your project affected by the security vulnerability. For more information, see "[Creating a security advisory](/github/managing-security-vulnerabilities/creating-a-security-advisory)."
|
||||
|
||||
If you've created a security advisory but haven't yet provided details about the versions of your project that the security vulnerability affects, you can edit the security advisory. For more information, see "[Editing a security advisory](/github/managing-security-vulnerabilities/editing-a-security-advisory)."
|
||||
|
||||
### About publishing a security advisory
|
||||
|
||||
When you publish a security advisory, you notify your community about the security vulnerability that the security advisory addresses. Publishing a security advisory makes it easier for your community to update package dependencies and research the impact of the security vulnerability.
|
||||
|
||||
{% data reusables.repositories.security-advisories-republishing %}
|
||||
|
||||
Before you publish a security advisory, you can privately collaborate to fix the vulnerability in a temporary private fork. For more information, see "[Collaborating in a temporary private fork to resolve a security vulnerability](/articles/collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability)."
|
||||
|
||||
{% warning %}
|
||||
|
||||
**Warning**: Whenever possible, you should always add a fix version to a security advisory prior to publishing the advisory. If you don't, the advisory will be published without a fixed version, and {% data variables.product.prodname_dependabot %} will alert your users about the issue, without offering any safe version to update to.
|
||||
|
||||
We recommend you take the following steps in these different situations:
|
||||
|
||||
- If a fix version is imminently available, and you are able to, wait to disclose the issue when the fix is ready.
|
||||
- If a fix version is in development but not yet available, mention this in the advisory, and edit the advisory later, after publication.
|
||||
- If you are not planning to fix the issue, be clear about it in the advisory so that your users don't contact you to ask when a fix will be made. In this case, it is helpful to include steps users can take to mitigate the issue.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
When you publish a draft advisory from a public repository, everyone is able to see:
|
||||
|
||||
- The current version of the advisory data.
|
||||
- Any advisory credits that the credited users have accepted.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note**: The general public will never have access to the edit history of the advisory, and will only see the published version.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
After you publish a security advisory, the URL for the security advisory will remain the same as before you published the security advisory. Anyone with read access to the repository can see the security advisory. Collaborators on the security advisory can continue to view past conversations, including the full comment stream, in the security advisory unless someone with admin permissions removes the collaborator from the security advisory.
|
||||
|
||||
If you need to update or correct information in a security advisory that you've published, you can edit the security advisory. For more information, see "[Editing a security advisory](/github/managing-security-vulnerabilities/editing-a-security-advisory)."
|
||||
|
||||
### Requesting a CVE identification number
|
||||
|
||||
Anyone with admin permissions to a security advisory can request a CVE identification number for the security advisory.
|
||||
|
||||
{% data reusables.repositories.request-security-advisory-cve-id %} For more information, see "[About {% data variables.product.prodname_security_advisories %}](/github/managing-security-vulnerabilities/about-github-security-advisories#cve-identification-numbers)."
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
{% data reusables.repositories.sidebar-advisories %}
|
||||
4. In the "Security Advisories" list, click the security advisory you'd like to request a CVE identification number for.
|
||||
|
||||
5. Use the **Publish advisory** drop-down menu, and click **Request CVE**.
|
||||
|
||||
6. Click **Request CVE**.
|
||||
|
||||
|
||||
### Publishing a security advisory
|
||||
|
||||
Publishing a security advisory deletes the temporary private fork for the security advisory.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
{% data reusables.repositories.sidebar-advisories %}
|
||||
4. In the "Security Advisories" list, click the security advisory you'd like to publish.
|
||||
|
||||
5. At the bottom of the page, click **Publish advisory**.
|
||||
|
||||
|
||||
### {% data variables.product.prodname_dependabot_alerts %} for published security advisories
|
||||
|
||||
{% data reusables.repositories.github-reviews-security-advisories %}
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[Withdrawing a security advisory](/github/managing-security-vulnerabilities/withdrawing-a-security-advisory)"
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
title: Removing a collaborator from a security advisory
|
||||
intro: 'When you remove a collaborator from a security advisory, they lose read and write access to the security advisory''s discussion and metadata.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
People with admin permissions to a security advisory can remove collaborators from the security advisory.
|
||||
|
||||
### Removing a collaborator from a security advisory
|
||||
|
||||
{% data reusables.repositories.security-advisory-collaborators-public-repositories %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
{% data reusables.repositories.sidebar-advisories %}
|
||||
4. In the "Security Advisories" list, click the security advisory you'd like to remove a collaborator from.
|
||||
|
||||
5. On the right side of the page, under "Collaborators", find the name of the user or team you'd like to remove from the security advisory.
|
||||
|
||||
6. Next to the collaborator you want to remove, click the **X** icon.
|
||||
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[Permission levels for security advisories](/github/managing-security-vulnerabilities/permission-levels-for-security-advisories)"
|
||||
- "[Adding a collaborator to a security advisory](/github/managing-security-vulnerabilities/adding-a-collaborator-to-a-security-advisory)"
|
||||
@@ -1,103 +0,0 @@
|
||||
---
|
||||
title: Troubleshooting Dependabot errors
|
||||
intro: 'Sometimes {% data variables.product.prodname_dependabot %} is unable to raise a pull request to update your dependencies. You can review the error and unblock {% data variables.product.prodname_dependabot %}.'
|
||||
shortTitle: Troubleshooting errors
|
||||
redirect_from:
|
||||
- /github/managing-security-vulnerabilities/troubleshooting-github-dependabot-errors
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
{% data reusables.dependabot.beta-note %}
|
||||
|
||||
### About {% data variables.product.prodname_dependabot %} errors
|
||||
|
||||
{% data reusables.dependabot.pull-request-introduction %}
|
||||
|
||||
If anything prevents {% data variables.product.prodname_dependabot %} from raising a pull request, this is reported as an error.
|
||||
|
||||
### Investigating errors with {% data variables.product.prodname_dependabot_security_updates %}
|
||||
|
||||
When {% data variables.product.prodname_dependabot %} is blocked from creating a pull request to fix a {% data variables.product.prodname_dependabot %} alert, it posts the error message on the alert. The {% data variables.product.prodname_dependabot_alerts %} view shows a list of any alerts that have not been resolved yet. To access the alerts view, click **{% data variables.product.prodname_dependabot_alerts %}** on the **Security** tab for the repository. Where a pull request that will fix the vulnerable dependency has been generated, the alert includes a link to that pull request.
|
||||
|
||||
|
||||
|
||||
There are three reasons why an alert may have no pull request link:
|
||||
|
||||
1. {% data variables.product.prodname_dependabot_security_updates %} are not enabled for the repository.
|
||||
1. The alert is for an indirect or transitive dependency that is not explicitly defined in a lock file.
|
||||
1. An error blocked {% data variables.product.prodname_dependabot %} from creating a pull request.
|
||||
|
||||
If an error blocked {% data variables.product.prodname_dependabot %} from creating a pull request, you can display details of the error by clicking the alert.
|
||||
|
||||
|
||||
|
||||
### Investigating errors with {% data variables.product.prodname_dependabot_version_updates %}
|
||||
|
||||
When {% data variables.product.prodname_dependabot %} is blocked from creating a pull request to update a dependency in an ecosystem, it posts the error icon on the manifest file. The manifest files that are managed by {% data variables.product.prodname_dependabot %} are listed on the {% data variables.product.prodname_dependabot %} tab. To access this tab, on the **Insights** tab for the repository click **Dependency graph**, and then click the **{% data variables.product.prodname_dependabot %}** tab.
|
||||
|
||||
|
||||
|
||||
To see the log file for any manifest file, click the **Last checked TIME ago** link. When you display the log file for a manifest that's shown with an error symbol (for example, Maven in the screenshot above), any errors are also displayed.
|
||||
|
||||
|
||||
|
||||
### Understanding {% data variables.product.prodname_dependabot %} errors
|
||||
|
||||
Pull requests for security updates act to upgrade a vulnerable dependency to the minimum version that includes a fix for the vulnerability. In contrast, pull requests for version updates act to upgrade a dependency to the latest version allowed by the package manifest and {% data variables.product.prodname_dependabot %} configuration files. Consequently, some errors are specific to one type of update.
|
||||
|
||||
#### {% data variables.product.prodname_dependabot %} cannot update DEPENDENCY to a non-vulnerable version
|
||||
|
||||
**Security updates only.** {% data variables.product.prodname_dependabot %} cannot create a pull request to update the vulnerable dependency to a secure version without breaking other dependencies in the dependency graph for this repository.
|
||||
|
||||
Every application that has dependencies has a dependency graph, that is, a directed acyclic graph of every package version that the application directly or indirectly depends on. Every time a dependency is updated, this graph must resolve otherwise the application won't build. When an ecosystem has a deep and complex dependency graph, for example, npm and RubyGems, it is often impossible to upgrade a single dependency without upgrading the whole ecosystem.
|
||||
|
||||
The best way to avoid this problem is to stay up to date with the most recently released versions, for example, by enabling version updates. This increases the likelihood that a vulnerability in one dependency can be resolved by a simple upgrade that doesn't break the dependency graph. For more information, see "[Enabling and disabling version updates](/github/administering-a-repository/enabling-and-disabling-version-updates)."
|
||||
|
||||
#### {% data variables.product.prodname_dependabot %} cannot update to the required version as there is already an open pull request for the latest version
|
||||
|
||||
**Security updates only.** {% data variables.product.prodname_dependabot %} will not create a pull request to update the vulnerable dependency to a secure version because there is already an open pull request to update this dependency. You will see this error when a vulnerability is detected in a single dependency and there's already an open pull request to update the dependency to the latest version.
|
||||
|
||||
There are two options: you can review the open pull request and merge it as soon as you are confident that the change is safe, or close that pull request and trigger a new security update pull request. For more information, see "[Triggering a {% data variables.product.prodname_dependabot %} pull request manually](#triggering-a-dependabot-pull-request-manually)."
|
||||
|
||||
#### {% data variables.product.prodname_dependabot %} timed out during its update
|
||||
|
||||
{% data variables.product.prodname_dependabot %} took longer than the maximum time allowed to assess the update required and prepare a pull request. This error is usually seen only for large repositories with many manifest files, for example, npm or yarn monorepo projects with hundreds of *package.json* files. Updates to the Composer ecosystem also take longer to assess and may time out.
|
||||
|
||||
This error is difficult to address. If a version update times out, you could specify the most important dependencies to update using the `allow` parameter or, alternatively, use the `ignore` parameter to exclude some dependencies from updates. Updating your configuration might allow {% data variables.product.prodname_dependabot %} to review the version update and generate the pull request in the time available.
|
||||
|
||||
If a security update times out, you can reduce the chances of this happening by keeping the dependencies updated, for example, by enabling version updates. For more information, see "[Enabling and disabling version updates](/github/administering-a-repository/enabling-and-disabling-version-updates)."
|
||||
|
||||
#### {% data variables.product.prodname_dependabot %} cannot open any more pull requests
|
||||
|
||||
There's a limit on the number of open pull requests {% data variables.product.prodname_dependabot %} will generate. When this limit is reached, no new pull requests are opened and this error is reported. The best way to resolve this error is to review and merge some of the open pull requests.
|
||||
|
||||
There are separate limits for security and version update pull requests, so that open version update pull requests cannot block the creation of a security update pull request. The limit for security update pull requests is 10. By default, the limit for version updates is 5 but you can change this using the `open-pull-requests-limit` parameter in the configuration file. For more information, see "[Configuration options for dependency updates](/github/administering-a-repository/configuration-options-for-dependency-updates#open-pull-requests-limit)."
|
||||
|
||||
The best way to resolve this error is to merge or close some of the existing pull requests and trigger a new pull request manually. For more information, see "[Triggering a {% data variables.product.prodname_dependabot %} pull request manually](#triggering-a-dependabot-pull-request-manually)."
|
||||
|
||||
#### {% data variables.product.prodname_dependabot %} can't resolve or access your dependencies
|
||||
|
||||
If {% data variables.product.prodname_dependabot %} attempts to check whether dependency references need to be updated in a repository, but can't access one or more of the referenced files, the operation will fail with the error message "{% data variables.product.prodname_dependabot %} can't resolve your LANGUAGE dependency files." The API error type is `git_dependencies_not_reachable`.
|
||||
|
||||
Similarly, if {% data variables.product.prodname_dependabot %} can't access a private package registry in which a dependency is located, one of the following errors is generated:
|
||||
|
||||
* "Dependabot can't reach a dependency in a private package registry"<br>
|
||||
(API error type: `private_source_not_reachable`)
|
||||
* "Dependabot can't authenticate to a private package registry"<br>
|
||||
(API error type:`private_source_authentication_failure`)
|
||||
* "Dependabot timed out while waiting for a private package registry"<br>
|
||||
(API error type:`private_source_timed_out`)
|
||||
* "Dependabot couldn't validate the certificate for a private package registry"<br>
|
||||
(API error type:`private_source_certificate_failure`)
|
||||
|
||||
To allow {% data variables.product.prodname_dependabot %} to update the dependency references successfully, make sure that all of the referenced dependencies are hosted at accessible locations.
|
||||
|
||||
**Version updates only.** {% data reusables.dependabot.private-dependencies-note %} Additionally, {% data variables.product.prodname_dependabot %} doesn't support private {% data variables.product.prodname_dotcom %} dependencies for all package managers. For more information, see "[About Dependabot version updates](/github/administering-a-repository/about-dependabot-version-updates#supported-repositories-and-ecosystems)."
|
||||
|
||||
### Triggering a {% data variables.product.prodname_dependabot %} pull request manually
|
||||
|
||||
If you unblock {% data variables.product.prodname_dependabot %}, you can manually trigger a fresh attempt to create a pull request.
|
||||
|
||||
- **Security updates**—display the {% data variables.product.prodname_dependabot %} alert that shows the error you have fixed and click **Create {% data variables.product.prodname_dependabot %} security update**.
|
||||
- **Version updates**—on the **Insights** tab for the repository click **Dependency graph**, and then click the **Dependabot** tab. Click **Last checked *TIME* ago** to see the log file that {% data variables.product.prodname_dependabot %} generated during the last check for version updates. Click **Check for updates**.
|
||||
@@ -1,101 +0,0 @@
|
||||
---
|
||||
title: Troubleshooting the detection of vulnerable dependencies
|
||||
intro: 'If the dependency information reported by {% data variables.product.product_name %} is not what you expected, there are a number of points to consider, and various things you can check.'
|
||||
shortTitle: Troubleshooting detection
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
The results of dependency detection reported by {% data variables.product.product_name %} may be different from the results returned by other tools. There are good reasons for this and it's helpful to understand how {% data variables.product.prodname_dotcom %} determines dependencies for your project.
|
||||
|
||||
### Why do some dependencies seem to be missing?
|
||||
|
||||
{% data variables.product.prodname_dotcom %} 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:
|
||||
|
||||
* {% data variables.product.prodname_advisory_database %} is one of the data sources that {% data variables.product.prodname_dotcom %} uses to identify vulnerable dependencies. It's a free, curated database of vulnerability information for common package ecosystems on {% data variables.product.prodname_dotcom %}. It includes both data reported directly to {% data variables.product.prodname_dotcom %} from {% data variables.product.prodname_security_advisories %}, as well as official feeds and community sources. This data is reviewed and curated by {% data variables.product.prodname_dotcom %} to ensure that false or unactionable information is not shared with the development community. For more information, see "[Browsing security vulnerabilities in the {% data variables.product.prodname_advisory_database %}](/github/managing-security-vulnerabilities/browsing-security-vulnerabilities-in-the-github-advisory-database)" and "[About {% data variables.product.prodname_security_advisories %}](/github/managing-security-vulnerabilities/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](/github/visualizing-repository-data-with-graphs/about-the-dependency-graph)."
|
||||
* {% data variables.product.prodname_dependabot %} 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. {% data variables.product.prodname_dependabot_alerts %} are aggregated at the repository level, rather than creating one alert per vulnerability. For more information, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies)."
|
||||
* {% data variables.product.prodname_dependabot_security_updates %} are triggered when you receive an alert about a vulnerable dependency in your repository. Where possible, {% data variables.product.prodname_dependabot %} 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 {% data variables.product.prodname_dependabot_security_updates %}](/github/managing-security-vulnerabilities/about-dependabot-security-updates)" and "[Troubleshooting {% data variables.product.prodname_dependabot %} errors](/github/managing-security-vulnerabilities/troubleshooting-dependabot-errors)."
|
||||
|
||||
{% data variables.product.prodname_dependabot %} 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 ({% data variables.product.prodname_dotcom %} checks for this on every push), or when a new vulnerability is discovered and added to the advisory database.
|
||||
|
||||
### Why don't I get vulnerability alerts for some ecosystems?
|
||||
|
||||
{% data variables.product.prodname_dotcom %} limits its support for vulnerability alerts to a set of ecosystems where we can provide high-quality, actionable data. Curated vulnerabilities in the {% data variables.product.prodname_advisory_database %}, the dependency graph, {% data variables.product.prodname_dependabot_alerts %}, and {% data variables.product.prodname_dependabot %} security updates are provided for several ecosystems, including Java’s Maven, JavaScript’s npm and Yarn, .NET’s NuGet, Python’s pip, Ruby's RubyGems, and PHP’s Composer. We'll continue to add support for more ecosystems over time. For an overview of the package ecosystems that we support, see "[About the dependency graph](/github/visualizing-repository-data-with-graphs/about-the-dependency-graph#supported-package-ecosystems)."
|
||||
|
||||
It's worth noting that [{% data variables.product.prodname_dotcom %} Security Advisories](/github/managing-security-vulnerabilities/about-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.
|
||||
|
||||
**Check**: Does the uncaught vulnerability apply to an unsupported ecosystem?
|
||||
|
||||
### Does the dependency graph only find dependencies in manifests and lockfiles?
|
||||
|
||||
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.
|
||||
|
||||
{% data variables.product.prodname_dependabot_alerts %} advise you about dependencies you should update, including transitive dependencies, where the version can be determined from a manifest or a lockfile. {% data variables.product.prodname_dependabot %} security updates only suggests a change where it 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?
|
||||
|
||||
### Does the dependency graph detect dependencies specified using variables?
|
||||
|
||||
The dependency graph analyzes manifests as they’re pushed to {% data variables.product.prodname_dotcom %}. 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?
|
||||
|
||||
### Are there limits which affect the dependency graph data?
|
||||
|
||||
Yes, the dependency graph has two categories of limits:
|
||||
|
||||
1. **Processing limits**
|
||||
|
||||
These affect the dependency graph displayed within {% data variables.product.prodname_dotcom %} and also prevent {% data variables.product.prodname_dependabot_alerts %} 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 {% data variables.product.prodname_dependabot_alerts %}.
|
||||
|
||||
By default, {% data variables.product.prodname_dotcom %} will not process more than 20 manifests per repository. {% data variables.product.prodname_dependabot_alerts %} are not be created for manifests beyond this limit. If you need to increase the limit, contact {% data variables.contact.contact_support %}.
|
||||
|
||||
2. **Visualization limits**
|
||||
|
||||
These affect what's displayed in the dependency graph within {% data variables.product.prodname_dotcom %}. However, they don't affect the {% data variables.product.prodname_dependabot_alerts %} 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, {% data variables.product.prodname_dependabot_alerts %} are still created for any manifests that are not shown within {% data variables.product.prodname_dotcom %}.
|
||||
|
||||
**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?
|
||||
|
||||
### Does {% data variables.product.prodname_dependabot %} generate alerts for vulnerabilities that have been known for many years?
|
||||
|
||||
The {% data variables.product.prodname_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 {% data variables.product.prodname_advisory_database %}. If there's a specific old vulnerability that you need to be included in the database, contact {% data variables.contact.contact_support %}.
|
||||
|
||||
**Check**: Does the uncaught vulnerability have a publish date earlier than 2017 in the National Vulnerability Database?
|
||||
|
||||
### Why does {% data variables.product.prodname_advisory_database %} use a subset of published vulnerability data?
|
||||
|
||||
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 {% data variables.product.prodname_dependabot %} uses curated data in the {% data variables.product.prodname_advisory_database %}, the volume of alerts may be lower, but the alerts you do receive will be accurate and relevant.
|
||||
|
||||
### Does each dependency vulnerability generate a separate alert?
|
||||
|
||||
When a dependency has multiple vulnerabilities, only one aggregated alert is generated for that dependency, instead of one alert per vulnerability.
|
||||
|
||||
The {% data variables.product.prodname_dependabot_alerts %} count in {% data variables.product.prodname_dotcom %} 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.
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies)"
|
||||
- "[Viewing and updating vulnerable dependencies in your repository](/github/managing-security-vulnerabilities/viewing-and-updating-vulnerable-dependencies-in-your-repository)"
|
||||
- "[Managing security and analysis settings for your repository](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository)"
|
||||
- "[Troubleshooting {% data variables.product.prodname_dependabot %} errors](/github/managing-security-vulnerabilities/troubleshooting-dependabot-errors)"
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
title: Viewing and updating vulnerable dependencies in your repository
|
||||
intro: 'If {% data variables.product.product_name %} discovers vulnerable dependencies in your project, you can view them on the Dependabot alerts tab of your repository. Then, you can update your project to resolve or dismiss the vulnerability.'
|
||||
redirect_from:
|
||||
- /articles/viewing-and-updating-vulnerable-dependencies-in-your-repository
|
||||
permissions: Repository administrators and organization owners can view and update dependencies.
|
||||
shortTitle: Viewing and updating vulnerable dependencies
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
Your repository's {% data variables.product.prodname_dependabot %} alerts tab lists all open and closed {% data variables.product.prodname_dependabot_alerts %} and corresponding {% data variables.product.prodname_dependabot_security_updates %}. You can sort the list of alerts using the drop-down menu, and you can click into specific alerts for more details. For more information, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies)."
|
||||
|
||||
You can enable automatic security updates for any repository that uses {% data variables.product.prodname_dependabot_alerts %} and the dependency graph. For more information, see "[About {% data variables.product.prodname_dependabot_security_updates %}](/github/managing-security-vulnerabilities/about-dependabot-security-updates)."
|
||||
|
||||
{% data reusables.repositories.dependency-review %}
|
||||
|
||||
### About updates for vulnerable dependencies in your repository
|
||||
|
||||
{% data variables.product.product_name %} generates {% data variables.product.prodname_dependabot_alerts %} when we detect that your codebase is using dependencies with known vulnerabilities. For repositories where {% data variables.product.prodname_dependabot_security_updates %} are enabled, when {% data variables.product.product_name %} detects a vulnerable dependency in the default branch, {% data variables.product.prodname_dependabot %} creates a pull request to fix it. The pull request will upgrade the dependency to the minimum possible secure version needed to avoid the vulnerability.
|
||||
|
||||
### Viewing and updating vulnerable dependencies
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
{% data reusables.repositories.sidebar-dependabot-alerts %}
|
||||
1. Click the alert you'd like to view.
|
||||
|
||||
1. Review the details of the vulnerability and, if available, the pull request containing the automated security update.
|
||||
1. Optionally, if there isn't already a {% data variables.product.prodname_dependabot_security_updates %} update for the alert, to create a pull request to resolve the vulnerability, click **Create {% data variables.product.prodname_dependabot %} security update**.
|
||||
|
||||
1. When you're ready to update your dependency and resolve the vulnerability, merge the pull request. Each pull request raised by {% data variables.product.prodname_dependabot %} includes information on commands you can use to control {% data variables.product.prodname_dependabot %}. For more information, see "[Managing pull requests for dependency updates](/github/administering-a-repository/managing-pull-requests-for-dependency-updates#managing-dependabot-pull-requests-with-comment-commands)."
|
||||
1. Optionally, if the alert is being fixed, if it's incorrect, or located in unused code, use the "Dismiss" drop-down, and click a reason for dismissing the alert.
|
||||
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies)"
|
||||
- "[Configuring {% data variables.product.prodname_dependabot_security_updates %}](/github/managing-security-vulnerabilities/configuring-dependabot-security-updates)"
|
||||
- "[Managing security and analysis settings for your repository](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository)"
|
||||
- "[Troubleshooting the detection of vulnerable dependencies](/github/managing-security-vulnerabilities/troubleshooting-the-detection-of-vulnerable-dependencies)"
|
||||
- "[Troubleshooting {% data variables.product.prodname_dependabot %} errors](/github/managing-security-vulnerabilities/troubleshooting-dependabot-errors)"
|
||||
@@ -1,12 +0,0 @@
|
||||
---
|
||||
title: Withdrawing a security advisory
|
||||
intro: You can withdraw a security advisory that you've published.
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
If you publish a security advisory in error, you can withdraw the security advisory by contacting {% data variables.contact.contact_support %}.
|
||||
|
||||
### Further reading
|
||||
|
||||
- [Editing a security advisory](/github/managing-security-vulnerabilities/editing-a-security-advisory)
|
||||
@@ -142,7 +142,7 @@ In this section, you can find the repository permission levels required for secu
|
||||
| [Designate additional people or teams to receive {% data variables.product.prodname_dependabot_alerts %}](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository#granting-access-to-security-alerts) for vulnerable dependencies | | | | | **X** |
|
||||
| Create [security advisories](/github/managing-security-vulnerabilities/about-github-security-advisories) | | | | | **X** |{% endif %}{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" or currentVersion == "github-ae@latest" %}
|
||||
| Manage access to {% data variables.product.prodname_GH_advanced_security %} features (see "[Managing security and analysis settings for your organization](/github/setting-up-and-managing-organizations-and-teams/managing-security-and-analysis-settings-for-your-organization)") | | | | | **X** |{% endif %}{% if currentVersion == "free-pro-team@latest" %}
|
||||
| [Enable the dependency graph](/github/visualizing-repository-data-with-graphs/exploring-the-dependencies-and-dependents-of-a-repository) for a private repository | | | | | **X** |
|
||||
| [Enable the dependency graph](/code-security/supply-chain-security/exploring-the-dependencies-of-a-repository) for a private repository | | | | | **X** |
|
||||
| [View dependency reviews](/github/collaborating-with-issues-and-pull-requests/reviewing-dependency-changes-in-a-pull-request) | **X** | **X** | **X** | **X** | **X** |{% endif %}{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" or currentVersion == "github-ae@latest" %}
|
||||
| [View {% data variables.product.prodname_code_scanning %} alerts on pull requests](/github/finding-security-vulnerabilities-and-errors-in-your-code/triaging-code-scanning-alerts-in-pull-requests) | **X** | **X** | **X** | **X** | **X** |
|
||||
| [List, dismiss, and delete {% data variables.product.prodname_code_scanning %} alerts](/github/finding-security-vulnerabilities-and-errors-in-your-code/managing-code-scanning-alerts-for-your-repository) | | | **X** | **X** | **X** |{% endif %}{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" or currentVersion == 'github-ae@next' %}
|
||||
|
||||
@@ -2,8 +2,7 @@
|
||||
title: About the dependency graph
|
||||
intro: 'Detailed information about the dependency graph, the ecosystems it supports, and how it determines which packages a repository depends on.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
enterprise-server: '<=2.22'
|
||||
---
|
||||
|
||||
### Dependency graph availability
|
||||
@@ -45,7 +44,7 @@ You can use the dependency graph to:
|
||||
|
||||
- Explore the repositories your code depends on{% if currentVersion == "free-pro-team@latest" %}, and those that depend on it{% endif %}. For more information, see "[Exploring the dependencies of a repository](/github/visualizing-repository-data-with-graphs/exploring-the-dependencies-of-a-repository)." {% if currentVersion == "free-pro-team@latest" %}
|
||||
- View a summary of the dependencies used in your organization's repositories in a single dashboard. For more information, see "[Viewing insights for your organization](/articles/viewing-insights-for-your-organization#viewing-organization-dependency-insights)."{% endif %}
|
||||
- View and update vulnerable dependencies for your repository. For more information, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies)."{% if currentVersion == "free-pro-team@latest" %}
|
||||
- View and update vulnerable dependencies for your repository. For more information, see "[About alerts for vulnerable dependencies](/code-security/supply-chain-security/about-alerts-for-vulnerable-dependencies)."{% if currentVersion == "free-pro-team@latest" %}
|
||||
- See information about vulnerable dependencies in pull requests. For more information, see "[Reviewing dependency changes in a pull request](/github/collaborating-with-issues-and-pull-requests/reviewing-dependency-changes-in-a-pull-request)."{% endif %}
|
||||
|
||||
### Enabling the dependency graph
|
||||
|
||||
@@ -8,8 +8,7 @@ redirect_from:
|
||||
- /github/visualizing-repository-data-with-graphs/listing-the-projects-that-depend-on-a-repository
|
||||
- /github/visualizing-repository-data-with-graphs/exploring-the-dependencies-and-dependents-of-a-repository
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
enterprise-server: '<=2.22'
|
||||
---
|
||||
|
||||
### Viewing the dependency graph
|
||||
|
||||
@@ -25,5 +25,6 @@ versions:
|
||||
{% topic_link_in_list /understanding-connections-between-repositories %}
|
||||
{% link_in_list /viewing-a-repositorys-network %}
|
||||
{% link_in_list /listing-the-forks-of-a-repository %}
|
||||
{% link_in_list /about-the-dependency-graph %}
|
||||
{% link_in_list /exploring-the-dependencies-of-a-repository %}
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}{% link_in_list /viewing-the-dependencies-of-a-repository %}{% endif %}
|
||||
{% if currentVersion ver_lt "enterprise-server@3.0" %}{% link_in_list /about-the-dependency-graph %}
|
||||
{% link_in_list /exploring-the-dependencies-of-a-repository %}{% endif %}
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: Viewing the dependencies of a repository
|
||||
intro: 'You can use the dependency graph to explore the code your repository depends on.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=3.0'
|
||||
---
|
||||
|
||||
Almost all software relies on code developed and maintained by other developers, often known as a supply chain. For example, utilities, libraries, and frameworks. These dependencies are an integral part of your code and any bugs or vulnerabilities in them may affect your code. It's important to review and maintain these dependencies.
|
||||
|
||||
The dependency graph provides a great way to visualize and explore the dependencies for a repository. For more information, see "[About the dependency graph](/code-security/supply-chain-security/about-the-dependency-graph)" and "[Exploring the dependencies of a repository](/code-security/supply-chain-security/exploring-the-dependencies-of-a-repository)."
|
||||
|
||||
You can also set up your repository so that {% data variables.product.company_short %} alerts you automatically whenever a security vulnerability is found in one of your dependencies. For more information, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies)."
|
||||
Reference in New Issue
Block a user