Managing code scanning alerts for your repository

From the security view, you can view, fix, dismiss, or delete alerts for potential vulnerabilities or errors in your project's code.

If you have write permission to a repository you can manage Varredura de código alerts for that repository.

Varredura de código está disponível para todos os repositórios públicos e para repositórios privados pertencentes a organizações em que Segurança Avançada GitHub está habilitado. Para obter mais informações, consulte "Sobre Segurança Avançada GitHub".

About alerts from Varredura de código

You can set up Varredura de código 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 "Setting up Varredura de código for a repository."

By default, Varredura de código analyzes your code periodically on the default branch and during pull requests. For information about managing alerts on a pull request, see "Triaging Varredura de código alerts in pull requests."

Notas:

  • SARIF upload supports a maximum of 5000 results per upload. Todos os resultados acima deste limite são ignorados. Se uma ferramenta gerar muitos resultados, você deverá atualizar a configuração para focar nos resultados para as regras ou consultas mais importantes.

  • For each upload, SARIF upload supports a maximum size of 10 MB for the gzip-compressed SARIF file. Any uploads over this limit will be rejected. If your SARIF file is too large because it contains too many results, you should update the configuration to focus on results for the most important rules or queries.

About alerts 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 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.

Example alert from Varredura de código

If you set up Varredura de código using CodeQL, this can also detect 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 Varredura de código reports data-flow alerts, GitHub shows you how data moves through the code. Varredura de código 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 severity levels

Alert severity levels may be Error, Warning, or Note.

By default, any code scanning results with a severity of error will cause check failure. You can specify the severity level at which pull requests that trigger code scanning alerts should fail. For more information, see "Defining the severities causing pull request check failure."

About security severity levels

Varredura de código displays security severity levels for alerts that are generated by security queries. Security severity levels can be Critical, High, Medium, or Low.

To calculate the security severity of an alert, we use Common Vulnerability Scoring System (CVSS) data. CVSS is an open framework for communicating the characteristics and severity of software vulnerabilities, and is commonly used by other security products to score alerts. For more information about how severity levels are calculated, see the blog post.

By default, any code scanning results with a security severity of Critical or High will cause a check failure. You can specify which security severity level for code scanning results should cause a check failure. For more information, see "Defining the severities causing pull request check failure."

About labels for alerts that are not found in application code

GitHub 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

Varredura de código categorizes files by file path. You cannot manually categorize source files.

Here is an example from the Varredura de código alert list of an alert marked as occuring in library code.

Code scanning library alert in list

On the alert page, you can see that the filepath is marked as library code (Library label).

Code scanning library alert details

Viewing the alerts for a repository

Anyone with read permission for a repository can see Varredura de código annotations on pull requests. For more information, see "Triaging Varredura de código alerts in pull requests."

You need write permission to view a summary of all the alerts for a repository on the Security tab.

By default, the code scanning alerts page is filtered to show alerts for the default branch of the repository only.

  1. No GitHub.com, navegue até a página principal do repositório.

  2. No seu nome de repositório, clique em Segurança. Guia de segurança

  3. Na barra lateral esquerda, clique em alertas de varredura de código. Aba de "Alertas de varredura de código"

  4. Optionally, use the free text search box or the drop-down menus to filter alerts. For example, you can filter by the tool that was used to identify alerts. Filter by tool

  5. Em "Varredura de código", clique no alerta que você gostaria de explorar.

    Summary of alerts

  6. Optionally, if the alert highlights a problem with data flow, click Show paths to display the path from the data source to the sink where it's used. The "Show paths" link on an alert

  7. Alerts from CodeQL analysis include a description of the problem. Click Show more for guidance on how to fix your code. Details for an alert

Note: For Varredura de código analysis with CodeQL, you can see information about the latest run in a header at the top of the list of Varredura de código alerts for the repository.

For example, you can see when the last scan ran, the number of lines of code analyzed compared to the total number of lines of code in your repository, and the total number of alerts that were generated. UI banner

Filtering Varredura de código alerts

You can filter the alerts shown in the Varredura de código alerts view. This is useful if there are many alerts as you can focus on a particular type of alert. There are some predefined filters and a range of keywords that you can use to refine the list of alerts displayed.

  • To use a predefined filter, click Filters, or a filter shown in the header of the list of alerts, and choose a filter from the drop-down list. Predefined filters
  • To use a keyword, either type directly in the filters text box, or:
    1. Click in the filters text box to show a list of all available filter keywords.
    2. Click the keyword you want to use and then choose a value from the drop-down list. Keyword filters list

The benefit of using keyword filters is that only values with results are shown in the drop-down lists. This makes it easy to avoid setting filters that find no results.

If you enter multiple filters, the view will show alerts matching all these filters. For example, is:closed severity:high branch:main will only display closed high-severity alerts that are present on the main branch. The exception is filters relating to refs (ref, branch and pr): is:open branch:main branch:next will show you open alerts from both the main branch and the next branch.

Restricting results to application code only

You can use the "Only alerts in application code" filter or autofilter:true keyword and value to restrict results to alerts in application code. See "About labels for alerts not in application code" above for more information about the types of code that are not application code.

Searching Varredura de código alerts

You can search the list of alerts. This is useful if there is a large number of alerts in your repository, or if you don't know the exact name for an alert for example. GitHub performs the free text search across:

  • The name of the alert

  • The alert description

  • The alert details (this also includes the information hidden from view by default in the Show more collapsible section)

    The alert information used in searches

Supported searchSyntax exampleResults
Single word searchinjectionReturns all the alerts containing the word injection
Multiple word searchsql injectionReturns all the alerts containing sql or injection
Exact match search
(use double quotes)
"sql injection"Returns all the alerts containing the exact phrase sql injection
OR searchsql OR injectionReturns all the alerts containing sql or injection
AND searchsql AND injectionReturns all the alerts containing both words sql and injection

Tips:

  • The multiple word search is equivalent to an OR search.
  • The AND search will return results where the search terms are found anywhere, in any order in the alert name, description, or details.
  1. No GitHub.com, navegue até a página principal do repositório.
  2. No seu nome de repositório, clique em Segurança. Guia de segurança
  3. Na barra lateral esquerda, clique em alertas de varredura de código. Aba de "Alertas de varredura de código"
  4. To the right of the Filters drop-down menus, type the keywords to search for in the free text search box. The free text search box
  5. Press return. The alert listing will contain the open Varredura de código alerts matching your search criteria.

Tracking Varredura de código alerts in issues

Note: The tracking of Varredura de código alerts in issues is in beta and subject to change.

This feature supports running analysis natively using GitHub Actions or externally using existing CI/CD infrastructure, as well as third-party Varredura de código tools, but not third-party tracking tools.

Varredura de código alerts integrate with task lists in Problemas do GitHub to make it easy for you to prioritize and track alerts with all your development work. Para obter mais informações sobre os problemas, consulte "Sobre os problemas".

To track a code scanning alert in an issue, add the URL for the alert as a task list item in the issue. For more information about task lists, see "About tasks lists."

For more information about creating issues to track Varredura de código alerts, see "Tracking Varredura de código alerts in issues using task lists."

Fixing an alert

Anyone with write permission for a repository can fix an alert by committing a correction to the code. If the repository has Varredura de código scheduled to run on pull requests, it's best to raise a pull request with your correction. This will trigger Varredura de código analysis of the changes and test that your fix doesn't introduce any new problems. For more information, see "Configuring Varredura de código" and "Triaging Varredura de código alerts in pull requests."

If you have write permission for a repository, you can view fixed alerts by viewing the summary of alerts and clicking Closed. For more information, see "Viewing the alerts for a repository." The "Closed" list shows fixed alerts and alerts that users have dismissed.

You can use the free text search or the filters to display a subset of alerts and then in turn mark all matching alerts as closed.

Alerts may be fixed in one branch but not in another. You can use the "Branch" drop-down menu, on the summary of alerts, to check whether an alert is fixed in a particular branch.

Filtering alerts by branch

Dismissing or deleting alerts

There are two ways of closing an alert. You can fix the problem in the code, or you can dismiss the alert. Alternatively, if you have admin permissions for the repository, you can delete alerts. Deleting alerts is useful in situations where you have set up a Varredura de código tool and then decided to remove it, or where you have configured CodeQL analysis with a larger set of queries than you want to continue using, and you've then removed some queries from the tool. In both cases, deleting alerts allows you to clean up your Varredura de código results. You can delete alerts from the summary list within the Security tab.

Dismissing an alert is a way of closing an alert that you don't think needs to be fixed. Por exemplo, um erro no código que é usado apenas para testes ou quando o esforço de corrigir o erro é maior do que o benefício potencial de melhorar o código. You can dismiss alerts from Varredura de código annotations in code, or from the summary list within the Security tab.

When you dismiss an alert:

  • It's dismissed in all branches.
  • The alert is removed from the number of current alerts for your project.
  • The alert is moved to the "Closed" list in the summary of alerts, from where you can reopen it, if required.
  • The reason why you closed the alert is recorded.
  • Next time Varredura de código runs, the same code won't generate an alert.

When you delete an alert:

  • It's deleted in all branches.
  • The alert is removed from the number of current alerts for your project.
  • It is not added to the "Closed" list in the summary of alerts.
  • If the code that generated the alert stays the same, and the same Varredura de código tool runs again without any configuration changes, the alert will be shown again in your analysis results.

To dismiss or delete alerts:

  1. No GitHub.com, navegue até a página principal do repositório.

  2. No seu nome de repositório, clique em Segurança. Guia de segurança

  3. Na barra lateral esquerda, clique em alertas de varredura de código. Aba de "Alertas de varredura de código"

  4. If you have admin permissions for the repository, and you want to delete alerts for this Varredura de código tool, select some or all of the check boxes and click Delete.

    Deleting alerts

    Optionally, you can use the free text search or the filters to display a subset of alerts and then delete all matching alerts at once. For example, if you have removed a query from CodeQL analysis, you can use the "Rule" filter to list just the alerts for that query and then select and delete all of those alerts.

    Filter alerts by rule

  5. If you want to dismiss an alert, it's important to explore the alert first, so that you can choose the correct dismissal reason. Click the alert you'd like to explore.

    Open an alert from the summary list

  6. Review the alert, then click Dismiss and choose a reason for closing the alert. Choosing a reason for dismissing an alert

    É importante escolher o motivo apropriado no menu suspenso, pois isso pode afetar se uma consulta continua sendo incluída em análise futura.

    Se você ignorar um alerta de CodeQL como um falso resultado positivo, por exemplo, porque o código usa uma biblioteca de sanitização incompatível, considere contribuir para o repositório de CodeQL e melhorar a análise. Para obter mais informações sobre CodeQL, consulte "Contribuir para CodeQL".

Dismissing multiple alerts at once

If a project has multiple alerts that you want to dismiss for the same reason, you can bulk dismiss them from the summary of alerts. Typically, you'll want to filter the list and then dismiss all of the matching alerts. For example, you might want to dismiss all of the current alerts in the project that have been tagged for a particular Common Weakness Enumeration (CWE) vulnerability.

Further reading

Esse documento ajudou você?

Política de Privacidade

Ajude-nos a tornar esses documentos ótimos!

Todos os documentos do GitHub são de código aberto. Você percebeu que algo que está errado ou não está claro? Envie um pull request.

Faça uma contribuição

Ou, aprenda como contribuir.