Code scanning alerts

About alerts from code scanning

You can configure code scanning to check the code in a repository using the default CodeQL analysis, a third-party analysis, or multiple types of analysis. When the analysis is complete, the resulting alerts are displayed alongside each other in the security view of the repository. Results from third-party tools or from custom queries may not include all of the properties that you see for alerts detected by GitHub's default CodeQL analysis. For more information, see Configuring default setup for code scanning and 配置代码扫描的高级设置.

By default, code scanning analyzes your code periodically on the default branch and during pull requests. For information about managing alerts on a pull request, see Triaging code scanning alerts in pull requests.

For code scanning alerts from CodeQL analysis, you can use security overview to see how CodeQL is performing in pull requests in repositories across your organization, and to identify repositories where you may need to take action. For more information, see CodeQL 拉取请求警报指标.

可以使用 code scanning 工具审核为响应GitHub警报而执行的操作。 有关详细信息，请参阅“Auditing security alerts”。

About alert details

Each alert highlights a problem with the code and the name of the tool that identified it. You can see the line of code that triggered the alert, as well as properties of the alert, such as the alert severity, security severity, and the nature of the problem. Alerts also tell you when the issue was first introduced. For alerts identified by CodeQL analysis, you will also see information on how to fix the problem.

警报页面上的状态和详细信息仅反映存储库默认分支上的警报状态，即使警报存在于其他分支中也是如此。 可以在警报页右侧的“受影响的分支”部分查看非默认分支上的警报状态。 如果默认分支中不存在警报，则警报的状态将显示为“在拉取请求中”或“在分支中”，并将变为灰色。 “开发”部分显示将修复警报的链接分支和拉取请求。****

If you configure code scanning using CodeQL, you can also find data-flow problems in your code. Data-flow analysis finds potential security issues in code, such as: using data insecurely, passing dangerous arguments to functions, and leaking sensitive information.

When code scanning reports data-flow alerts, GitHub shows you how data moves through the code. Code scanning allows you to identify the areas of your code that leak sensitive information, and that could be the entry point for attacks by malicious users.

In some cases, the same vulnerability can be reached through multiple code paths, for example, when several different functions pass user input to the same unsafe operation. Code scanning groups these related paths under a single alert rather than creating separate alerts for each path, so you can see the full scope of the vulnerability in one place.

About alerts from multiple configurations

You can run multiple configurations of code analysis on a repository, using different tools and targeting different languages or areas of the code. Each configuration of code scanning generates a unique set of alerts. For example, an alert generated using the default CodeQL analysis with GitHub Actions comes from a different configuration than an alert generated externally and uploaded via the code scanning API.

If you use multiple configurations to analyze a file, any problems detected by the same query are reported as alerts generated by multiple configurations. If an alert exists in more than one configuration, the number of configurations appears next to the branch name in the "Affected branches" section on the right-hand side of the alert page. To view the configurations for an alert, in the "Affected branches" section, click a branch. A "Configurations analyzing" modal appears with the names of each configuration generating the alert for that branch. Below each configuration, you can see when that configuration's alert was last updated.

An alert may display different statuses from different configurations. To update the alert statuses, re-run each out-of-date configuration. Alternatively, you can delete stale configurations from a branch to remove outdated alerts. For more information on deleting stale configurations and alerts, see Resolving code scanning alerts.

About labels for alerts that are not found in application code

GitHub assigns a category label to alerts that are not found in application code. The label relates to the location of the alert.

• Generated: Code generated by the build process
• Test: Test code
• Library: Library or third-party code
• Documentation: Documentation

Code scanning categorizes files by file path. You cannot manually categorize source files.

In this example, an alert is marked as in "Test" code in the code scanning alert list.

When you click through to see details for the alert, you can see that the file path is marked as "Test" code.

About alert severity and security severity levels

The severity level for a code scanning alert indicates how much risk the problem adds to your codebase.

• Severity. All code scanning alerts have a level of Error, Warning, or Note.
• Security severity. Each security alert found using CodeQL also has a security severity level of Critical, High, Medium, or Low.

When an alert has a security severity level, code scanning displays and uses this level in preference to the severity. Security severity levels follow the industry-standard Common Vulnerability Scoring System (CVSS) that is also used for advisories in the GitHub Advisory Database. For more information, see CVSS: Qualitative Severity Rating Scale.

Calculation of security severity levels

When a security query is added to the CodeQL Default or Extended query suite, the CodeQL engineering team calculates the security severity as follows.

1. Search for all CVEs that are assigned one or more of the CWE tags associated with the new security query.
2. Calculate the 75th percentile of the CVSS score for those CVEs.
3. Define that score as the security severity for the query.
4. When displaying alerts found by the query, translate the numerical scores to Critical, High, Medium, or Low using the CVSS definitions.

For more information, see CodeQL CWE coverage on the CodeQL documentation site.

About alerts in pull requests

Code scanning alerts can appear on pull requests as check results and annotations. This happens in repositories where code scanning either:

• Is configured as a pull request check (by default, this is limited to pull requests that target the default branch)
• Is configured to scan each time code is pushed (the results are mapped to any open pull requests)

You will only see an alert in a pull request if all the lines of code identified by the alert exist in the pull request diff.

Depending on branch protection rules, the "Code scanning results" check may be a required check that prevents pull requests from being merged until it passes.