In repositories where code scanning is configured as a pull request check, code scanning checks the code in the pull request. By default, this is limited to pull requests that target the default branch, but you can change this configuration within GitHub Actions or in a third-party CI/CD system. If merging the changes would introduce new code scanning alerts to the target branch, the alerts are reported in multiple places.
- Check results in the pull request
- The Files changed tab of the pull request
If you have write permission for the repository, you can see any existing code scanning alerts on the Security tab. For information about repository alerts, see "Managing code scanning alerts for your repository."
In repositories where code scanning is configured to scan each time code is pushed, code scanning will also map the results to any open pull requests and add the alerts as annotations in the same places as other pull request checks. For more information, see "Scanning on push."
If your pull request targets a protected branch that uses code scanning, and the repository owner has configured required status checks, then the "Code scanning results" check must pass before you can merge the pull request. For more information, see "About protected branches."
There are many options for configuring code scanning as a pull request check, so the exact setup of each repository will vary and some will have more than one check.
For all configurations of code scanning, the check that contains the results of code scanning is: Code scanning results. The results for each analysis tool used are shown separately. Any new alerts caused by changes in the pull request are shown as annotations.
To see the full set of alerts for the analyzed branch, click View all branch alerts. This opens the full alert view where you can filter all the alerts on the branch by type, severity, tag, etc. For more information, see "Managing code scanning alerts for your repository."
If the code scanning results check finds any problems with a severity of
high, the check fails and the error is reported in the check results. If all the results found by code scanning have lower severities, the alerts are treated as warnings or notes and the check succeeds.
You can override the default behavior in your repository settings, by specifying the level of severities and security severities that will cause a pull request check failure. For more information, see "Defining the severities causing pull request check failure".
Depending on your configuration, you may see additional checks running on pull requests with code scanning configured. These are usually workflows that analyze the code or that upload code scanning results. These checks are useful for troubleshooting when there are problems with the analysis.
For example, if the repository uses the CodeQL analysis workflow a CodeQL / Analyze (LANGUAGE) check is run for each language before the results check runs. The analysis check may fail if there are configuration problems, or if the pull request breaks the build for a language that the analysis needs to compile (for example, C/C++, C#, or Java).
As with other pull request checks, you can see full details of the check failure on the Checks tab. For more information about configuring and troubleshooting, see "Configuring code scanning" or "Troubleshooting the CodeQL workflow."
You can see any code scanning alerts introduced in a pull request by displaying the Files changed tab. Each alert is shown as an annotation on the lines of code that triggered the alert. The severity of the alert is displayed in the annotation.
If you have write permission for the repository, some annotations contain links with extra context for the alert. In the example above, from CodeQL analysis, you can click user-provided value to see where the untrusted data enters the data flow (this is referred to as the source). In this case you can also view the full path from the source to the code that uses the data (the sink) by clicking Show paths. This makes it easy to check whether the data is untrusted or if the analysis failed to recognize a data sanitization step between the source and the sink. For information about analyzing data flow using CodeQL, see "About data flow analysis."
To see more information about an alert, users with write permission can click the Show more details link shown in the annotation. This allows you to see all of the context and metadata provided by the tool in an alert view. In the example below, you can see tags showing the severity, type, and relevant common weakness enumerations (CWEs) for the problem. The view also shows which commit introduced the problem.
警报页面上的状态和详细信息仅反映存储库默认分支上的警报状态，即使警报存在于其他分支中也是如此。 可以在警报页右侧的“受影响的分支”部分查看非默认分支上的警报状态。 如果默认分支中不存在警报，则警报的状态将显示为“在拉取请求中”或“在分支中”，并将变为灰色。
In the detailed view for an alert, some code scanning tools, like CodeQL analysis, also include a description of the problem and a Show more link for guidance on how to fix your code.
Anyone with push access to a pull request can fix a code scanning alert that's identified on that pull request. If you commit changes to the pull request this triggers a new run of the pull request checks. If your changes fix the problem, the alert is closed and the annotation removed.
An alternative way of closing an alert is to dismiss it. You can dismiss an alert if you don't think it needs to be fixed. 例如，仅用于测试的代码中有错误，或者修复错误的工作超过改进代码的潜在益处。 If you have write permission for the repository, the Dismiss button is available in code annotations and in the alerts summary. When you click Dismiss you will be prompted to choose a reason for closing the alert.
从下拉菜单中选择合适的原因很重要，因为这可能会影响到是否继续将查询纳入未来的分析。 （可选）可对关闭操作进行注释，记录警报关闭情况的上下文。 关闭操作注释将添加到警报时间线，可在审核和报告期间用作理由。 可使用代码扫描 REST API 检索或设置注释。 注释包含在
dismissed_comment 中。 有关详细信息，请参阅“代码扫描”。
如果将 CodeQL 警报作为误报予以忽略，例如因为代码使用了不受支持的清理库，请考虑参与 CodeQL 存储库并改进分析。 有关 CodeQL 的详细信息，请参阅“参与 CodeQL”。
For more information about dismissing alerts, see "Managing code scanning alerts for your repository."