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
Hinweis
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.
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 Anpassen des erweiterten Setups für das Codescanning.
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 Informationen zu geschützten Branches.
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.
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.
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 Anpassen des erweiterten Setups für das Codescanning.
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-Analyseworkflow 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 (public preview), und 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 Anpassen des erweiterten Setups für das Codescanning or Problembehandlung bei Analysefehlern.
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.
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.
Der Status und die Details auf der Warnungsseite spiegeln nur den Status der Warnung für den Standardbranch des Repositorys wider, auch wenn die Warnung in anderen Branches vorhanden ist. Du kannst den Status der Warnung für nicht standardmäßigen Branches im Abschnitt Betroffene Branches rechts auf der Warnungsseite sehen. Wenn eine Warnung im Standardbranch nicht vorhanden ist, wird der Status der Warnung als „in Pull Request“ oder „in Branch“ in grau angezeigt. Im Abschnitt Development werden verknüpfte Branches und Pull Requests angezeigt, die die Warnung beheben.
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.
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 Informationen zu geschützten Branches.
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.
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. Beispielsweise liegt ein Fehler in Code vor, der nur zum Testen verwendet wird, oder der Aufwand zum Beheben des Fehlers ist höher als der potenzielle Vorteil der Verbesserung des Codes. 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.
Es ist wichtig, den entsprechenden Grund aus dem Dropdownmenü auszuwählen, weil sich dies darauf auswirken kann, ob eine Abfrage weiterhin in zukünftigen Analysen berücksichtigt wird. Optional können Sie die Zurückweisung kommentieren, um den Kontext der Zurückweisung einer Warnung aufzuzeichnen. Der Kommentar zur Zurückweisung wird zur Zeitleiste der Warnung hinzugefügt und kann bei Prüfungen und Berichterstellungen als Begründung verwendet werden. Du kannst einen Kommentar über die REST-API für die Codeüberprüfung abrufen oder festlegen. Der Kommentar ist in dismissed_comment für den Endpunkt alerts/{alert_number} enthalten. Weitere Informationen finden Sie unter REST-API-Endpunkte für die Codeüberprüfung.
Wenn du eine CodeQL-Warnung als False Positive-Ergebnis schließt, z. B. weil der Code eine nicht unterstützte Bereinigungsbibliothek verwendet, solltest du zum CodeQL-Repository beitragen und die Analyse verbessern. Weitere Informationen zu CodeQL findest du unter Beitragen zu CodeQL.
For more information about dismissing alerts, see Resolving code scanning alerts.