Observação: O administrador do site deve habilitar Varredura de código para your GitHub Enterprise Server instance antes de usar este recurso. Se você desejar usar o GitHub Actions para fazer a varredura do seu código, o administrador do site também deverá habilitar o GitHub Actions e configurar a infraestrutura necessária. Para obter mais informações, consulte "Configurar o Varredura de código para seu aplicativo ".
Note: This article describes the features available with the version of the CodeQL action and associated CodeQL CLI bundle included in the initial release of this version of GitHub Enterprise Server. If your enterprise uses a more recent version of the CodeQL action, see the GitHub Enterprise Cloud article for information on the latest features. For information on using the latest version, see "Configuring code scanning for your appliance."
About Varredura de código configuration
You can run Varredura de código on GitHub Enterprise Server, using GitHub Actions, or from your continuous integration (CI) system. For more information, see "About GitHub Actions" or "About CodeQL Varredura de código in your CI system."
This article is about running Varredura de código on GitHub Enterprise Server using actions.
Before you can configure Varredura de código for a repository, you must set up Varredura de código by adding a GitHub Actions workflow to the repository. For more information, see "Setting up Varredura de código for a repository."
Typically, you don't need to edit the default workflow for Varredura de código. However, if required, you can edit the workflow to customize some of the settings. For example, you can edit GitHub's Fluxo de trabalho de análise do CodeQL to specify the frequency of scans, the languages or directories to scan, and what CodeQL Varredura de código looks for in your code. You might also need to edit the Fluxo de trabalho de análise do CodeQL if you use a specific set of commands to compile your code.
CodeQL analysis is just one type of Varredura de código you can do in GitHub. GitHub Marketplace on GitHub.com contains other Varredura de código workflows you can use. The specific examples given in this article relate to the Fluxo de trabalho de análise do CodeQL file.
Editing a Varredura de código workflow
GitHub saves workflow files in the .github/workflows directory of your repository. You can find a workflow you have added by searching for its file name. For example, by default, the workflow file for CodeQL Varredura de código is called codeql-analysis.yml.
- In your repository, browse to the workflow file you want to edit.
- In the upper right corner of the file view, to open the workflow editor, click .
- After you have edited the file, click Start commit and complete the "Commit changes" form. You can choose to commit directly to the current branch, or create a new branch and start a pull request.
For more information about editing workflow files, see "Learn GitHub Actions."
Configuring frequency
You can configure the Fluxo de trabalho de análise do CodeQL to scan code on a schedule or when specific events occur in a repository.
Scanning code when someone pushes a change, and whenever a pull request is created, prevents developers from introducing new vulnerabilities and errors into the code. Scanning code on a schedule informs you about the latest vulnerabilities and errors that GitHub, security researchers, and the community discover, even when developers aren't actively maintaining the repository.
Scanning on push
By default, the Fluxo de trabalho de análise do CodeQL uses the on.push
event to trigger a code scan on every push to the default branch of the repository and any protected branches. For Varredura de código to be triggered on a specified branch, the workflow must exist in that branch. For more information, see "Workflow syntax for GitHub Actions."
If you scan on push, then the results appear in the Security tab for your repository. For more information, see "Managing code scanning alerts for your repository."
Scanning pull requests
The default Fluxo de trabalho de análise do CodeQL uses the pull_request
event to trigger a code scan on pull requests targeted against the default branch. The pull_request
event is not triggered if the pull request was opened from a private fork.
For more information about the pull_request
event, see "Events that trigger workflows."
If you scan pull requests, then the results appear as alerts in a pull request check. For more information, see "Triaging code scanning alerts in pull requests."
Avoiding unnecessary scans of pull requests
You might want to avoid a code scan being triggered on specific pull requests targeted against the default branch, irrespective of which files have been changed. You can configure this by specifying on:pull_request:paths-ignore
or on:pull_request:paths
in the Varredura de código workflow. For example, if the only changes in a pull request are to files with the file extensions .md
or .txt
you can use the following paths-ignore
array.
on:
push:
branches: [main, protected]
pull_request:
branches: [main]
paths-ignore:
- '**/*.md'
- '**/*.txt'
Notes
on:pull_request:paths-ignore
andon:pull_request:paths
set conditions that determine whether the actions in the workflow will run on a pull request. They don't determine what files will be analyzed when the actions are run. When a pull request contains any files that are not matched byon:pull_request:paths-ignore
oron:pull_request:paths
, the workflow runs the actions and scans all of the files changed in the pull request, including those matched byon:pull_request:paths-ignore
oron:pull_request:paths
, unless the files have been excluded. For information on how to exclude files from analysis, see "Specifying directories to scan."- For CodeQL Varredura de código workflow files, don't use the
paths-ignore
orpaths
keywords with theon:push
event as this is likely to cause missing analyses. For accurate results, CodeQL Varredura de código needs to be able to compare new changes with the analysis of the previous commit.
For more information about using on:pull_request:paths-ignore
and on:pull_request:paths
to determine when a workflow will run for a pull request, see "Workflow syntax for GitHub Actions."
Scanning on a schedule
If you use the default Fluxo de trabalho de análise do CodeQL, the workflow will scan the code in your repository once a week, in addition to the scans triggered by events. To adjust this schedule, edit the cron
value in the workflow. For more information, see "Workflow syntax for GitHub Actions."
Note: GitHub only runs scheduled jobs that are in workflows on the default branch. Changing the schedule in a workflow on any other branch has no effect until you merge the branch into the default branch.
Example
The following example shows a Fluxo de trabalho de análise do CodeQL for a particular repository that has a default branch called main
and one protected branch called protected
.
on:
push:
branches: [main, protected]
pull_request:
branches: [main]
schedule:
- cron: '20 14 * * 1'
This workflow scans:
- Every push to the default branch and the protected branch
- Every pull request to the default branch
- The default branch every Monday at 14:20 UTC
Specifying an operating system
If your code requires a specific operating system to compile, you can configure the operating system in your Fluxo de trabalho de análise do CodeQL. Edit the value of jobs.analyze.runs-on
to specify the operating system for the machine that runs your Varredura de código actions. You specify the operating system by using an appropriate label as the second element in a two-element array, after self-hosted
.
jobs:
analyze:
name: Analyze
runs-on: [self-hosted, ubuntu-latest]
CodeQL Varredura de código supports the latest versions of Ubuntu, Windows, and macOS. Typical values for this setting are therefore: ubuntu-latest
, windows-latest
, and macos-latest
. For more information, see "Workflow syntax for GitHub Actions" and "Using labels with self-hosted runners."
You must ensure that Git is in the PATH variable on your self-hosted runners.
For more information, see "About self-hosted runners" and "Adding self-hosted runners."
For recommended specifications (RAM, CPU cores, and disk) for running CodeQL analysis, see "Recommended hardware resources for running CodeQL."
Changing the languages that are analyzed
CodeQL Varredura de código automatically detects code written in the supported languages.
- C/C++
- C#
- Go
- Java
- JavaScript/TypeScript
- Python
The default Fluxo de trabalho de análise do CodeQL file contains a build matrix called language
which lists the languages in your repository that are analyzed. CodeQL automatically populates this matrix when you add Varredura de código to a repository. Using the language
matrix optimizes CodeQL to run each analysis in parallel. We recommend that all workflows adopt this configuration due to the performance benefits of parallelizing builds. For more information about build matrices, see "Managing complex workflows."
Se o seu repositório contiver código em mais de uma das linguagens compatíveis, você poderá escolher quais linguagens deseja analisar. Há vários motivos para impedir que uma linguagem seja analisada. Por exemplo, o projeto pode ter dependências em uma linguagem diferente do texto principal do seu código, e você pode preferir não ver os alertas para essas dependências.
If your workflow uses the language
matrix then CodeQL is hardcoded to analyze only the languages in the matrix. To change the languages you want to analyze, edit the value of the matrix variable. You can remove a language to prevent it being analyzed or you can add a language that was not present in the repository when Varredura de código was set up. For example, if the repository initially only contained JavaScript when Varredura de código was set up, and you later added Python code, you will need to add python
to the matrix.
jobs:
analyze:
name: Analyze
...
strategy:
fail-fast: false
matrix:
language: ['javascript', 'python']
If your workflow does not contain a matrix called language
, then CodeQL is configured to run analysis sequentially. If you don't specify languages in the workflow, CodeQL automatically detects, and attempts to analyze, any supported languages in the repository. If you want to choose which languages to analyze, without using a matrix, you can use the languages
parameter under the init
action.
- uses: github/codeql-action/init@v1
with:
languages: cpp, csharp, python
Running additional queries
Ao usar CodeQL para fazer a varredura do código, o mecanismo de análise de CodeQL gera um banco de dados do código e executa consultas no mesmo. A análise de CodeQL usa um conjunto-padrão de consultas, mas você pode especificar outras consultas a serem executadas, além das consultas-padrão.
Any additional queries you want to run must belong to a QL pack in a repository. For more information, see "About Varredura de código with CodeQL."
Você pode especificar um único arquivo .ql, um diretório que contém múltiplos arquivos .ql, um arquivo de definição de suite de consultas .qls ou qualquer outra combinação. Para obter mais informações sobre definições do conjunto de consultas, consulte "Criar as conjuntos de consulta do CodeQL".
To add one or more queries, add a with: queries:
entry within the uses: github/codeql-action/init@v1
section of the workflow. If the queries are in a private repository, use the external-repository-token
parameter to specify a token that has access to checkout the private repository.
- uses: github/codeql-action/init@v1
with:
queries: COMMA-SEPARATED LIST OF PATHS
# Optional. Provide a token to access queries stored in private repositories.
external-repository-token: ${{ secrets.ACCESS_TOKEN }}
You can also specify query suites in the value of queries
. Query suites are collections of queries, usually grouped by purpose or language.
Os conjuntos de consulta a seguir foram criados em CodeQL Varredura de código e estão disponíveis para uso.
Suite de consulta | Descrição |
---|---|
security-extended | Consultas de menor gravidade e precisão que as consultas-padrão |
security-and-quality | Consultas de security-extended , mais consultas de manutenção e confiabilidade |
When you specify a query suite, the CodeQL analysis engine will run the default set of queries and any extra queries defined in the additional query suite.
If you also use a configuration file for custom settings, any additional queries specified in your workflow are used instead of those specified in the configuration file. If you want to run the combined set of additional queries, prefix the value of queries
in the workflow with the +
symbol. For more information, see "Using a custom configuration file."
In the following example, the +
symbol ensures that the specified additional queries are used together with any specified in the referenced configuration file.
- uses: github/codeql-action/init@v1
with:
config-file: ./.github/codeql/codeql-config.yml
queries: +security-and-quality,octo-org/python-qlpack/show_ifs.ql@main
Using a custom configuration file
A custom configuration file is an alternative way to specify additional queries to run. You can also use the file to disable the default queries and to specify which directories to scan during analysis.
In the workflow file, use the config-file
parameter of the init
action to specify the path to the configuration file you want to use. This example loads the configuration file ./.github/codeql/codeql-config.yml.
- uses: github/codeql-action/init@v1
with:
config-file: ./.github/codeql/codeql-config.yml
O arquivo de configuração pode ser localizado no repositório que você está analisando ou em um repositório externo. O uso de um repositório externo permite especificar opções de configuração para vários repositórios em um único lugar. Ao fazer referência a um arquivo de configuração localizado em um repositório externo, você pode usar a sintaxe OWNER/REPOSITORY/FILENAME@BRANCH. Por exemplo, octo-org/shared/codeql-config.yml@main.
If the configuration file is located in an external private repository, use the external-repository-token
parameter of the init
action to specify a token that has access to the private repository.
- uses: github/codeql-action/init@v1
with:
external-repository-token: ${{ secrets.ACCESS_TOKEN }}
The settings in the configuration file are written in YAML format.
Specifying additional queries
You specify additional queries in a queries
array. Each element of the array contains a uses
parameter with a value that identifies a single query file, a directory containing query files, or a query suite definition file.
queries:
- uses: ./my-basic-queries/example-query.ql
- uses: ./my-advanced-queries
- uses: ./query-suites/my-security-queries.qls
Optionally, you can give each array element a name, as shown in the example configuration files below. For more information about additional queries, see "Running additional queries" above.
Disabling the default queries
If you only want to run custom queries, you can disable the default security queries by using disable-default-queries: true
.
Specifying directories to scan
For the interpreted languages that CodeQL supports (Python and JavaScript/TypeScript), you can restrict Varredura de código to files in specific directories by adding a paths
array to the configuration file. You can exclude the files in specific directories from analysis by adding a paths-ignore
array.
paths:
- src
paths-ignore:
- src/node_modules
- '**/*.test.js'
Note:
- The
paths
andpaths-ignore
keywords, used in the context of the Varredura de código configuration file, should not be confused with the same keywords when used foron.<push|pull_request>.paths
in a workflow. When they are used to modifyon.<push|pull_request>
in a workflow, they determine whether the actions will be run when someone modifies code in the specified directories. For more information, see "Workflow syntax for GitHub Actions." - The filter pattern characters
?
,+
,[
,]
, and!
are not supported and will be matched literally. **
characters can only be at the start or end of a line, or surrounded by slashes, and you can't mix**
and other characters. For example,foo/**
,**/foo
, andfoo/**/bar
are all allowed syntax, but**foo
isn't. However you can use single stars along with other characters, as shown in the example. You'll need to quote anything that contains a*
character.
For compiled languages, if you want to limit Varredura de código to specific directories in your project, you must specify appropriate build steps in the workflow. The commands you need to use to exclude a directory from the build will depend on your build system. For more information, see "Configuring the CodeQL workflow for compiled languages."
You can quickly analyze small portions of a monorepo when you modify code in specific directories. You'll need to both exclude directories in your build steps and use the paths-ignore
and paths
keywords for on.<push|pull_request>
in your workflow.
Example configuration files
Este arquivo de configuração adiciona o suite de consulta de security-and-quality
para a lista de consultas executadas por CodeQL ao fazer a varredura do seu código. Para obter mais informações sobre o suite de consultas disponível para uso, consulte "Executar consultas adicionais".
name: "My CodeQL config"
queries:
- uses: security-and-quality
O seguinte arquivo de configuração desabilita as consultas-padrão e especifica um conjunto de consultas personalizadas para serem executadas. Também configura CodeQL para fazer a varredura de arquivos no diretório src (relativo � raiz), exceto o diretório src/node_modules e os arquivos cujo nome termina com .test.js. Os arquivos em src/node_modules e arquivos com nomes terminados em .test.js são, portanto, excluídos da análise.
name: "My CodeQL config"
disable-default-queries: true
queries:
- name: Use an in-repository QL pack (run queries in the my-queries directory)
uses: ./my-queries
- name: Use an external JavaScript QL pack (run queries from an external repo)
uses: octo-org/javascript-qlpack@main
- name: Use an external query (run a single query from an external QL pack)
uses: octo-org/python-qlpack/show_ifs.ql@main
- name: Use a query suite file (run queries from a query suite in this repo)
uses: ./codeql-qlpacks/complex-python-qlpack/rootAndBar.qls
paths:
- src
paths-ignore:
- src/node_modules
- '**/*.test.js'
Configuring Varredura de código for compiled languages
Para as linguagens compiladas compatíveis, você pode usar a ação autobuild
no Fluxo de trabalho de análise do CodeQL para criar o seu código. Isso evita que você tenha que especificar comandos de criação explícitos para C/C++, C#, e Java. CodeQL também executa uma criação para projetos Go para configurar o projeto. Entretanto, diferente das outras linguagens compiladas, todos os Go no repositório são extraídos, não apenas aqueles construídos. Você pode usar comandos de criação personalizados para ignorar arquivos de Go de extração que não são tocados pela compilação.
Se o código de C/C++, C#, ou Java no seu repositório tiver um processo de criação não padrão, poderá ocorrer uma falha no autobuild
. Você deverá remover a etapa autobuild
do fluxo de trabalho e adicionar manualmente etapas de criação. Se você quiser especificar quais arquivos de Go no seu repositório devem ser extraídos, você deverá adicionar as etapas de criação. For more information about how to configure CodeQL Varredura de código for compiled languages, see "Configuring the CodeQL workflow for compiled languages."
Uploading Varredura de código data to GitHub
GitHub can display code analysis data generated externally by a third-party tool. You can upload code analysis data with the upload-sarif
action. For more information, see "Uploading a SARIF file to GitHub."