Configurar a varredura do código

Sobre a configuração do Varredura de código

Você pode executar Varredura de código em GitHub, usando GitHub Actions ou a partir do seu sistema de integração contínua (CI). Para obter mais informações, consulte "Sobre GitHub Actions" ou "Sobre CodeQL Varredura de código no seu sistema de CI".

Este artigo é sobre a execução de Varredura de código em GitHub usando ações.

Antes de poder configurar o Varredura de código para um repositório, você deve configurar Varredura de código adicionando um fluxo de trabalho do GitHub Actions ao repositório. Para obter mais informações, consulte "Configurar Varredura de código para um repositório".

De modo geral, você não precisa editar o fluxo de trabalho padrão para Varredura de código. No entanto, se necessário, você editar o fluxo de trabalho para personalizar algumas das configurações. Por exemplo, você pode editar os Fluxo de trabalho de análise do CodeQL de GitHub para especificar a frequência das digitalizações, as linguagens ou diretórios a serem digitalizados e o que CodeQL Varredura de código procura no seu código. Talvez você precise editar o Fluxo de trabalho de análise do CodeQL se você usar um conjunto específico de comandos para compilar seu código.

A análise de CodeQL é apenas um tipo de Varredura de código que você pode fazer em GitHub. GitHub Marketplace contém outros fluxos de trabalho de Varredura de código que você pode usar. Você pode encontrar uma seleção destes na página "Comece com Varredura de código", que você pode acessar na aba Segurança. Os exemplos específicos fornecidos neste artigo estão relacionados ao arquivo de Fluxo de trabalho de análise do CodeQL.

Editing a code scanning workflow

O GitHub salva arquivos de fluxo de trabalho no diretório .github/workflows do seu repositório. Você pode encontrar um fluxo de trabalho que você adicionou procurando o nome do seu arquivo. For example, the default workflow file for CodeQL code scanning is called codeql-analysis.yml.

1. No seu repositório, pesquise o arquivo do fluxo de trabalho que você deseja editar.
2. No canto superior direito da vista do arquivo, clique em para abrir o editor do fluxo de trabalho.
3. Depois de ter editado o arquivo, clique em Iniciar commit e preencha o formulário "Alterações do commit". Você pode escolher o "commit" diretamente no branch atual ou criar um novo branch e iniciar um pull request.

Para obter mais informações sobre a edição de arquivos do fluxo de trabalho, consulte "Aprenda GitHub Actions".

Configurar a frequência

Você pode fazer a varredura de código de forma pré-programada ou quando ocorrerem eventos específicos em um repositório.

A varredura do código a cada push para o repositório, e toda vez que um pull request é criado, isso impede que os desenvolvedores introduzam novas vulnerabilidades e erros no código. A varredura do código de forma pré-programada informa as últimas vulnerabilidades e erros de GitHub, que os pesquisadores de segurança e da comunidade, mesmo quando desenvolvedores não estão mantendo o repositório de forma ativa.

Fazer a varredura no push

Se você usar o fluxo de trabalho padrão, o Varredura de código fará a varredura do código no repositório uma vez por semana, além das varreduras acionadas pelos eventos. Para ajustar essa programação, edite o valor CRON no fluxo de trabalho. Para obter mais informações, consulte "Sintaxe de fluxo de trabalho para o GitHub Actions".

Se você fizer uma varredura no push, os resultados aparecerão na aba Segurança do repositório. Para obter mais informações, consulte "Gerenciar alertas de varredura de código para seu repositório. "

Além disso, quando uma verificação de on:push retorna resultados que podem ser mapeados com um pull request aberto, esses alertas serão automaticamente exibidos no pull request nos mesmos lugares que outros alertas de pull request. Os alertas são identificados comparando a análise existente do cabeçalho do branch com a análise do branch de destino. Para obter mais informações sobre alertas de Varredura de código em pull requests, consulte "Triando alertas de Varredura de código em pull requests".

Fazer a varredura de pull requests

O padrão Fluxo de trabalho de análise do CodeQL usa o evento pull_request para acionar uma verificação de código em pull requests direcionadas ao branch padrão. Se um pull request for de um fork privado, o evento pull_request só será acionado se você tiver selecionado a opção "Executar fluxos de trabalho a partir de pull requests" nas configurações do repositório. Para obter mais informações, consulte "Gerenciar configurações de GitHub Actions para um repositório".

Para obter mais informações sobre o evento pull_request , consulte "Sintaxe de fluxo de trabalho para GitHub Actions".

Se você realizar uma varredura de pull requests, os resultados aparecerão como alertas em uma verificação de pull request. Para obter mais informações, consulte "Alertas de varredura de código de triagem em pull requests".

O uso o gatilho pull_request, configurado para verificar o commit de merge do pull request, em vez do commit do cabeçalho, produzirá resultados mais eficientes e precisos do que digitalizar o cabeçalho do branch em cada push. No entanto, se você usa um sistema de CI/CD que não pode ser configurado para acionar em pull requests, você ainda poderá usar o gatilho on:push e Varredura de código mapeará os resultados para abrir os pull requests no branch e adicionar os alertas como anotações no pull request. Para obter mais informações, consulte "Digitalizando ao enviar por push".

Definindo as severidades que causam falha na verificação de pull request

Por padrão, apenas os alertas com o nível de gravidade Error ou nível de segurança Critical ou High farão com que ocorra uma falha no pull request e uma verificação será bem-sucedida com alertas de menor gravidade. É possível alterar os níveis de gravide dos alertas e de gravidades de segurança que causarão uma falha de verificação de pull request nas configurações do seu repositório. Para obter mais informações sobre os níveis de gravidade, consulte "Gerenciar alertas de digitalização de códigos para o seu repositório.

1. No GitHub.com, navegue até a página principal do repositório.
2. No nome do seu repositório, clique em Configurações.
3. Na barra lateral esquerda, clique em Security & analysis (Segurança e análise).
4. Em "Varredura de código", à direita de "Verificar falha", use o menu suspenso para selecionar o nível de gravidade que você gostaria de fazer com que um pull request falhasse.

Evitar varreduras desnecessárias de pull requests

Você pode querer evitar que uma varredura de código seja acionada em pull requests específicos para o branch padrão, Independentemente de os arquivos terem sido alterados. Você pode configurar isso, especificando no:pull_request:paths-ignore ou on:pull_request:paths no fluxo de trabalho de Varredura de código. Por exemplo, se as únicas alterações em um pull request são para arquivos com extensões de arquivo .md ou .txt, você poderá usar o seguinte array paths-ignore.

on:
  push:
    branches: [main, protected]
  pull_request:
    branches: [main]
    paths-ignore:
      - '**/*.md'
      - '**/*.txt'

Para mais informações sobre como usar on:pull_request:paths-ignore e on:pull_request:paths para determinar quando um fluxo de trabalho será executado para um pull request, consulte "sintaxe de fluxo de trabalho para GitHub Actions".

Fazer a varredura de forma pré-programada

O fluxo de trabalho padrão do Varredura de código usa o evento on.push para acionar uma varredura de código em cada push para qualquer branch que contém o arquivo de fluxo de trabalho. Para ajustar essa programação, edite o valor CRON no fluxo de trabalho. Para obter mais informações, consulte "Sintaxe de fluxo de trabalho para o GitHub Actions".

Exemplo

O exemplo a seguir mostra um Fluxo de trabalho de análise do CodeQL para um repositório em particular que possui um branch-padrão denominado principal e um branch protegido denominado protegido.

on:
  push:
    branches: [main, protected]
  pull_request:
    branches: [main]
  schedule:
    - cron: '20 14 * * 1'

Este fluxo de trabalho faz a varredura:

• Cada push para o branch-padrão e o branch protegido
• Cada pull request para o branch-padrão
• O branch padrão toda segunda-feira às 14h20 UTC

Especificar um sistema operacional

Se seu código exigir um sistema operacional específico para compilar, você poderá configurar o sistema operacional em seu Fluxo de trabalho de análise do CodeQL. Edite o valor de jobs.analyze.runs-on para especificar o sistema operacional para a máquina que executa suas ações de Varredura de código.

Se você optar por usar um executor auto-hospedado para varredura de código, você pode especificar um sistema operacional usando uma etiqueta apropriada como segundo elemento em um array de dois elementos, após auto-hospedado.

jobs:
  analyze:
    name: Analyze
    runs-on: [self-hosted, ubuntu-latest]

Para obter mais informações, consulte "Sobre executores auto-hospedados" e "Adicionar executores auto-hospedados."

O Varredura de código é compatível com as versões mais recentes do macOS, Ubuntu, e Windows. Portanto, os valores típicos para essa configuração são ubuntu-latest, windows-latest e macos-latest. Para obter mais informações, consulte "Sintaxe de fluxo de trabalho para o GitHub Actions."

Se você usa um executor auto-hospedado, você deve garantir que o Git esteja na variável de PATH.

Especificar o local para bancos de dados de CodeQL

Em geral você não precisa se preocupar com o lugar em que Fluxo de trabalho de análise do CodeQL coloca bancos de dados de CodeQL, uma vez que as etapas posteriores encontrarão automaticamente bancos de dados criados nas etapas anteriores. No entanto, se estiver escrevendo um fluxo de trabalho personalizado que exige que o banco de dados de CodeQL esteja em um local específico do disco, por exemplo, para fazer o upload do banco de dados como um artefato de fluxo de trabalho você pode especificar essa localização usando o parâmetro db-location na ação init.

- uses: github/codeql-action/init@v1
  with:
    db-location: '${{ github.workspace }}/codeql_dbs'

O Fluxo de trabalho de análise do CodeQL esperará que o caminho fornecido no db-location tenha permissão de gravação, e não exista ou seja um diretório vazio. Ao usar este parâmetro em um trabalho em execução em um executor auto-hospedado ou usando um contêiner Docker, é responsabilidade do usuário garantir que o diretório escolhido seja limpo entre execuções, ou que os bancos de dados sejam removidos depois de deixarem de ser necessários. This is not necessary for jobs running on GitHub-hosted runners, which obtain a fresh instance and a clean filesystem each time they run. For more information, see "About GitHub-hosted runners."

Se este parâmetro não for usado, o Fluxo de trabalho de análise do CodeQL criará bancos de dados em um local temporário da sua própria escolha.

Alterar as linguagens que são analisadas

O CodeQL Varredura de código detecta automaticamente código escrito nas linguagens compatíveis.

• C/C++
• C#
• Go
• Java
• JavaScript/TypeScript
• Python
• Ruby

For more information, see the documentation on the CodeQL website: "Supported languages and frameworks."

O arquivo padrão do Fluxo de trabalho de análise do CodeQL contém uma matriz de criação denominada linguagem que lista as linguagens no seu repositório que são analisadas. O CodeQL preenche automaticamente esta matriz quando você adiciona o Varredura de código a um repositório. Usar a matriz de linguagem otimiza CodeQL para executar cada análise em paralelo. Recomendamos que todos os fluxos de trabalho adotem esta configuração devido aos benefícios de desempenho de criações paralelas. Para obter mais informações sobre matrizes de criação, consulte "Gerenciar fluxos de trabalho complexos".

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.

Se o seu fluxo de trabalho usar a matriz de linguagem , o CodeQL será codificado para analisar apenas as linguagens da matriz. Para alterar as linguagens que você deseja analisar, edite o valor da variável da matriz. Você pode remover uma linguagem para evitar que ele seja analisado ou adicionar uma linguagem que não estava presente no repositório quando o Varredura de código estava configurado. Por exemplo, se o repositório inicialmente continha apenas JavaScript quando Varredura de código foi configurado e, posteriormente, você adicionou o código Python, você precisará adicionar o <code>python à matriz.

jobs:
  analyze:
    name: Analyze
    ...
    strategy:
      fail-fast: false
      matrix:
        language: ['javascript', 'python']

Se o seu fluxo de trabalho não contiver uma matriz denominada linguagem, o CodeQL será configurado para executar a análise sequencialmente. Se você não especificar as linguagens no fluxo de trabalho, o CodeQL irá detectar automaticamente e tentará analisar quaisquer linguagens compatíveis no repositório. Se você quiser escolher quais linguagens analisar sem usar uma matriz, você poderá usar o parâmetro linguagens na ação init.

- uses: github/codeql-action/init@v1
  with:
    languages: cpp, csharp, python

Analisar as dependências do Python

Para executores hospedados no GitHub, que usam apenas Linux, o Fluxo de trabalho de análise do CodeQL tentará instalar automaticamente as dependências do Python para dar mais resultados para a análise do CodeQL. Você pode controlar este comportamento especificando o parâmetro setup-python-dependencies para a ação chamada pela etapa "Initialize CodeQL". Por padrão, esse parâmetro é definido como verdadeiro:

• Se o repositório contiver código escrito em Python, a etapa "Initialize CodeQL" instalará as dependências necessárias no executor hospedado pelo GitHub. Se a instalação automática for bem-sucedida, a ação também definirá a variável de ambiente CODEQL_PYTHON para o arquivo Python executável que inclui as dependências.

• Se o repositório não tiver dependências do Python ou se as dependências forem especificadas de forma inesperada, você receberá um aviso e a ação continuará com os trabalhos restantes. A ação pode ser executada com sucesso, mesmo quando houver problemas de interpretação de dependências, mas os resultados podem estar incompletos.

Alternativamente, você pode instalar as dependências do Python manualmente em qualquer sistema operacional. Você precisará adicionar as setup-python-dependencies e definir como falso, além de definir CODEQL_PYTHON como o executável do Python que inclui as dependências, conforme mostrado neste trecho do fluxo de trabalho:

jobs:
  CodeQL-Build:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
      actions: read

    steps:
      - name: Checkout repository
        uses: actions/checkout@v2
      - name: Set up Python
        uses: actions/setup-python@v2
        with:
          python-version: '3.x'
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          if [ -f requirements.txt ];
          then pip install -r requirements.txt;
          fi
          # Set the `CODEQL-PYTHON` environment variable to the Python executable
          # that includes the dependencies
          echo "CODEQL_PYTHON=$(which python)" >> $GITHUB_ENV
      - name: Initialize CodeQL
        uses: github/codeql-action/init@v1
        with:
          languages: python
          # Override the default behavior so that the action doesn't attempt
          # to auto-install Python dependencies
          setup-python-dependencies: false

Configurar uma categoria para a análise

Use a categoria para distinguir entre múltiplas análises para a mesma ferramenta e commit, mas executada em diferentes linguagens ou diferentes partes do código. A categoria especificada no seu fluxo de trabalho será incluída no arquivo de resultados SARIF.

Esse parâmetro é particularmente útil se você trabalhar com monorepos e tiver vários arquivos SARIF para diferentes componentes do monorepo.

    - name: Perform CodeQL Analysis
      uses: github/codeql-action/analyze
      with:
        # Optional. Specify a category to distinguish between multiple analyses
        # for the same tool and ref. If you don't use `category` in your workflow, 
        # GitHub will generate a default category name for you
        category: "my_category"

Se você não especificar um parâmetro da categoria no seu fluxo de trabalho, GitHub irá gerar um nome de categoria para você, com base no nome do arquivo de fluxo de trabalho que ativa a ação, o nome da ação e todas as variáveis de matrizes. Por exemplo:

• O fluxo de trabalho .github/workflows/codeql-analyis.yml e a ação analyze produzirão a categoria .github/workflows/codeql.yml:analyze.
• O fluxo de trabalho .github/workflows/codeql-analyis.yml, a ação analyze e as variáveis da matriz {language: javascript, os: linux} irão produzir a categoria .github/workflows/codeql-analyis.yml:analyze/language:javascript/os:linux.

A categoria será exibida como a propriedade <run>.automationDetails.id no SARIF v2.1.0. Para obter mais informações, consulte "Suporte SARIF para Varredura de código".

Sua categoria especificada não substituirá os detalhes do objeto runAutomationDetails no arquivo SARIF, se incluído.

Executar consultas adicionais

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.

You can run extra queries if they are part of a CodeQL pack (beta) published to the GitHub Container registry or a QL pack stored in a repository. For more information, see "About Varredura de código with CodeQL."

The options available to specify the additional queries you want to run are:

• packs to install one or more CodeQL query packs (beta) and run the default query suite or queries for those packs.
• queries to specify a single .ql file, a directory containing multiple .ql files, a .qls query suite definition file, or any combination. Para obter mais informações sobre definições do conjunto de consultas, consulte "Criar as conjuntos de consulta do CodeQL".

You can use both packs and queries in the same workflow.

Não recomendamos fazer referência a conjuntos de consulta diretamente do repositório github/codeql, como github/codeql/cpp/ql/src@main. Tais consultas não podem ser compiladas com a mesma versão do CodeQL que é usada para outras consultas, que poderia gerar erros durante a análise.

Usando pacotes de consulta de CodeQL

Para adicionar um ou mais pacotes de consulta (beta) de CodeQL, adicione uma entrada with: packs à seção uses: github/codeql-action/init@v1 do fluxo de trabalho. Dentro de pacotes você especifica um ou mais pacotes para usar e, opcionalmente, qual versão baixar. Quando você não especificar uma versão, será feito o download da versão mais recente. Se você quiser usar pacotes que não estão disponíveis publicamente, você precisa definir a variável de ambiente GITHUB_TOKEN para um segredo que tenha acesso aos pacotes. Para obter mais informações, consulte "Autenticação em um fluxo de trabalho" e "Segredos criptografados".

No exemplo abaixo, escopo é toda organização ou conta pessoal que publicou o pacote. Quando o fluxo de trabalho é executado, os três pacotes de consulta de CodeQL são baixados de GitHub e das consultas ou conjunto de consultas padrão para cada execução de pacote. É feito o download da versão mais recente do pack1, pois nenhuma versão é especificada. A versão 1.2.3 de pack2 é baixada, bem como a última versão de pack3 que é compatível com a versão 1.2.3.

- uses: github/codeql-action/init@v1
  with:
    # Comma-separated list of packs to download
    packs: scope/pack1,scope/[email protected],scope/pack3@~1.2.3

Usando consultas em pacotes QL

Para adicionar uma ou mais consultas, adicione uma entrada with: queries: na seção uses: github/codeql-action/init@v1 do fluxo de trabalho. Se as consultas estiverem em um repositório privado, use o parâmetro external-repository-token para especificar um token que tenha acesso ao check-out do repositório privado.

- uses: github/codeql-action/init@v1
  with:
    queries: COMMA-SEPARATED LIST OF PATHS
    # Optional. Forneça um token de acesso para consultas armazenadas em repositórios privados.
    external-repository-token: ${{ secrets.ACCESS_TOKEN }}

Você também pode executar suítes de consultas adicionais especificando-os em um arquivo de configuração. Os suítes de consulta são coleções de consultas, geralmente agrupados por finalidade ou linguagem.

Os conjuntos de consulta a seguir foram criados em CodeQL Varredura de código e estão disponíveis para uso.

Ao especificar um conjunto de pesquisas, o mecanismo de análise de CodeQL executará as consultas contidas no conjunto para você além do conjunto-padrão de consultas.

Trabalhando com arquivos de configuração personalizados

Se você também usar um arquivo de configuração para configurações personalizadas, todas os pacotes ou consultas especificadas no seu fluxo de trabalho serão usados em vez daqueles especificados no arquivo de configuração. Se você quiser executar o conjunto combinado de pacotes adicionais ou consultas, prefixe o valor de pacotes ou consultas no fluxo de trabalho com o símbolo +. Para obter exemplos de arquivos de configuração, consulte "Exemplo de arquivos de configuração".

No exemplo a seguir, o símbolo + garante que os pacotes e consultas especificados sejam usados em conjunto com qualquer um especificado no arquivo de configuração referenciado.

- 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
    packs: +scope/pack1,scope/[email protected]
    

Usar uma ferramenta de varredura de código de terceiros

Um arquivo de configuração personalizado é uma forma alternativa de especificar as consultas adicionais de e a serem executadas. Você também pode usar o arquivo para desabilitar as consultas padrão e especificar quais diretórios digitalizar durante a análise.

No arquivo de workflow use o parâmetro config-file da ação init para especificar o caminho para o arquivo de configuração que você deseja usar. Este exemplo carrega o arquivo de configuração ./.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.

Se o arquivo de configuração estiver localizado em um repositório privado externo, use o parâmetro external-repository-token da ação init para especificar um token que tenha acesso ao repositório privado.

- uses: github/codeql-action/init@v1
  with:
    external-repository-token: ${{ secrets.ACCESS_TOKEN }}

As configurações no arquivo de configuração estão escritas no formato YAML.

Especificando pacotes de consulta de CodeQL

Você especificou pacotes de consulta de CodeQL em uma matriz. Observe que o formato é diferente do formato usado pelo arquivo do fluxo de trabalho.

packs: 
  # Use the latest version of 'pack1' published by 'scope'
  - scope/pack1 
  # Use version 1.23 of 'pack2' 
  - scope/[email protected]
  # Use the latest version of 'pack3' compatible with 1.23
  - scope/pack3@~1.2.3

Se tiver um fluxo de trabalho que gera mais de um banco de dados de CodeQL, você poderá especificar todos os pacotes de consulta de CodeQL para executar em um arquivo de configuração personalizado usando um mapa aninhado de pacotes.

packs:
  # Use these packs for JavaScript analysis
  javascript:
    - scope/js-pack1
    - scope/js-pack2
  # Use these packs for Java analysis
  java:
    - scope/java-pack1
    - scope/[email protected]

Especificar consultas adicionais

Você especifica consultas adicionais em um array de consultas. Cada elemento do array contém um parâmetro de uso com um valor que identifica um único arquivo de consulta, um diretório que contém arquivos de consulta ou um arquivo de definição do conjunto de consulta.

queries:
  - uses: ./my-basic-queries/example-query.ql
  - uses: ./my-advanced-queries
  - uses: ./query-suites/my-security-queries.qls

Opcionalmente, você pode dar um nome a cada elemento do array, conforme mostrado nos exemplos de arquivos de configuração abaixo. Para obter mais informações sobre consultas adicionais, consulte "Executar consultas adicionais acima.

Desativar as consultas-padrão

Se você desejar apenas executar consultas personalizadas, você poderá desabilitar as consultas de segurança padrão adicionando disable-default-queries: true ao seu arquivo de configuração.

Especificar diretórios para serem varridos

Para as linguagens interpretadas com as quais CodeQL é compatível (Python, Ruby e JavaScript/TypeScript), você pode restringir Varredura de código para arquivos em diretórios específicos adicionando uma matriz caminhos matriz ao arquivo de configuração. Você pode excluir os arquivos em diretórios específicos das análises, adicionando um array de paths-ignore.

paths:
  - src
paths-ignore:
  - src/node_modules
  - '**/*.test.js'

Para linguagens compiladas, se você deseja limitar Varredura de código a diretórios específicos no seu projeto, você deverá especificar os passos de compilação adequados no fluxo de trabalho. Os comandos que você precisa usar para excluir um diretório da criação dependerão do seu sistema de criação. Para obter mais informações, consulte "Configurar o fluxo de trabalho do CodeQL para linguagens compiladas".

Você pode rapidamente analisar pequenas partes de um monorepo ao modificar o código em diretórios específicos. Você deverá excluir diretórios nas suas etapas de criação e usar as palavras-chave paths-ignore e caminhos para on.<push|pull_request> no seu arquivo de fluxo de trabalho.

Exemplo de arquivo de configuração

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'

Configurar o Varredura de código para linguagens compiladas

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. Para obter mais informações sobre como configurar CodeQL Varredura de código para linguagens compiladas, consulte "Configurar o fluxo de trabalho do CodeQL para linguagens compiladas".

Varredura de código usa GitHub Actions.

Você pode exibir análise de código de uma ferramenta de terceiros em GitHub, adicionando a ação de upload-sarif ao seu fluxo de trabalho. Você pode fazer o upload de dados de análise de código com a ação upload-sarif. Para obter mais informações, consulte "Fazer o upload de um arquivo SARIF para o GitHub".