Skip to main content

Triaging code scanning alerts in pull requests

When code scanning identifies a problem in a pull request, you can review the highlighted code and resolve the alert.

누가 이 기능을 사용할 수 있나요?

읽기 권한이 있는 사용자

About code scanning results on pull requests

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 the lines of code changed in the pull request generate code scanning alerts, the alerts are reported in the following places on the pull request.

  • Check results in the pull request
  • The Conversation tab of the pull request, as part of a pull request review
  • The Files changed tab of the pull request

참고 항목

Code scanning displays alerts in pull requests only when all the lines of code identified by the alert exist in the pull request diff. For more information, see SARIF support for code scanning.

GitHub Copilot Autofix will suggest fixes for alerts from code scanning analysis (including CodeQL analysis) in private repositories. For more information on working with suggestions from 코파일럿 자동 수정 in pull requests, see Working with 코파일럿 자동 수정 suggestions for alerts on a 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 Assessing 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 코드 검색을 위한 고급 설정 사용자 지정.

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 code scanning as a pull request check

There are many options for configuring code scanning as a pull request check, so the exact configuration of each repository will vary and some will have more than one check.

Code scanning results 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 on lines of code changed 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 Assessing code scanning alerts for your repository.

Screenshot of the Code scanning results check on a pull request. The "View all branch alerts" link is highlighted with a dark orange outline.

Code scanning results check failures

If the code scanning results check finds any problems with a severity of error, critical, or 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.

Screenshot of the merge box for a pull request. The "Code scanning results / CodeQL" check has "1 new alert including 1 high severity security v..."

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 코드 검색을 위한 고급 설정 사용자 지정.

Other code scanning checks

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 분석 워크플로 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 compiles (for example, C/C++, C#, Go, Java, Kotlin, Rust, 및 Swift).

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 코드 검색을 위한 고급 설정 사용자 지정 or 분석 오류 문제 해결.

Viewing an alert on your pull request

You can see any code scanning alerts that are inside the diff of the changes introduced in a pull request by viewing the Conversation tab. Code scanning posts a pull request review that shows each alert as an annotation on the lines of code that triggered the alert. You can comment on the alerts, dismiss the alerts, and view paths for the alerts, directly from the annotations. You can view the full details of an alert by clicking the "Show more details" link, which will take you to the alert details page.

Screenshot of an alert annotation on the "Conversations" tab of a pull request. The "Show more details" link is outlined in dark orange.

You can also view all code scanning alerts that are inside the diff of the changes introduced in the pull request in the Files changed tab.

If you add a new code scanning configuration in your pull request, you will see a comment on your pull request directing you to the Security tab of the repository so you can view all the alerts on the pull request branch. For more information about viewing the alerts for a repository, see Assessing code scanning alerts for your repository.

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.

경고 페이지에 있는 상태와 세부 정보는 경고가 다른 분기에 있는 경우에도 리포지토리의 기본 분기에 있는 경고의 상태만 반영합니다. 경고 페이지의 오른쪽에 있는 영향받는 분기 섹션에서 기본 분기가 아닌 분기에 대한 경고 상태를 볼 수 있습니다. 경고가 기본 분기에 없는 경우 경고 상태가 "끌어오기 요청 내" 또는 "분기 내"로 표시되고 회색으로 표시됩니다. Development 섹션에서는 경고를 수정할 연결된 분기 및 끌어오기 요청을 보여 줍니다.

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.

Screenshot showing the description for a code scanning alert. A link labeled "Show more" is highlighted with a dark orange outline.

Commenting on an alert in a pull request

You can comment on any code scanning alert that appears in a pull request. Alerts appear as annotations in the Conversation tab of a pull request, as part of a pull request review, and also are shown in the Files changed tab.

You can choose to require all conversations in a pull request, including those on code scanning alerts, to be resolved before a pull request can be merged. For more information, see 보호된 분기 정보.

Fixing an alert on your pull request

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.

Working with 코파일럿 자동 수정 suggestions for alerts on a pull request

GitHub Copilot Autofix is an expansion of code scanning that provides you with targeted recommendations to help you fix code scanning alerts (including CodeQL alerts) in pull requests. The potential fixes are generated automatically by large language models (LLMs) using data from the codebase, the pull request, and from code scanning analysis.

참고 항목

GitHub Copilot Autofix를 사용하기 위해 GitHub Copilot을 구독할 필요는 없습니다. 코파일럿 자동 수정는 GitHub.com의 모든 퍼블릭 리포지토리와 GitHub Code Security 라이선스가 있는 조직 및 엔터프라이즈가 소유한 내부 또는 프라이빗 리포지토리에서 사용할 수 있습니다.

Screenshot of the check failure for a code scanning alert in a pull request. Part of the "autofix" suggestion is outlined in dark orange.

Generating 코파일럿 자동 수정 suggestions and publishing to a pull request

When 코파일럿 자동 수정 is enabled for a repository, alerts are displayed in pull requests as normal and information from any alerts found by code scanning is automatically sent to the LLM for processing. When LLM analysis is complete, any results are published as comments on relevant alerts. For more information, see 코드 검사에 대한 Copilot Autofix의 책임 있는 사용.

참고 항목

  • 코파일럿 자동 수정 supports a subset of CodeQL queries. For information about the availability of 코파일럿 자동 수정, see the query tables linked from Queries for CodeQL analysis.
  • When analysis is complete, all relevant results are published to the pull request at once. If at least one alert in your pull request has an 코파일럿 자동 수정 suggestion, you should assume that the LLM has finished identifying potential fixes for your code.
  • On alerts generated from queries that are not supported by 코파일럿 자동 수정, you will see a note telling you that the query is not supported. If a suggestion for a supported query fails to generate, you will see a note on the alert prompting you to try pushing another commit or to contact support.
  • 코파일럿 자동 수정 for code scanning alerts won't be able to generate a fix for every alert in every situation. The feature operates on a best-effort basis and is not guaranteed to succeed 100% of the time. For information about the limitations of automatically generated fixes, see Limitations of suggestions.

Usually, when you suggest changes to a pull request, your comment contains changes for a single file that is changed in the pull request. The following screenshot shows an 코파일럿 자동 수정 comment that suggests changes to the index.js file where the alert is displayed. Since the potential fix requires a new dependency on escape-html, the comment also suggests adding this dependency to the package.json file, even though the original pull request makes no changes to this file.

Screenshot of 코파일럿 자동 수정 suggestion to edit the current file. A suggested change in "package.json" is outlined in dark orange.

Assessing and committing an 코파일럿 자동 수정 suggestion

Each 코파일럿 자동 수정 suggestion demonstrates a potential solution for a code scanning alert in your codebase. You must assess the suggested changes to determine whether they are a good solution for your codebase and to ensure that they maintain the intended behavior. For information about the limitations of 코파일럿 자동 수정 suggestions, see Limitations of suggestions and Mitigating the limitations of suggestions in "Responsible use of 코파일럿 자동 수정 for code scanning."

  1. Click Edit to display the editing options and select your preferred method.
    • Under Edit with GitHub CLI, follow the instructions for checking out the pull request locally and applying the suggested fix.
    • Select Edit FILENAME to edit the file directly on GitHub with the suggested fix applied.
  2. Optionally, if you prefer to apply the fix on a local repository or branch, select the dropdown menu on the suggestion.
    • Select View autofix patch to display instructions for applying the suggested fix to any local repository or branch.
    • Select Copy modified line LINE_NUMBER to copy a specific line of the suggestion.
  3. Test and modify the suggested fix as needed.
  4. When you have finished testing your changes, commit the changes, and push them to your branch.
  5. Pushing the changes to your branch will trigger all the usual tests for your pull request. Confirm that your unit tests still pass and that the code scanning alert is now fixed.

Dismissing a 코파일럿 자동 수정 suggestion

If you decide to reject a 코파일럿 자동 수정 suggestion, click Dismiss suggestion in the comment to dismiss the suggested fix.

Dismissing an alert on your pull request

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, a Dismiss alert button is available in code annotations and in the alerts summary. When you click Dismiss alert you will be prompted to choose a reason for closing the alert.

Screenshot of a check failure for code scanning. The "Dismiss alert" button is highlighted in dark orange. The "Dismiss alert" drop-down is shown.

쿼리가 향후 분석에 계속 포함될지 여부에 영향을 줄 수 있으므로 드롭다운 메뉴에서 적절한 이유를 선택하는 것이 중요합니다. 선택적으로 해제에 대한 주석을 달아 경고 해제의 컨텍스트를 기록할 수 있습니다. 해제 주석은 경고 타임라인에 추가되며 감사 및 보고 중에 근거로 사용할 수 있습니다. REST API를 검색하는 코드를 사용하여 주석을 검색하거나 설정할 수 있습니다. 주석은 alerts/{alert_number} 엔드포인트에 대한 dismissed_comment에 포함되어 있습니다. 자세한 내용은 코드 검색에 대한 REST API 엔드포인트을(를) 참조하세요.

예를 들어 코드에서 지원되지 않는 삭제 라이브러리를 사용하기 때문에 CodeQL 경고를 가양성 결과로 해제하는 경우 CodeQL 리포지토리에 기여하고 분석을 개선하는 것이 좋습니다. CodeQL에 대한 자세한 내용은 CodeQL에 기여를 참조하세요.

For more information about dismissing alerts, see Resolving code scanning alerts.