Skip to main content

이 버전의 GitHub Enterprise는 다음 날짜에 중단되었습니다. 2024-03-26. 중요한 보안 문제에 대해서도 패치 릴리스가 이루어지지 않습니다. 더 뛰어난 성능, 향상된 보안, 새로운 기능을 위해 최신 버전의 GitHub Enterprise Server로 업그레이드합니다. 업그레이드에 대한 도움말은 GitHub Enterprise 지원에 문의하세요.

코드 검사 경고 정보

다양한 유형의 코드 검사 경고 및 각 경고가 강조 표시하는 문제를 이해하는 데 도움이 되는 정보에 대해 알아봅니다.

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

Code scanning는 GitHub Enterprise Server의 조직 소유 리포지토리에서 사용할 수 있습니다. 이 기능을 사용하려면 GitHub Advanced Security에 대한 라이선스가 필요합니다. 자세한 내용은 "GitHub Advanced Security 정보.

Note: Your site administrator must enable code scanning for your GitHub Enterprise Server instance before you can use this feature. For more information, see "Configuring code scanning for your appliance."

You may not be able to enable or disable code scanning if an enterprise owner has set a GitHub Advanced Security (GHAS) policy at the enterprise level. For more information, see "Enforcing policies for code security and analysis for your enterprise."

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 code scanning."

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."

You can audit the actions taken in response to code scanning alerts using GitHub tools. For more information, see "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.

The status and details on the alert page only reflect the state of the alert on the default branch of the repository, even if the alert exists in other branches. You can see the status of the alert on non-default branches in the Affected branches section on the right-hand side of the alert page. If an alert doesn't exist in the default branch, the status of the alert will display as "in pull request" or "in branch" and will be colored grey.

Screenshot showing the elements of a code scanning alert, including the title of the alert and relevant lines of code at left and the severity level, affected branches, and weaknesses at right.

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.

About analysis origins

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 is the analysis origin for all the alerts it generates. For example, an alert generated using the default CodeQL analysis with GitHub Actions will have a different analysis origin from 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 with multiple analysis origins. If an alert has more than one analysis origin, a icon will appear next to any relevant branch in the Affected branches section on the right-hand side of the alert page. You can hover over the icon to see the names of each analysis origin and the status of the alert for that analysis origin. You can also view the history of when alerts appeared in each analysis origin in the timeline on the alert page. If an alert only has one analysis origin, no information about analysis origins is displayed on the alert page.

Screenshot showing a code scanning alert with multiple analysis origins.

Note: Sometimes a code scanning alert displays as fixed for one analysis origin but is still open for a second analysis origin. You can resolve this by re-running the second code scanning configuration to update the alert status for that analysis origin.

About labels for alerts that are not found in application code

GitHub Enterprise Server 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.

Screenshot of an alert in the code scanning list. To the right of the title, a "Test" label is highlighted with a dark orange outline.

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

Screenshot showing the details of an alert. The file path and "Test" label are highlighted with a dark orange outline.

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.

Pull request check failures for code scanning alerts

When you enable code scanning on pull requests the check fails only if one or more alerts of severity error, or security severity critical or high are detected. The check will succeed if alerts with lower severities or security severities are detected. For important codebases, you may want the code scanning check to fail if any alerts are detected, so that the alert must be fixed or dismissed before the code change is merged. For more information about severity levels, see "About alert severity and security severity levels."

You can edit which severity and security severity alert levels cause a check failure. For more information, see "Customizing code scanning."

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.