Skip to main content

Triaging code scanning alerts in pull requests

When escaneo de código identifies a problem in a pull request, you can review the highlighted code and resolve the alert.

If you have read permission for a repository, you can see annotations on pull requests. With write permission, you can see detailed information and resolve escaneo de código alerts for that repository.

El Escaneo de código está disponible para todos los repositorios públicos en GitHub.com. Para utilizar el escaneo de código en un repositorio privado que le pertenezca a una organización, debes tener una licencia para GitHub Advanced Security. Para obtener más información, consulta "Productos de GitHub".

About escaneo de código results on pull requests

In repositories where escaneo de código is configured as a pull request check, escaneo de código 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 escaneo de código alerts to the target branch, the alerts are reported in multiple places.

  • 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

If you have write permission for the repository, you can see any existing escaneo de código alerts on the Security tab. For information about repository alerts, see "Managing escaneo de código alerts for your repository."

In repositories where escaneo de código is configured to scan each time code is pushed, escaneo de código 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 escaneo de código, and the repository owner has configured required status checks, then the "Escaneo de código results" check must pass before you can merge the pull request. For more information, see "About protected branches."

About escaneo de código as a pull request check

There are many options for configuring escaneo de código as a pull request check, so the exact setup of each repository will vary and some will have more than one check.

Escaneo de código results check

For all configurations of escaneo de código, the check that contains the results of escaneo de código is: Escaneo de código 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."

Escaneo de código results check on a pull request

Escaneo de código results check failures

If the escaneo de código 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 escaneo de código have lower severities, the alerts are treated as warnings or notes and the check succeeds.

Failed escaneo de código check on a pull request

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

Other escaneo de código checks

Depending on your configuration, you may see additional checks running on pull requests with escaneo de código configured. These are usually workflows that analyze the code or that upload escaneo de código results. These checks are useful for troubleshooting when there are problems with the analysis.

For example, if the repository uses the Flujo de trabajo de análisis de 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 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 escaneo de código" or "Troubleshooting the CodeQL workflow."

Viewing an alert on your pull request

You can see any escaneo de código alerts introduced in a pull request by viewing the Conversation tab. Escaneo de código 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.

Alert annotation within a pull request Conversations tab

You can also view all escaneo de código alerts in the Files changed tab of the pull request. Existing escaneo de código alerts on a file that are outside the diff of the changes introduced in the pull request will only appear in the Files changed tab.

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.

El estado y los detalles en la página de alerta solo reflejan el estado de la misma en la rama predeterminada del repositorio, incluso si dicha alerta existe en otras ramas. Puedes ver el estado de la alerta en ramas que no sean la predeterminada en la sección Ramas afectadas a la derecha de la página de alertas. Si una alerta no existe en la rama predeterminada, su estado se mostrará como "en la solicitud de cambios" o "en la rama" y se marcará de color gris.

In the detailed view for an alert, some escaneo de código tools, like CodeQL analysis, also include a description of the problem and a Show more link for guidance on how to fix your code.

Alert description and link to show more information

Commenting on an alert in a pull request

You can comment on any escaneo de código alert introduced by the changes 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 only comment on alerts introduced by the changes in a pull request. Existing escaneo de código alerts, on files that are outside the changes introduced in the pull request, will appear in the Files changed tab but cannot be commented on.

You can choose to require all conversations in a pull request, including those on escaneo de código alerts, to be resolved before a pull request can be merged. For more information, see "About protected branches."

Fixing an alert on your pull request

Anyone with push access to a pull request can fix a escaneo de código 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. Por ejemplo, un error en el código que se utiliza únicamente para hacer pruebas, o cuando el esfuerzo de areglar el error es mayor que el beneficio potencial de mejorar el código. 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.

Screenshot of code scanning alert with dropdown to choose dismissal reason emphasized

Es importante elegir la razón adecuada del menú desplegable, ya que esto puede afectar si la consulta continuará incluyéndose en los análisis futuros. Opcionalmente, puedes comentar en un rechazo para registrar el contexto del rechazo de una alerta. El comentario de rechazo se agrega a la línea de tiempo de la alerta y puede utilizarse como justificación durante los reportes y auditorías. Puedes recuperar o establecer un comentario utilizando la API de REST del escaneo de código. El comentario se contiene en dismissed_comment para la terminal alerts/{alert_number}. Para obtener más información, consulta la sección "Escaneo de código".

Si descartas una alerta de CodeQL como consecuencia de un resultado de falso positivo, por ejemplo, porque el código utiliza una biblioteca de sanitización que no es compatible, considera contribuir con el repositorio de CodeQL y mejorar el análisis. Para obtener más información acerca de CodeQL, consulta la sección "Contribuir con CodeQL".

For more information about dismissing alerts, see "Managing escaneo de código alerts for your repository."