{"meta":{"title":"Opções de configuração de fluxo de trabalho para verificação de código","intro":"Edite seu arquivo de fluxo de trabalho para configurar como a instalação avançada verifica o código em seu projeto em busca de vulnerabilidades e erros.","product":"Qualidade de segurança e código","breadcrumbs":[{"href":"/pt/code-security","title":"Qualidade de segurança e código"},{"href":"/pt/code-security/reference","title":"Referência"},{"href":"/pt/code-security/reference/code-scanning","title":"Varredura de código"},{"href":"/pt/code-security/reference/code-scanning/workflow-configuration-options","title":"Opções de configuração de fluxo de trabalho"}],"documentType":"article"},"body":"# Opções de configuração de fluxo de trabalho para verificação de código\n\nEdite seu arquivo de fluxo de trabalho para configurar como a instalação avançada verifica o código em seu projeto em busca de vulnerabilidades e erros.\n\n\n\n## Pré-requisitos\n\nVocê deve usar a configuração avançada para code scanning e ser capaz de editar o arquivo de fluxo de trabalho onde sua configuração está definida.\n\nOs exemplos fornecidos neste artigo estão relacionados ao Fluxo de trabalho de análise do CodeQL arquivo. Por padrão, esse arquivo é definido em `.github/workflows/codeql-analysis.yml`.\n\n## Frequência de varredura\n\nVocê pode configurar o Fluxo de trabalho de análise do CodeQL para escanear o código de acordo com um cronograma ou quando eventos específicos ocorrerem em um repositório.\n\nA 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 verificação de código de forma programada informa sobre as vulnerabilidades e erros mais recentes que foram descobertos por GitHub, pesquisadores de segurança e a comunidade, mesmo quando os desenvolvedores do repositório não estão mantendo-o ativamente.\n\n### Fazer a varredura no push\n\nPor padrão, o Fluxo de trabalho de análise do CodeQL usa o evento `on:push` para disparar uma verificação de código em cada push para o branch padrão do repositório e quaisquer branches protegidos. Para code scanning ser disparado em um branch especificado, o fluxo de trabalho deve existir nesse branch. Para saber mais, confira [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/actions/using-workflows/workflow-syntax-for-github-actions#on).\n\nSe você fizer a varredura no push, os resultados aparecerão na aba ** Security and quality** do repositório. Para saber mais, confira [Avaliar alertas de varredura de código para seu repositório](/pt/code-security/code-scanning/managing-code-scanning-alerts/assessing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository).\n\nAlém disso, quando uma verificação de `on:push` retorna resultados que podem ser mapeados para uma solicitação de pull aberta, esses alertas aparecem automaticamente na solicitação de pull no mesmo local que os outros alertas da solicitação de pull. Os alertas são identificados por meio da comparação da análise existente do início da ramificação com a análise da ramificação de destino. Para obter mais informações sobre code scanning alertas em solicitações de pull, consulte [Alertas de varredura de código de triagem em pull requests](/pt/code-security/code-scanning/managing-code-scanning-alerts/triaging-code-scanning-alerts-in-pull-requests).\n\n### Fazer a varredura de pull requests\n\nO Fluxo de trabalho de análise do CodeQL padrão usa o evento `pull_request` para disparar uma verificação de código nos pull requests direcionados ao branch padrão.\nSe uma solicitação de pull for de uma bifurcação privada, o `pull_request` evento só será disparado se você tiver selecionado a opção \"Executar fluxos de trabalho de solicitações de pull de bifurcação\" nas configurações do repositório. Para obter mais informações, consulte [Gerenciando configurações de GitHub Actions para um repositório](/pt/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks).\n\nPara obter mais informações sobre o evento `pull_request`, confira [Eventos que disparam fluxos de trabalho](/pt/actions/using-workflows/events-that-trigger-workflows#pull_request).\n\nSe você examinar as solicitações de pull, os resultados serão exibidos como alertas em uma verificação de solicitação de pull. Para saber mais, confira [Alertas de varredura de código de triagem em pull requests](/pt/code-security/code-scanning/managing-code-scanning-alerts/triaging-code-scanning-alerts-in-pull-requests).\n\nSe você usar o gatilho `pull_request`, configurado para verificar o commit de mesclagem da solicitação de pull em vez do commit de cabeçalho, ele produzirá resultados mais eficientes e precisos do que a verificação do cabeçalho do branch em cada push. No entanto, se você usar um sistema de CI/CD que não pode ser configurado para ser acionado por solicitações de pull, ainda poderá usar o `on:push` gatilho, e code scanning irá mapear os resultados para as solicitações de pull abertas na branch e adicionar alertas como anotações na solicitação de pull. Para obter mais informações, confira [Verificação durante o push](#scanning-on-push).\n\n> \\[!NOTE]\n> Se o repositório estiver configurado com uma fila de mesclagem, você precisará incluir o `merge_group` evento como um gatilho adicional para code scanning. Isso garantirá que as solicitações de pull também sejam verificadas quando forem adicionadas a uma fila de mesclagem. Para saber mais, confira [Como gerenciar uma fila de mesclagem](/pt/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue).\n\n### Evitar varreduras desnecessárias de pull requests\n\nTalvez você queira evitar que uma varredura de código seja disparada em solicitações de pull específicas direcionadas à ramificação padrão, independentemente dos arquivos que foram alterados. Você pode configurar isso especificando `on:pull_request:paths-ignore` ou `on:pull_request:paths` no code scanning fluxo de trabalho. Por exemplo, se as únicas alterações em uma solicitação de pull forem para arquivos com as extensões de arquivo `.md` ou `.txt`, você poderá usar a matriz `paths-ignore` a seguir.\n\n```yaml copy\non:\n push:\n branches: [main, protected]\n pull_request:\n branches: [main]\n paths-ignore:\n - '**/*.md'\n - '**/*.txt'\n```\n\n> \\[!NOTE]\n\n```\n `on:pull_request:paths-ignore` e `on:pull_request:paths` definem condições que determinam se as ações no fluxo de trabalho serão executadas em uma solicitação de pull. Eles não determinam quais arquivos serão analisados quando as ações _forem_ executadas. Quando uma solicitação de pull contém arquivos sem correspondência com `on:pull_request:paths-ignore` ou `on:pull_request:paths`, o fluxo de trabalho executa as ações e verifica todos os arquivos alterados na solicitação de pull, incluindo aqueles correspondentes a `on:pull_request:paths-ignore` ou `on:pull_request:paths`, a menos que eles tenham sido excluídos. Para obter informações sobre como excluir arquivos da análise, confira [Como especificar os diretórios para verificação](#specifying-directories-to-scan).\n```\n\nPara obter 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 uma solicitação de pull, confira [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore).\n\n### Fazer a varredura de forma pré-programada\n\nSe você usar o padrão Fluxo de trabalho de análise do CodeQL, o fluxo de trabalho examinará o código em seu repositório uma vez por semana, além das verificações disparadas por eventos. Para ajustar essa agenda, edite o valor `cron` do evento `on.schedule` no fluxo de trabalho. Para saber mais, confira [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/actions/reference/workflows-and-actions/workflow-syntax#onschedule).\n\n> \\[!NOTE]\n> Esse evento vai disparar apenas um fluxo de trabalho executado se o arquivo de fluxo de trabalho existe no branch padrão.\n\n### Exemplo\n\nO exemplo a seguir mostra um Fluxo de trabalho de análise do CodeQL de um repositório específico, que tem um branch padrão chamado `main` e um branch protegido chamado `protected`.\n\n```yaml copy\non:\n push:\n branches: [main, protected]\n pull_request:\n branches: [main]\n schedule:\n - cron: '20 14 * * 1'\n```\n\nEste fluxo de trabalho varre:\n\n* Cada push para a ramificação padrão e a ramificação protegida\n* Cada solicitação de pull para a ramificação padrão\n* A ramificação padrão a cada segunda-feira às 14h20 UTC\n\n## Sistema operacional\n\n> \\[!NOTE]\n>\n> * A verificação do código Swift usa executores do macOS por padrão.\n\n```\n GitHubOs executores de macOS hospedados são mais caros do que os executores do Linux e do Windows, portanto, você deve considerar apenas a verificação da etapa de build. Para obter mais informações sobre como configurar a verificação de código para Swift, confira [AUTOTITLE](/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages#considerations-for-building-swift). Para obter mais informações sobre preços para GitHubexecutores hospedados, consulte [AUTOTITLE](/billing/managing-billing-for-github-actions/about-billing-for-github-actions).\n```\n\n> * O Code scanning do código Swift não é compatível com executores que fazem parte de um Actions Runner Controller (ARC), porque os executores ARC usam apenas o Linux e o Swift requer executores macOS. No entanto, você pode ter uma mistura de executores ARC e executores macOS auto-hospedados. Para saber mais, confira [Controlador de Ações Runner](/pt/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-actions-runner-controller).\n\nSe o código exigir que um sistema operacional específico seja compilado, 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 o computador que executa suas code scanning tarefas.\n\n```yaml copy\njobs:\n analyze:\n name: Analyze\n runs-on: [ubuntu-latest]\n```\n\nSe você optar por usar um executor auto-hospedado para verificação de código, poderá especificar um sistema operacional usando um rótulo apropriado como o segundo elemento em uma matriz de dois elementos, após `self-hosted`.\n\n```yaml copy\njobs:\n analyze:\n name: Analyze\n runs-on: [self-hosted, ubuntu-latest]\n```\n\n```\n CodeQL\n code scanning dá suporte às versões mais recentes do Ubuntu, windows e macOS. Os valores típicos dessa configuração são: `ubuntu-latest`, `windows-latest` e `macos-latest`. Para saber mais, confira [AUTOTITLE](/actions/using-jobs/choosing-the-runner-for-a-job) e [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/using-labels-with-self-hosted-runners).\n\n Se você usar um executor auto-hospedado, deverá garantir que o Git esteja na variável PATH. Para saber mais, confira [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners) e [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners).\n```\n\nPara obter especificações recomendadas (RAM, núcleos de CPU e disco) para executar CodeQL a análise em computadores auto-hospedados, consulte [Recursos de hardware recomendados para executar o CodeQL](/pt/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/recommended-hardware-resources-for-running-codeql).\n\n##\n\n```\n CodeQL local do banco de dados\n```\n\nEm geral, você não precisa se preocupar com onde o Fluxo de trabalho de análise do CodeQL coloca os bancos de dados CodeQL, pois as etapas posteriores encontrarão automaticamente os bancos de dados criados por etapas anteriores. No entanto, se você estiver escrevendo uma etapa de fluxo de trabalho personalizada que exija que o CodeQL banco de dados esteja em um local de disco específico, por exemplo, para carregar o banco de dados como um artefato de fluxo de trabalho, você poderá especificar esse local usando o `db-location` parâmetro sob a ação `init` .\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n db-location: '${{ github.runner_temp }}/my_location'\n```\n\n```\n Fluxo de trabalho de análise do CodeQL vai esperar que o caminho em `db-location` seja gravável 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. Isso não é necessário para trabalhos em execução em GitHubexecutores hospedados, que obtêm uma instância nova e um sistema de arquivos limpo a cada vez que são executados. Para saber mais, confira [AUTOTITLE](/actions/using-github-hosted-runners/about-github-hosted-runners).\n```\n\nSe esse parâmetro não for usado, ele Fluxo de trabalho de análise do CodeQL criará bancos de dados em um local temporário de sua própria escolha. Atualmente, o valor padrão é `${{ github.runner_temp }}/codeql_databases`.\n\n## Idiomas a serem analisados\n\n```\n CodeQL\n code scanning dá suporte ao código escrito nos seguintes idiomas:\n```\n\n\n\n* C/C++\n* C#\n* Go\n* Java/Kotlin\n* JavaScript/TypeScript\n* Python\n* Ruby\n* Rust\n* Swift\\* Fluxos de trabalho do GitHub Actions\n\n> \\[!NOTE]\n>\n> * Use `java-kotlin` para analisar o código escrito em Java, Kotlin ou ambos.\n> * Use `javascript-typescript` para analisar o código escrito em JavaScript, TypeScript ou ambos.\n\nPara obter mais informações, confira a documentação no site do CodeQL: [Linguagens e estruturas compatíveis](https://codeql.github.com/docs/codeql-overview/supported-languages-and-frameworks/).\n\n```\n CodeQL usa os seguintes identificadores de idioma:\n```\n\n| Linguagem | Identificador | Identificadores alternativos opcionais (se houver) |\n| --------- | ------------- | -------------------------------------------------- |\n| C/C++ | `c-cpp` | |\n\n```\n `c` ou `cpp` |\n```\n\n\\| C# | `csharp` |\n\\| |\nFluxos de trabalho GitHub Actions | `actions`\n|\n\\| Go | `go` |\n\\| Java/Kotlin | `java-kotlin` |\n`java` ou `kotlin` |\n\\| JavaScript/TypeScript | `javascript-typescript` |\n`javascript` ou `typescript` |\n\\| Python | `python` |\n\\| Ruby | `ruby` |\n\\| |\nRust | `rust`\n|\n\\| Swift | `swift` |\n\n> \\[!NOTE]\n> Especificar um dos identificadores alternativos equivale a usar o identificador de linguagem padrão. Por exemplo, especificar `javascript` em vez de `javascript-typescript` não excluirá a análise do código TypeScript. Em vez disso, você pode usar um arquivo de configuração personalizado para excluir arquivos da análise usando a configuração `paths-ignore`. Para obter mais informações, confira [Como usar um arquivo de configuração personalizado](/pt/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning#custom-configuration-files) e [Como especificar diretórios a serem digitalizados](/pt/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning#specifying-directories-to-scan).\n\nEsses identificadores de linguagem podem ser usados como argumentos para a entrada `languages` da ação `init`. Recomendamos que apenas uma linguagem seja fornecida como argumento:\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n languages: javascript-typescript\n```\n\nO arquivo padrão Fluxo de trabalho de análise do CodeQL criado após [a configuração avançada para verificação de código com CodeQL](/pt/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning#configuring-advanced-setup-for-code-scanning-with-codeql) define uma matriz que contém uma propriedade nomeada `language` que lista os idiomas em seu repositório que serão analisados. Essa matriz foi preenchida automaticamente com linguagens com suporte detectadas em seu repositório. O uso da `language` matriz permite CodeQL executar cada análise de idioma em paralelo e personalizar a análise para cada idioma. Em uma análise individual, o nome da linguagem da matriz é fornecido à ação `init` como o argumento para a entrada `languages`. Recomendamos que todos os fluxos de trabalho adotem essa configuração. Para obter mais informações sobre matrizes, confira [Executando variações de tarefas em um workflow](/pt/actions/using-jobs/using-a-matrix-for-your-jobs).\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n languages: ${{ matrix.language }}\n```\n\nSe o fluxo de trabalho utilizar a `language` matriz, CodeQL analisará apenas os idiomas na matriz. Para alterar as linguagens que você quer analisar, edite a configuração da matriz. Você pode remover uma linguagem para impedir que ela seja analisada. Há vários motivos pelos quais você talvez queira impedir que uma linguagem seja analisada. Por exemplo, o projeto pode ter dependências em uma linguagem diferente do corpo principal do seu código e você pode preferir não ver alertas para essas dependências. Você também pode adicionar um idioma que não estava presente no repositório quando code scanning foi configurado. Por exemplo, se o repositório inicialmente continha apenas JavaScript quando code scanning foi configurado e você adicionou posteriormente o código Python, será necessário adicionar `python` à matriz.\n\n```yaml copy\njobs:\n analyze:\n name: Analyze\n ...\n strategy:\n fail-fast: false\n matrix:\n include:\n - language: javascript-typescript\n build-mode: none\n - language: python\n build-mode: none\n```\n\nPara linguagens compiladas, a matriz também pode ser usada para configurar qual modo de build usar para a análise alterando o valor da propriedade `build-mode`. Para obter mais informações sobre modos de build, confira [Verificação de código do CodeQL para linguagens compiladas](/pt/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages#about-build-mode-none-for-codeql).\n\nSe o fluxo de trabalho não fornecer um argumento para a `languages` entrada da ação `init`, CodeQL será configurado para executar análises sequencialmente. Nesse caso, CodeQL detecta e tenta analisar automaticamente todos os idiomas com suporte no repositório. Dependendo do tamanho do repositório e do número de linguagens, isso pode levar muito tempo. Se a análise de uma linguagem falhar nesse modo, a análise de todas as linguagens falhará. Portanto, não recomendamos essa configuração.\n\n> \\[!NOTE]\n> Ao analisar linguagens sequencialmente, o modo de build padrão de cada linguagem será usado. Como alternativa, se você fornecer uma etapa `autobuild` explícita, todas as linguagens com suporte para o modo `autobuild` a usarão, enquanto outras linguagens usam o modo padrão. Se for necessária uma configuração de modo de build mais complexa do que essa, você precisará configurar uma matriz.\n\n## Severidades de alerta para falhas de verificação\n\nVocê pode usar conjuntos de regras para evitar que pull requests sejam mesclados quando uma das seguintes condições for atendida:\n\n* Uma ferramenta necessária localiza um alerta code scanning de uma severidade definida no conjunto de regras.\n* A análise da ferramenta necessária ainda está em andamento.\n* Uma ferramenta necessária não está configurada para o repositório.\n\nPara saber mais, confira [Definir proteção contra mesclagem de verificação de código](/pt/code-security/code-scanning/managing-your-code-scanning-configuration/set-code-scanning-merge-protection). Para obter informações gerais sobre conjuntos de regras, confira [Sobre os conjuntos de regras](/pt/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets).\n\n## Categoria de análise\n\nUse `category` para distinguir entre várias análises da mesma ferramenta e do mesmo commit, mas executadas em diferentes linguagens ou em diferentes partes do código. A categoria especificada no seu fluxo de trabalho será incluída no arquivo de resultados SARIF.\n\nEsse parâmetro é particularmente útil se você trabalhar com monorepos e tiver vários arquivos SARIF para diferentes componentes do monorepo.\n\n```yaml copy\n - name: Perform CodeQL Analysis\n uses: github/codeql-action/analyze@v4\n with:\n # Optional. Specify a category to distinguish between multiple analyses\n # for the same tool and ref. If you don't use `category` in your workflow,\n # GitHub will generate a default category name for you\n category: \"my_category\"\n```\n\nSe você não especificar um `category` parâmetro em seu fluxo de trabalho, GitHub gerará um nome de categoria para você, com base no nome do arquivo de fluxo de trabalho que dispara a ação, o nome da ação e quaisquer variáveis de matriz. Por exemplo:\n\n* O fluxo de trabalho `.github/workflows/codeql-analysis.yml` e a ação `analyze` produzirão a categoria `.github/workflows/codeql.yml:analyze`.\n* O fluxo de trabalho `.github/workflows/codeql-analysis.yml`, a ação `analyze` e as variáveis da matriz `{language: javascript-typescript, os: linux}` produzirão a categoria `.github/workflows/codeql-analysis.yml:analyze/language:javascript-typescript/os:linux`.\n\nO valor `category` será exibido como a propriedade `.automationDetails.id` no SARIF v2.1.0. Para saber mais, confira [Suporte SARIF para a varredura de código](/pt/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning#runautomationdetails-object).\n\nA categoria especificada não substituirá os detalhes do objeto `runAutomationDetails` no arquivo SARIF, se incluído.\n\n##\n\n```\n CodeQL pacotes de modelos\n```\n\nSe a sua base de código depender de uma biblioteca ou framework que não seja reconhecida pelas consultas padrão em CodeQL, você pode estender a cobertura em seu fluxo de trabalho code scanning especificando pacotes de modelos publicados CodeQL. Para obter mais informações sobre como criar seus próprios pacotes de modelo, confira [Como criar e trabalhar com pacotes do CodeQL](/pt/code-security/codeql-cli/using-the-advanced-functionality-of-the-codeql-cli/creating-and-working-with-codeql-packs#creating-a-model-pack).\n\n> \\[!NOTE]\n> Atualmente, os pacotes de modelo do CodeQL estão em versão prévia pública e estão sujeitos a alterações. Os pacotes de modelos são compatíveis com a análise do C/C++, C#, Java/Kotlin, Python, Ruby e Rust.\n>\n> O editor de modelos do CodeQL na extensão CodeQL para Visual Studio Code dá suporte a dependências de modelagem para C#, Java/Kotlin, Python e Ruby.\n\n### Usando CodeQL pacotes de modelos\n\nPara adicionar um ou mais pacotes de modelos publicados CodeQL , especifique-os dentro da `with: packs:` entrada dentro da `uses: github/codeql-action/init@v4` seção do fluxo de trabalho. Em `packs`, você especifica um ou mais pacotes a serem usados e, opcionalmente, a versão que será baixada. Quando você não especificar uma versão, a versão mais recente será baixada. Se você quiser usar pacotes que não estão publicamente disponíveis, precisará definir a variável de ambiente `GITHUB_TOKEN` para um segredo que tenha acesso aos pacotes. Para saber mais, confira [Usar GITHUB\\_TOKEN para autenticação em fluxos de trabalho](/pt/actions/security-guides/automatic-token-authentication) e [Usar segredos em ações do GitHub](/pt/actions/security-guides/encrypted-secrets).\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n config-file: ./.github/codeql/codeql-config.yml\n queries: security-extended\n packs: my-company/my-java-queries@~7.8.9,my-repo/my-java-model-pack\n```\n\nNeste exemplo, as consultas padrão serão executadas para Java, bem como as consultas de uma versão maior ou igual a `7.8.9` e menor que `7.9.0` do pacote de consultas `my-company/my-java-queries`. As dependências modeladas na versão mais recente do pacote de modelos `my-repo/my-java-model-pack` estarão disponíveis para as consultas padrão e aquelas no `my-company/my-java-queries`.\n\n## Consultas não padrão\n\nAo 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.\n\n> \\[!TIP]\n> Você também pode especificar as consultas que deseja excluir da análise ou incluir na análise. Isso requer o uso de um arquivo de configuração personalizado. Para obter mais informações, consulte [arquivos de configuração personalizados](#custom-configuration-files) e [exclusão de consultas específicas da análise](#excluding-specific-queries-from-analysis) abaixo.\n\nVocê pode executar consultas adicionais se elas fizerem parte de um pacote do CodeQL publicado no GitHub Container registry ou um pacote do armazenado em um repositório. Para saber mais, confira [Sobre a varredura de código com CodeQL](/pt/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql#about-codeql-queries).\n\nAs opções disponíveis para especificar as consultas adicionais que você deseja executar são:\n\n* ```\n `packs` para instalar um ou mais pacotes de consulta do CodeQL e executar o conjunto de consultas padrão ou as consultas desses pacotes.\n ```\n* ```\n `queries` para especificar um arquivo _.ql_ individual, um diretório que contém vários arquivos _.ql_, um arquivo de definição de pacote de consultas _.qls_ ou qualquer combinação. Para obter mais informações sobre as definições do pacote de consultas, confira [Como criar pacotes de consultas do CodeQL](https://codeql.github.com/docs/codeql-cli/creating-codeql-query-suites/).\n ```\n\nUse `packs` e `queries` no mesmo fluxo de trabalho.\n\nNão recomendamos referenciar pacotes de consultas diretamente do repositório `github/codeql`, como `github/codeql/cpp/ql/src@main`. Essas consultas teriam que ser recompiladas e talvez não sejam compatíveis com a versão do CodeQL ativa no momento no GitHub Actions, o que poderia causar erros durante a análise.\n\n### Usando pacotes de consultas\n\nPara adicionar um ou mais CodeQL pacotes de consulta, adicione uma `with: packs:` entrada na `uses: github/codeql-action/init@v4` seção do fluxo de trabalho. Em `packs`, você especifica um ou mais pacotes a serem usados e, opcionalmente, a versão que será baixada. Quando você não especificar uma versão, a versão mais recente será baixada. Se você quiser usar pacotes que não estão publicamente disponíveis, precisará definir a variável de ambiente `GITHUB_TOKEN` para um segredo que tenha acesso aos pacotes. Para saber mais, confira [Usar GITHUB\\_TOKEN para autenticação em fluxos de trabalho](/pt/actions/security-guides/automatic-token-authentication) e [Usar segredos em ações do GitHub](/pt/actions/security-guides/encrypted-secrets).\n\n> \\[!NOTE]\n> Para fluxos de trabalho que geram CodeQL bancos de dados para vários idiomas, você deve especificar os CodeQL pacotes de consulta em um arquivo de configuração. Para obter mais informações, consulte [Especificando CodeQL pacotes de consulta](#specifying-codeql-query-packs) abaixo.\n\nNo exemplo abaixo, `scope` é a organização ou a conta pessoal que publicou o pacote. Quando o fluxo de trabalho é executado, os quatro CodeQL pacotes de GitHub consulta são baixados e as consultas ou o pacote de consultas padrão para cada pacote são executados:\n\n* A última versão do `pack1` é baixada e todas as consultas padrão são executadas.\n* A versão 1.2.3 do `pack2` é baixada e todas as consultas padrão são executadas.\n* A última versão do `pack3` que é compatível com a versão 3.2.1 é baixada e todas as consultas são executadas.\n* A versão 4.5.6 é `pack4` baixada e somente as consultas encontradas em `path/to/queries` são executadas.\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n # Comma-separated list of packs to download\n packs: scope/pack1,scope/pack2@1.2.3,scope/pack3@~3.2.1,scope/pack4@4.5.6:path/to/queries\n```\n\n> \\[!NOTE]\n> Se você especificar uma versão particular de um pacote de consultas a ser usado, esteja ciente de que a versão que você especificar pode eventualmente se tornar muito antiga para ser usada com eficiência pelo mecanismo padrão CodeQL utilizado pela ação CodeQL. Para garantir o desempenho ideal, se você precisar especificar versões exatas do pacote de consultas, considere examinar periodicamente se a versão fixada do pacote de consultas precisa ser atualizada.\n>\n> Para obter mais informações sobre a compatibilidade de pacotes, confira [Referência de pacotes de consulta CodeQL](/pt/code-security/reference/code-scanning/codeql/codeql-cli/codeql-query-packs#codeql-pack-compatibility).\n\n### Baixando CodeQL pacotes de GitHub Enterprise Server\n\nSe o fluxo de trabalho usar pacotes publicados em uma GitHub Enterprise Server instalação, você precisará informar ao fluxo de trabalho onde encontrá-los. Você pode fazer isso usando a entrada `registries` da ação github/codeql-action/init\\@v4. Essa entrada aceita uma lista de propriedades `url`, `packages` e `token`, como é mostrado abaixo.\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n registries: |\n # URL to the container registry, usually in this format\n - url: https://containers.GHEHOSTNAME1/v2/\n\n # List of package glob patterns to be found at this registry\n packages:\n - my-company/*\n - my-company2/*\n\n # Token, which should be stored as a secret\n token: ${{ secrets.GHEHOSTNAME1_TOKEN }}\n\n # URL to the default container registry\n - url: https://ghcr.io/v2/\n # Packages can also be a string\n packages: \"*/*\"\n token: ${{ secrets.GHCR_TOKEN }}\n\n \n```\n\nOs padrões de pacote na lista de registros são examinados em ordem, portanto, coloque os padrões de pacote mais específicos em primeiro lugar. Os valores para `token` devem ser um personal access token (classic) gerado pela instância do GitHub da qual você está baixando, com a permissão `read:packages`.\n\nObserve o `|` após o nome da propriedade `registries`. Isso é importante, pois GitHub Actions as entradas só podem aceitar cadeias de caracteres. Usar o `|` converte o texto subsequente em uma cadeia de caracteres, que é analisada posteriormente pela ação do github/codeql-action/init\\@v4.\n\n### Usando consultas em pacotes QL\n\nPara adicionar uma ou mais consultas, adicione uma entrada `with: queries:` dentro da seção `uses: github/codeql-action/init@v4` 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 para fazer check-out do repositório privado.\n\nVocê também pode especificar conjuntos de consulta no valor de `queries`. Os conjuntos de consulta são coleções de consultas, geralmente agrupadas por finalidade ou linguagem.\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n # Comma-separated list of queries / packs / suites to run.\n # This may include paths or a built in suite, for example:\n # security-extended or security-and-quality.\n queries: security-extended\n # Optional. Provide a token to access queries stored in private repositories.\n external-repository-token: ${{ secrets.ACCESS_TOKEN }}\n```\n\nOs conjuntos de consulta a seguir foram criados em CodeQL code scanning e estão disponíveis para uso.\n\n| Conjunto de consultas | Descrição |\n| :--------------------- | :----------------------------------------------------------------------------------------------- |\n| `security-extended` | Consultas do pacote padrão, além de consultas de gravidade e precisão inferiores |\n| `security-and-quality` | Consultas de `security-extended`, além de consultas de capacidade de manutenção e confiabilidade |\n\nPara obter mais informações, confira: [Conjuntos de consultas CodeQL](/pt/code-security/code-scanning/managing-your-code-scanning-configuration/built-in-codeql-query-suites).\n\nCada um desses conjuntos de consultas contém um subconjunto diferente das consultas incluídas no pacote de consultas integrado CodeQL para esse idioma. Os pacotes de consultas são gerados automaticamente por meio dos metadados de cada consulta. Para saber mais, confira [Metadados para consultas CodeQL](https://codeql.github.com/docs/writing-codeql-queries/metadata-for-codeql-queries/).\n\n\n\nQuando você especificar um pacote de consultas, o mecanismo de análise do CodeQL executará o conjunto padrão de consultas e todas as consultas extras definidas no pacote de consultas adicionais.\n\n### Trabalhando com arquivos de configuração personalizados\n\nSe você também usar um arquivo de configuração para configurações personalizadas, todos os pacotes ou consultas adicionais especificados no fluxo de trabalho serão usados em vez daqueles especificados no arquivo de configuração. Caso deseje executar o conjunto combinado de pacotes ou consultas adicionais, coloque o valor de `packs` ou `queries` como prefixo do fluxo de trabalho com o símbolo `+`. Para obter mais informações, consulte [arquivos de configuração personalizados](#custom-configuration-files).\n\nNo exemplo a seguir, o símbolo `+` garante que os pacotes e as consultas adicionais especificados sejam usados junto com qualquer item especificado no arquivo de configuração referenciado.\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n config-file: ./.github/codeql/codeql-config.yml\n queries: +security-and-quality,octo-org/python-qlpack/show_ifs.ql@main\n packs: +scope/pack1,scope/pack2@1.2.3,scope/pack3@4.5.6:path/to/queries\n```\n\n\n\n## Arquivos de configuração personalizados\n\nUm arquivo de configuração personalizado é uma maneira alternativa de especificar pacotes e consultas adicionais a serem executados. Você também pode usar o arquivo para desabilitar as consultas padrão, excluir ou incluir consultas específicas e especificar quais diretórios examinar durante a análise.\n\nNo arquivo de fluxo de trabalho, 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*.\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n config-file: ./.github/codeql/codeql-config.yml\n```\n\nO 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 que você especifique opções de configuração para vários repositórios em um único local. Ao fazer referência a um arquivo de configuração localizado em um repositório externo, você poderá usar a sintaxe *OWNER/REPOSITORY/FILENAME\\@BRANCH* . Por exemplo, *octo-org/shared/codeql-config.yml\\@main*.\n\nSe 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.\n\n```yaml copy\n- uses: github/codeql-action/init@v4\n with:\n external-repository-token: ${{ secrets.ACCESS_TOKEN }}\n```\n\nAs configurações no arquivo de configuração são gravadas no formato YAML.\n\n### Especificando CodeQL pacotes de consulta\n\nOs pacotes de consulta CodeQL são especificados em uma matriz. Observe que o formato é diferente do formato usado pelo arquivo de fluxo de trabalho.\n\n```yaml copy\npacks:\n # Use the latest version of 'pack1' published by 'scope'\n - scope/pack1\n # Use version 1.2.3 of 'pack2'\n - scope/pack2@1.2.3\n # Use the latest version of 'pack3' compatible with 3.2.1\n - scope/pack3@~3.2.1\n # Use pack4 and restrict it to queries found in the 'path/to/queries' directory\n - scope/pack4:path/to/queries\n # Use pack5 and restrict it to the query 'path/to/single/query.ql'\n - scope/pack5:path/to/single/query.ql\n # Use pack6 and restrict it to the query suite 'path/to/suite.qls'\n - scope/pack6:path/to/suite.qls\n```\n\nO formato completo para especificar um pacote de consultas é `scope/name[@version][:path]`.\n`version` e `path` são opcionais.\n`version` é o intervalo de versão semver. Se ele estiver ausente, a última versão será usada. Para obter mais informações sobre intervalos semver, confira a [documentação do semver no npm](https://docs.npmjs.com/cli/v6/using-npm/semver#ranges).\n\nSe você tiver um fluxo de trabalho que gere mais de um banco de dados, poderá especificar todos CodeQL os CodeQL pacotes de consulta a serem executados em um arquivo de configuração personalizado usando um mapa aninhado de pacotes.\n\n```yaml copy\npacks:\n # Use these packs for JavaScript and TypeScript analysis\n javascript:\n - scope/js-pack1\n - scope/js-pack2\n # Use these packs for Java and Kotlin analysis\n java:\n - scope/java-pack1\n - scope/java-pack2@v1.0.0\n```\n\n### Estendendo a CodeQL cobertura com modelos de ameaça\n\n> \\[!NOTE]\n> Modelos de riscos estão em versão prévia pública e estão sujeitos a alterações. Durante o versão prévia pública, os modelos de risco são compatíveis apenas com a análise para Java/Kotlin e C#.\n\nO modelo de risco padrão inclui fontes remotas de dados não confiáveis. Você pode estender o CodeQL modelo de ameaça para incluir fontes locais de dados não confiáveis (por exemplo: argumentos de linha de comando, variáveis de ambiente, sistemas de arquivos e bancos de dados) especificando `threat-models: local` em um arquivo de configuração personalizado. Se você estender o modelo de risco, o modelo de risco padrão também será usado.\n\n### Especificar consultas adicionais\n\nAs consultas adicionais são especificadas em uma matriz `queries`. Cada elemento da matriz contém um parâmetro `uses` com um valor que identifica um arquivo de consulta individual, um diretório contendo arquivos de consulta ou um arquivo de definição de conjunto de consultas.\n\n```yaml copy\nqueries:\n - uses: ./my-basic-queries/example-query.ql\n - uses: ./my-advanced-queries\n - uses: ./query-suites/my-security-queries.qls\n```\n\nOpcionalmente, 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 [consultas não padrão](#non-default-queries) acima.\n\n### Desativar as consultas-padrão\n\nSe você quiser apenas executar consultas personalizadas, poderá desabilitar as consultas de segurança padrão usando `disable-default-queries: true`.\n\n### Como excluir consultas específicas da análise\n\nVocê pode adicionar os filtros `exclude` e `include` ao seu arquivo de configuração personalizado para especificar as consultas que deseja excluir ou incluir na análise.\n\nIsso será útil se você quiser excluir, por exemplo:\n\n* Consultas específicas dos pacotes padrão (`security`, `security-extended` e `security-and-quality`).\n* Consultas específicas cujos resultados não interessam a você.\n* Todas as consultas que geram avisos e recomendações.\n\nVocê pode usar filtros `exclude` semelhantes aos do arquivo de configuração abaixo para excluir as consultas que deseja remover da análise padrão. No exemplo do arquivo de configuração abaixo, as consultas `js/redundant-assignment` as `js/useless-assignment-to-local` são excluídas da análise.\n\n```yaml copy\nquery-filters:\n - exclude:\n id: js/redundant-assignment\n - exclude:\n id: js/useless-assignment-to-local\n```\n\nPara localizar a ID de uma consulta, clique no alerta na lista de alertas na ** Security and quality** guia. Isso abre a página de detalhes do alerta. O campo `Rule ID` contém a ID da consulta. Para obter mais informações sobre a página de detalhes do alerta, confira [Sobre alertas de digitalização de códigos](/pt/code-security/code-scanning/managing-code-scanning-alerts/about-code-scanning-alerts#about-alert-details).\n\n> \\[!TIP]\n>\n> * A ordem dos filtros faz diferença. A primeira instrução de filtro exibida após as instruções sobre as consultas e os pacotes de consulta determina se as consultas são incluídas ou excluídas por padrão.\n> * As instruções subsequentes são executadas em ordem e as instruções que aparecem posteriormente no arquivo têm precedência sobre as instruções anteriores.\n\nVocê pode encontrar outro exemplo ilustrando o uso desses filtros na seção [Arquivos de configuração de exemplo](#example-configuration-files).\n\nPara obter mais informações sobre como usar os filtros `exclude` e `include` em seu arquivo de configuração personalizado, confira [Como criar conjuntos de consultas do CodeQL](/pt/code-security/codeql-cli/using-the-advanced-functionality-of-the-codeql-cli/creating-codeql-query-suites#filtering-the-queries-in-a-query-suite). Para obter informações sobre os metadados de consulta nos quais você pode filtrar, confira [Metadados para consultas CodeQL](https://codeql.github.com/docs/writing-codeql-queries/metadata-for-codeql-queries/).\n\n### Especificar diretórios para serem varridos\n\nQuando as bases de código são analisadas sem criar o código, você pode restringir code scanning arquivos em diretórios específicos adicionando uma `paths` matriz ao arquivo de configuração. Você também pode excluir os arquivos de diretórios específicos da análise ao adicionar uma matriz `paths-ignore`. Você pode usar essa opção ao executar as CodeQL ações em uma linguagem interpretada (Python, Ruby e JavaScript/TypeScript) ou ao analisar um idioma compilado sem criar o código (atualmente compatível C/C++, C#, Java e Rust).\n\n```yaml copy\npaths:\n - src\npaths-ignore:\n - src/node_modules\n - '**/*.test.js'\n```\n\n> \\[!NOTE]\n>\n> * As palavras-chave `paths` e `paths-ignore`, usadas no contexto do arquivo de configuração code scanning, não devem ser confundidas com as mesmas palavras-chave quando usadas para `on..paths` em um fluxo de trabalho. Quando são usadas para modificar `on.` em um fluxo de trabalho, elas determinam se as ações serão executadas quando alguém modificar o código nos diretórios especificados. Para saber mais, confira [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore).\n> * Os caracteres de padrão de filtro `?`, `+`, `[`, `]` e `!` não têm suporte e serão correspondidos literalmente.\n> *\n\n```\n `**` os caracteres só podem estar no início ou no final de uma linha, ou circundados por barras, e você não pode misturar `**` e outros caracteres. Por exemplo, `foo/**`, `**/foo` e `foo/**/bar` são todas as sintaxes permitidas, mas `**foo` não é. No entanto, você pode usar estrelas únicas junto com outros caracteres, conforme mostrado no exemplo. Você precisará citar qualquer coisa que contenha um caractere `*`.\n```\n\nPara a análise em que o código é criado, se você quiser limitar code scanning a diretórios específicos em seu projeto, especifique as etapas de build apropriadas no fluxo de trabalho. Os comandos que você precisará usar para excluir um diretório da compilação dependerão do seu sistema de compilação. Para saber mais, confira [Verificação de código do CodeQL para linguagens compiladas](/pt/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages#adding-build-steps-for-a-compiled-language).\n\nVocê pode analisar rapidamente pequenas partes de um repositório único quando modifica o código em diretórios específicos. Você precisará excluir os diretórios em suas etapas de build e usar as palavras-chave `paths-ignore` e `paths` para [`on.`](/pt/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore) no seu fluxo de trabalho.\n\n\n\n### Exemplo de arquivos de configuração\n\nEste arquivo de configuração adiciona o conjunto de consulta `security-and-quality` à lista de consultas executadas pelo CodeQL ao fazer a verificação do seu código. Para obter mais informações sobre os conjuntos de consultas disponíveis para uso, consulte [consultas não padrão](#non-default-queries).\n\n```yaml\nname: \"My CodeQL config\"\n\nqueries:\n - uses: security-and-quality\n```\n\nO seguinte arquivo de configuração desabilita as consultas-padrão e especifica um conjunto de consultas personalizadas para serem executadas. Ele também configura o CodeQL para verificar arquivos no diretório *src* (em relação à raiz), com exceção do diretório *src/node\\_modules* e exceto arquivos cujos nomes terminam em *.test.js*. Os arquivos no *src/node\\_modules* e arquivos com nomes que terminam em *.test.js* são, portanto, excluídos da análise.\n\n```yaml\nname: \"My CodeQL config\"\n\ndisable-default-queries: true\n\nqueries:\n - name: Use an in-repository CodeQL pack (run queries in the my-queries directory)\n uses: ./my-queries\n - name: Use an external JavaScript CodeQL pack (run queries from an external repo)\n uses: octo-org/javascript-codeql-pack@main\n - name: Use an external query (run a single query from an external CodeQL pack)\n uses: octo-org/python-codeql-pack/show_ifs.ql@main\n - name: Use a query suite file (run queries from a query suite in this repo)\n uses: ./codeql-packs/complex-python-codeql-pack/rootAndBar.qls\n\npaths:\n - src\npaths-ignore:\n - src/node_modules\n - '**/*.test.js'\n```\n\nO arquivo de configuração a seguir executa apenas consultas que geram alertas de erro de gravidade. A configuração primeiro seleciona todas as consultas padrão, todas as consultas em `./my-queries` e o pacote padrão em `codeql/java-queries`, depois exclui todas as consultas que geram avisos ou recomendações.\n\n```yaml\nqueries:\n - name: Use an in-repository CodeQL query pack (run queries in the my-queries directory)\n uses: ./my-queries\npacks:\n - codeql/java-queries\nquery-filters:\n- exclude:\n problem.severity:\n - warning\n - recommendation\n```\n\n## Detalhes da configuração\n\nSe você preferir especificar detalhes adicionais de configuração no arquivo de fluxo de trabalho, poderá usar o `config` input do comando `init` da ação CodeQL. O valor dessa entrada deve ser uma cadeia de caracteres YAML que siga o formato de arquivo de configuração documentado nos [arquivos de configuração personalizados](#custom-configuration-files) acima.\n\n### Configuração de exemplo\n\nEsta etapa em um GitHub Actions arquivo de fluxo de trabalho usa uma `config` entrada para desabilitar as consultas padrão, adicionar o `security-extended` conjunto de consultas e excluir consultas marcadas com `cwe-020`.\n\n```yaml\n- uses: github/codeql-action/init@v4\n with:\n languages: ${{ matrix.language }}\n config: |\n disable-default-queries: true\n threat-models: local\n queries:\n - uses: security-extended\n query-filters:\n - exclude:\n tags: /cwe-020/\n```\n\nVocê pode usar a mesma abordagem para especificar as opções de configurações válidas no arquivo de fluxo de trabalho.\n\n> \\[!TIP]\n> Você pode compartilhar uma configuração em vários repositórios usando GitHub Actions variáveis. Um benefício dessa abordagem é que você pode atualizar a configuração em um único lugar sem editar o arquivo de fluxo de trabalho.\n>\n> No exemplo a seguir, `vars.CODEQL_CONF` é uma GitHub Actions variável. Seu valor pode ser o conteúdo de qualquer arquivo de configuração válido. Para saber mais, confira [Armazenar informações em variáveis](/pt/actions/learn-github-actions/variables#defining-configuration-variables-for-multiple-workflows).\n>\n> ```yaml\n> - uses: github/codeql-action/init@v4\n> with:\n> languages: ${{ matrix.language }}\n> config: ${{ vars.CODEQL_CONF }}\n> ```\n\n## Idiomas compilados\n\nPara idiomas compilados, você pode decidir como a ação CodeQL cria um CodeQL banco de dados para análise. Para obter informações sobre as opções de build disponíveis, confira [Verificação de código do CodeQL para linguagens compiladas](/pt/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages).\n\n## Carregamento de dados\n\n```\n GitHub pode exibir dados de análise de código gerados externamente por uma ferramenta de terceiros. Carregue os dados da análise de código com a ação `upload-sarif`. Para saber mais, confira [AUTOTITLE](/code-security/code-scanning/integrating-with-code-scanning/uploading-a-sarif-file-to-github).\n```"}