1
0
mirror of synced 2025-12-20 02:19:14 -05:00

Hello git history spelunker!

Are you looking for something? Here is all of the GitHub Docs history in one single commit. Enjoy! 🎉
This commit is contained in:
Vanessa Yuen
2020-09-27 14:10:11 +02:00
parent fa8bb2322f
commit 3df90fc9b8
28386 changed files with 1723440 additions and 3 deletions

View File

@@ -0,0 +1,61 @@
---
title: About code scanning
intro: 'You can use {{ site.data.variables.product.prodname_code_scanning }} to find security vulnerabilities and errors in the code for your project on {{ site.data.variables.product.prodname_dotcom }}.'
product: '{{ site.data.reusables.gated-features.code-scanning }}'
redirect_from:
- /github/managing-security-vulnerabilities/about-automated-code-scanning
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
---
{{ site.data.reusables.code-scanning.beta }}
{{ site.data.reusables.code-scanning.enterprise-enable-code-scanning }}
### About {{ site.data.variables.product.prodname_code_scanning }}
{{ site.data.reusables.code-scanning.about-code-scanning }}
You can use {{ site.data.variables.product.prodname_code_scanning }} to find, triage, and prioritize fixes for existing problems in your code. {{ site.data.variables.product.prodname_code_scanning_capc }} also prevents developers from introducing new problems. You can schedule scans for specific days and times, or trigger scans when a specific event occurs in the repository, such as a push.
If {{ site.data.variables.product.prodname_code_scanning }} finds a potential vulnerability or error in your code, {{ site.data.variables.product.prodname_dotcom }} displays an alert in the repository. After you fix the code that triggered the alert, {{ site.data.variables.product.prodname_dotcom }} closes the alert. For more information, see "[Managing alerts from {{ site.data.variables.product.prodname_code_scanning }}](/github/finding-security-vulnerabilities-and-errors-in-your-code/managing-alerts-from-code-scanning)."
To monitor results from {{ site.data.variables.product.prodname_code_scanning }} across your repositories or your organization, you can use the {{ site.data.variables.product.prodname_code_scanning }} API.
For more information about API endpoints, see "[{{ site.data.variables.product.prodname_code_scanning_capc }}](/v3/code-scanning)."
To get started with {{ site.data.variables.product.prodname_code_scanning }}, see "[Enabling {{ site.data.variables.product.prodname_code_scanning }} for a repository](/github/finding-security-vulnerabilities-and-errors-in-your-code/enabling-code-scanning-for-a-repository)."
### About {{ site.data.variables.product.prodname_codeql }}
You can use {{ site.data.variables.product.prodname_code_scanning }} with {{ site.data.variables.product.prodname_codeql }}, a semantic code analysis engine. {{ site.data.variables.product.prodname_codeql }} treats code as data, allowing you to find potential vulnerabilities in your code with greater confidence than traditional static analyzers.
{{ site.data.variables.product.prodname_ql }} is the query language that powers {{ site.data.variables.product.prodname_codeql }}. {{ site.data.variables.product.prodname_ql }} is an object-oriented logic programming language. {{ site.data.variables.product.company_short }}, language experts, and security researchers create the queries used for {{ site.data.variables.product.prodname_code_scanning }}, and the queries are open source. The community maintains and updates the queries to improve analysis and reduce false positives. For more information, see [{{ site.data.variables.product.prodname_codeql }}](https://securitylab.github.com/tools/codeql) on the GitHub Security Lab website.
{{ site.data.variables.product.prodname_code_scanning_capc }} with {{ site.data.variables.product.prodname_codeql }} supports both compiled and interpreted languages, and can find vulnerabilities and errors in code that's written in the supported languages.
{{ site.data.reusables.code-scanning.supported-languages }}
You can view and contribute to the queries for {{ site.data.variables.product.prodname_code_scanning }} in the [`github/codeql`](https://github.com/github/codeql) repository. For more information, see [{{ site.data.variables.product.prodname_codeql }} queries](https://help.semmle.com/QL/learn-ql/writing-queries/writing-queries.html) in the {{ site.data.variables.product.prodname_codeql }} documentation.
{% if currentVersion == "free-pro-team@latest" %}
### About billing for {{ site.data.variables.product.prodname_code_scanning }}
{{ site.data.variables.product.prodname_code_scanning_capc }} uses {{ site.data.variables.product.prodname_actions }}, and each run of a {{ site.data.variables.product.prodname_code_scanning }} workflow consumes minutes for {{ site.data.variables.product.prodname_actions }}. For more information, see "[About billing for {{ site.data.variables.product.prodname_actions }}](/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions)."
{% endif %}
### About third-party code scanning tools
{{ site.data.reusables.code-scanning.you-can-upload-third-party-analysis }}
{{ site.data.reusables.code-scanning.interoperable-with-tools-that-output-sarif }}
{{ site.data.reusables.code-scanning.get-started-uploading-third-party-data }}
### Further reading
{% if currentVersion == "free-pro-team@latest" %}
- "[About securing your repository](/github/administering-a-repository/about-securing-your-repository)"{% endif %}
- [{{ site.data.variables.product.prodname_security }}](https://securitylab.github.com/)
- [OASIS Static Analysis Results Interchange Format (SARIF) TC](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sarif) on the OASIS Committee website

View File

@@ -0,0 +1,24 @@
---
title: About integration with code scanning
shortTitle: About integration
intro: 'You can perform {{ site.data.variables.product.prodname_code_scanning }} externally and then display the results in {{ site.data.variables.product.prodname_dotcom }}.'
product: '{{ site.data.reusables.gated-features.code-scanning }}'
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
---
{{ site.data.reusables.code-scanning.beta }}
{{ site.data.reusables.code-scanning.enterprise-enable-code-scanning }}
As an alternative to running {{ site.data.variables.product.prodname_code_scanning }} within {{ site.data.variables.product.prodname_dotcom }}, you can perform analysis elsewhere and then upload the results. Alerts for {{ site.data.variables.product.prodname_code_scanning }} that you run externally are displayed in the same way as those for {{ site.data.variables.product.prodname_code_scanning }} that you run within {{ site.data.variables.product.prodname_dotcom }}. For more information, see "[Managing alerts from code scanning](/github/finding-security-vulnerabilities-and-errors-in-your-code/managing-alerts-from-code-scanning)."
You can use your continuous integration or continuous delivery/deployment (CI/CD) system to run {{ site.data.variables.product.prodname_dotcom }}'s {{ site.data.variables.product.prodname_codeql }} analysis and upload the results to {{ site.data.variables.product.prodname_dotcom }}. This is an alternative to using {{ site.data.variables.product.prodname_actions }} to run {{ site.data.variables.product.prodname_codeql }} analysis. For more information, see "[Running code scanning in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/running-code-scanning-in-your-ci-system)."
If you use a third-party static analysis tool that can produce results as Static Analysis Results Interchange Format (SARIF) 2.1.0 data, you can upload this to {{ site.data.variables.product.prodname_dotcom }}. For more information, see "[Uploading a SARIF file to GitHub](/github/finding-security-vulnerabilities-and-errors-in-your-code/uploading-a-sarif-file-to-github)."
### Further reading
* "[About code scanning](/github/finding-security-vulnerabilities-and-errors-in-your-code/about-code-scanning)"
* "[Configuring code scanning in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning-in-your-ci-system)"
* "[SARIF support for code scanning](/github/finding-security-vulnerabilities-and-errors-in-your-code/sarif-support-for-code-scanning)"

View File

@@ -0,0 +1,10 @@
---
title: Automatically scanning your code for vulnerabilities and errors
shortTitle: Scanning automatically
intro: 'You can find vulnerabilities and errors in your project''s code on {{ site.data.variables.product.prodname_dotcom }}, as well as view, triage, understand, and resolve the related {{ site.data.variables.product.prodname_code_scanning }} alerts.'
mapTopic: true
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
---

View File

@@ -0,0 +1,165 @@
---
title: Configuring code scanning in your CI system
shortTitle: Configuring in your CI
intro: 'You can configure how the {{ site.data.variables.product.prodname_codeql_runner }} scans the code in your project and uploads the results to {{ site.data.variables.product.prodname_dotcom }}.'
product: '{{ site.data.reusables.gated-features.code-scanning }}'
miniTocMaxHeadingLevel: 4
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
---
{{ site.data.reusables.code-scanning.beta }}
{{ site.data.reusables.code-scanning.enterprise-enable-code-scanning }}
### About {{ site.data.variables.product.prodname_code_scanning }} configuration in your CI system
To integrate {{ site.data.variables.product.prodname_code_scanning }} into your CI system, you can use the {{ site.data.variables.product.prodname_codeql_runner }}. For more information, see "[Running code scanning in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/running-code-scanning-in-your-ci-system)."
In general, you invoke the {{ site.data.variables.product.prodname_codeql_runner }} as follows.
```
$ /path/to-runner/codeql-runner-OS <COMMAND> <FLAGS>
```
`/path/to-runner/` depends on where you've downloaded the {{ site.data.variables.product.prodname_codeql_runner }} on your CI system. `codeql-runner-OS` depends on the operating system you use.
There are three versions of the {{ site.data.variables.product.prodname_codeql_runner }}, `codeql-runner-linux`, `codeql-runner-macos`, and `codeql-runner-win`, for Linux, macOS, and Windows systems respectively.
To customize the way the {{ site.data.variables.product.prodname_codeql_runner }} scans your code, you can use flags, such as `--languages` and `--queries`, or you can specify custom settings in a separate configuration file.
### Overriding automatic language detection
The {{ site.data.variables.product.prodname_codeql_runner }} automatically detects and scans code written in the supported languages.
{{ site.data.reusables.code-scanning.supported-languages }}
{{ site.data.reusables.code-scanning.specify-language-to-analyze }}
To override automatic language detection, run the `init` command with the `--languages` flag, followed by a comma-separated list of language keywords. The keywords for the supported languages are `cpp`, `csharp`, `go`, `java`, `javascript`, and `python`.
```
$ /path/to-runner/codeql-runner-linux init --languages cpp,java
```
### Running additional queries
{{ site.data.reusables.code-scanning.run-additional-queries }}
{{ site.data.reusables.code-scanning.codeql-query-suites }}
To add one or more queries, pass a comma-separated list of paths to the `--queries` flag of the `init` command. You can also specify additional queries in a configuration file.
If you also are using a configuration file for custom settings, and you are also specifying additional queries with the `--queries` flag, the {{ site.data.variables.product.prodname_codeql_runner }} uses the additional queries specified with the <nobr>`--queries`</nobr> flag instead of any in the configuration file.
If you want to run the combined set of additional queries specified with the flag and in the configuration file, prefix the value passed to <nobr>`--queries`</nobr> with the `+` symbol.
For more information, see "[Using a custom configuration file](#using-a-custom-configuration-file)."
In the following example, the `+` symbol ensures that the {{ site.data.variables.product.prodname_codeql_runner }} uses the additional queries together with any queries specified in the referenced configuration file.
```
$ /path/to-runner/codeql-runner-linux init --config-file .github/codeql/codeql-config.yml
--queries +security-and-quality,octo-org/python-qlpack/show_ifs.ql@main
```
### Using a custom configuration file
Instead of passing additional information to the {{ site.data.variables.product.prodname_codeql_runner }} commands, you can specify custom settings in a separate configuration file.
The configuration file is a YAML file. It uses syntax similar to the workflow syntax for {{ site.data.variables.product.prodname_actions }}, as illustrated in the examples below. For more information, see "[Workflow syntax for {{ site.data.variables.product.prodname_actions }}](/actions/reference/workflow-syntax-for-github-actions)."
Use the `--config-file` flag of the `init` command to specify the configuration file. The value of <nobr>`--config-file`</nobr> is the path to the configuration file that you want to use. This example loads the configuration file _.github/codeql/codeql-config.yml_.
```
$ /path/to-runner/codeql-runner-linux init --config-file .github/codeql/codeql-config.yml
```
#### Example configuration files
{{ site.data.reusables.code-scanning.example-configuration-files }}
### Configuring {{ site.data.variables.product.prodname_code_scanning }} for compiled languages
For the compiled languages C/C++, C#, and Java, {{ site.data.variables.product.prodname_codeql }} builds the code before analyzing it. In contrast to the other compiled languages, {{ site.data.variables.product.prodname_codeql }} analyzes Go without building the code.
For many common build systems, the {{ site.data.variables.product.prodname_codeql_runner }} can build the code automatically. To attempt to build the code automatically, run `autobuild` between the `init` and `analyze` steps. Note that if your repository requires a specific version of a build tool, you may need to install the build tool manually first.
The `autobuild` process only ever attempts to build _one_ compiled language for a repository. The language automatically selected for analysis is the language with the most files. If you want to choose a language explicitly, use the `--language` flag of the `autobuild` command.
```
$ /path/to-runner/codeql-runner-linux autobuild --language csharp
```
If the `autobuild` command can't build your code, you can run the build steps yourself, between the `init` and `analyze` steps. For more information, see "[Running code scanning in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/running-code-scanning-in-your-ci-system#compiled-language-example)."
### Uploading {{ site.data.variables.product.prodname_code_scanning }} data to {{ site.data.variables.product.prodname_dotcom }}
By default, the {{ site.data.variables.product.prodname_codeql_runner }} uploads results from {{ site.data.variables.product.prodname_code_scanning }} when you run the `analyze` command. You can also upload SARIF files separately, by using the `upload` command.
Once you've uploaded the data, {{ site.data.variables.product.prodname_dotcom }} displays the alerts in your repository. For more information, see "[Managing alerts from code scanning](/github/finding-security-vulnerabilities-and-errors-in-your-code/managing-alerts-from-code-scanning#viewing-an-alert)."
### {{ site.data.variables.product.prodname_codeql_runner }} command reference
The {{ site.data.variables.product.prodname_codeql_runner }} supports the following commands and flags.
#### `init`
Initializes the {{ site.data.variables.product.prodname_codeql_runner }} and creates a {{ site.data.variables.product.prodname_codeql }} database for each language to be analyzed.
| Flag | Required | Input value |
| ---- |:--------:| ----------- |
| `--repository` | ✓ | Name of the repository to initialize. |
| `--github-url` | ✓ | URL of the {{ site.data.variables.product.prodname_dotcom }} instance where your repository is hosted. |
| `--github-auth` | ✓ | A {{ site.data.variables.product.prodname_github_apps }} token or personal access token. |
| `--languages` | | Comma-separated list of languages to analyze. By default, the {{ site.data.variables.product.prodname_codeql_runner }} detects and analyzes all supported languages in the repository. |
| `--queries` | | Comma-separated list of additional queries to run, in addition to the default suite of security queries. |
| `--config-file` | | Path to custom configuration file. |
| `--codeql-path` | | Path to a copy of the {{ site.data.variables.product.prodname_codeql }} CLI executable to use. By default, the {{ site.data.variables.product.prodname_codeql_runner }} downloads a copy. |
| `--temp-dir` | | Directory where temporary files are stored. The default is _./codeql-runner_. |
| `--tools-dir` | | Directory where {{ site.data.variables.product.prodname_codeql }} tools and other files are stored between runs. The default is a subdirectory of the home directory. |
| <nobr>`--checkout-path`</nobr> | | The path to the checkout of your repository. The default is the current working directory. |
| `--debug` | | None. Prints more verbose output. |
| `-h`, `--help` | | None. Displays help for the command. |
#### `autobuild`
Attempts to build the code for the compiled languages C/C++, C#, and Java. For those languages, {{ site.data.variables.product.prodname_codeql }} builds the code before analyzing it. Run `autobuild` between the `init` and `analyze` steps.
| Flag | Required | Input value |
| ---- |:--------:| ----------- |
| `--language` | | The language to build. By default, the {{ site.data.variables.product.prodname_codeql_runner }} builds the compiled language with the most files. |
| <nobr>`--temp-dir`</nobr> | | Directory where temporary files are stored. The default is _./codeql-runner_. |
| `--debug` | | None. Prints more verbose output. |
| `-h`, `--help` | | None. Displays help for the command. |
#### `analyze`
Analyzes the code in the {{ site.data.variables.product.prodname_codeql }} databases and uploads results to {{ site.data.variables.product.product_location }}.
| Flag | Required | Input value |
| ---- |:--------:| ----------- |
| `--repository` | ✓ | Name of the repository to analyze. |
| `--commit` | ✓ | SHA of the commit to analyze. In Git and in Azure DevOps, this corresponds to the value of `git rev-parse HEAD`. In Jenkins, this corresponds to `$GIT_COMMIT`. |
| `--ref` | ✓ | Name of the reference to analyze, for example `refs/heads/main`. In Git and in Jenkins, this corresponds to the value of `git symbolic-ref HEAD`. In Azure DevOps, this corresponds to `$(Build.SourceBranch)`. |
| `--github-url` | ✓ | URL of the {{ site.data.variables.product.prodname_dotcom }} instance where your repository is hosted. |
| `--github-auth` | ✓ | A {{ site.data.variables.product.prodname_github_apps }} token or personal access token. |
| <nobr>`--checkout-path`</nobr> | | The path to the checkout of your repository. The default is the current working directory. |
| `--no-upload` | | None. Stops the {{ site.data.variables.product.prodname_codeql_runner }} from uploading the results to {{ site.data.variables.product.product_location }}. |
| `--output-dir` | | Directory where the output SARIF files are stored. The default is in the directory of temporary files. |
| `--temp-dir` | | Directory where temporary files are stored. The default is _./codeql-runner_. |
| `--debug` | | None. Prints more verbose output. |
| `-h`, `--help` | | None. Displays help for the command. |
#### `upload`
Uploads SARIF files to {{ site.data.variables.product.product_location }}.
| Flag | Required | Input value |
| ---- |:--------:| ----------- |
| `--sarif-file` | ✓ | SARIF file to upload, or a directory containing multiple SARIF files. |
| `--repository` | ✓ | Name of the repository that was analyzed. |
| `--commit` | ✓ | SHA of the commit that was analyzed. In Git and in Azure DevOps, this corresponds to the value of `git rev-parse HEAD`. In Jenkins, this corresponds to `$GIT_COMMIT`. |
| `--ref` | ✓ | Name of the reference that was analyzed, for example `refs/heads/main`. In Git and in Jenkins, this corresponds to the value of `git symbolic-ref HEAD`. In Azure DevOps, this corresponds to `$(Build.SourceBranch)`. |
| `--github-url` | ✓ | URL of the {{ site.data.variables.product.prodname_dotcom }} instance where your repository is hosted. |
| `--github-auth` | ✓ | A {{ site.data.variables.product.prodname_github_apps }} token or personal access token. |
| <nobr>`--checkout-path`</nobr> | | The path to the checkout of your repository. The default is the current working directory. |
| `--debug` | | None. Prints more verbose output. |
| `-h`, `--help` | | None. Displays help for the command. |

View File

@@ -0,0 +1,251 @@
---
title: Configuring code scanning
intro: 'You can configure how {{ site.data.variables.product.prodname_dotcom }} scans the code in your project for vulnerabilities and errors.'
product: '{{ site.data.reusables.gated-features.code-scanning }}'
permissions: 'People with write permissions to a repository can configure {{ site.data.variables.product.prodname_code_scanning }} for the repository.'
miniTocMaxHeadingLevel: 4
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
---
{{ site.data.reusables.code-scanning.beta }}
{{ site.data.reusables.code-scanning.enterprise-enable-code-scanning-actions }}
### About {{ site.data.variables.product.prodname_code_scanning }} configuration
You can run {{ site.data.variables.product.prodname_code_scanning }} within {{ site.data.variables.product.product_location }}, using {{ site.data.variables.product.prodname_actions }}, or from your continuous integration (CI) system, using the {{ site.data.variables.product.prodname_codeql_runner }}. For more information about {{ site.data.variables.product.prodname_actions }}, see "[About {{ site.data.variables.product.prodname_actions }}](/actions/getting-started-with-github-actions/about-github-actions)." For more information about the {{ site.data.variables.product.prodname_codeql_runner }}, see "[Running {{ site.data.variables.product.prodname_code_scanning }} in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/running-code-scanning-in-your-ci-system)."
This article relates to running {{ site.data.variables.product.prodname_code_scanning }} within {% if currentVersion ver_gt "enterprise-server@2.21" %}{{ site.data.variables.product.prodname_ghe_server }}{% else %}{{ site.data.variables.product.prodname_dotcom }}{% endif %}.
Before you can configure {{ site.data.variables.product.prodname_code_scanning }} for a repository, you must enable {{ site.data.variables.product.prodname_code_scanning }} by adding a {{ site.data.variables.product.prodname_actions }} workflow to the repository. For more information, see "[Enabling {{ site.data.variables.product.prodname_code_scanning }} for a repository](/github/finding-security-vulnerabilities-and-errors-in-your-code/enabling-code-scanning-for-a-repository)."
{{ site.data.reusables.code-scanning.edit-workflow }}
{{ site.data.variables.product.prodname_codeql }} analysis is just one type of {{ site.data.variables.product.prodname_code_scanning }} you can do in {{ site.data.variables.product.prodname_dotcom }}. {{ site.data.variables.product.prodname_marketplace }}{% if currentVersion ver_gt "enterprise-server@2.21" %} on {{ site.data.variables.product.prodname_dotcom_the_website }}{% endif %} contains other {{ site.data.variables.product.prodname_code_scanning }} workflows you can use. {% if currentVersion == "free-pro-team@latest" %}You can find a selection of these on the "Get started with {{ site.data.variables.product.prodname_code_scanning }}" page, which you can access from the **{% octicon "shield" aria-label="The shield symbol" %} Security** tab.{% endif %} The specific examples given in this article relate to the {{ site.data.variables.product.prodname_codeql_workflow }} file.
### Editing a {{ site.data.variables.product.prodname_code_scanning }} workflow
{{ site.data.variables.product.prodname_dotcom }} saves workflow files in the _.github/workflows_ directory of your repository. You can find a workflow you have enabled by searching for its file name. For example, by default, the workflow file for {{ site.data.variables.product.prodname_codeql }} {{ site.data.variables.product.prodname_code_scanning }} is called _codeql-analysis.yml_.
1. In your repository, browse to the workflow file you want to edit.
1. In the upper right corner of the file view, to open the workflow editor, click {% octicon "pencil" aria-label="The edit icon" %}.
![Edit workflow file button](/assets/images/help/repository/code-scanning-edit-workflow-button.png)
1. 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.
![Commit update to codeql.yml workflow](/assets/images/help/repository/code-scanning-workflow-update.png)
For more information about editing workflow files, see "[Learn {{ site.data.variables.product.prodname_actions }}](/actions/learn-github-actions)."
### Configuring frequency
You can configure the {{ site.data.variables.product.prodname_codeql_workflow }} 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 {{ site.data.variables.product.company_short }}, security researchers, and the community discover, even when developers aren't actively maintaining the repository.
#### Scanning on push
By default, the {{ site.data.variables.product.prodname_codeql_workflow }} 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 {{ site.data.variables.product.prodname_code_scanning }} to be triggered on a specified branch, the workflow must exist in that branch. For more information, see "[Workflow syntax for {{ site.data.variables.product.prodname_actions }}](/actions/reference/workflow-syntax-for-github-actions#on)."
#### Scanning pull requests
The default {{ site.data.variables.product.prodname_codeql_workflow }} uses the `pull_request` event to trigger a code scan on the `HEAD` commit of a pull request against the default branch. {% if currentVersion ver_gt "enterprise-server@2.21" %}The `pull_request` event is not triggered if the pull request was opened from a private fork.{% else %}If a pull request is from a private fork, the `pull_request` event will only be triggered if you've selected the "Run workflows from fork pull requests" option in the repository settings. For more information, see "[Disabling or limiting {{ site.data.variables.product.prodname_actions }} for a repository](/github/administering-a-repository/disabling-or-limiting-github-actions-for-a-repository#enabling-workflows-for-private-repository-forks)."{% endif %}
For more information about the `pull_request` event, see "[Workflow syntax for {{ site.data.variables.product.prodname_actions }}](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestbranchestags)."
#### Scanning on a schedule
If you use the default {{ site.data.variables.product.prodname_codeql_workflow }}, 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 {{ site.data.variables.product.prodname_actions }}](/actions/reference/workflow-syntax-for-github-actions#onschedule)."
{% note %}
**Note**: {{ site.data.variables.product.prodname_dotcom }} 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.
{% endnote %}
#### Example
The following example shows a {{ site.data.variables.product.prodname_codeql_workflow }} for a particular repository that has a default branch called `main` and one protected branch called `protected`.
``` yaml
on:
push:
branches: [main, protected]
pull_request:
branches: [main]
schedule:
- cron: '0 15 * * 0'
```
This workflow scans:
* Every push to the default branch and the protected branch
* Every pull request to the default branch
* The default branch at 3 P.M. every Sunday
### Specifying an operating system
If your code requires a specific operating system to compile, you can configure the operating system in your {{ site.data.variables.product.prodname_codeql_workflow }}. Edit the value of `jobs.analyze.runs-on` to specify the operating system for the machine that runs your {{ site.data.variables.product.prodname_code_scanning }} actions. {% if currentVersion ver_gt "enterprise-server@2.21" %}You specify the operating system by using an appropriate label as the second element in a two-element array, after `self-hosted`.{% else %}
If you choose to use a self-hosted runner for code scanning, you can specify an operating system by using an appropriate label as the second element in a two-element array, after `self-hosted`.{% endif %}
``` yaml
jobs:
analyze:
name: Analyze
runs-on: [self-hosted, ubuntu-latest]
```
{% if currentVersion == "free-pro-team@latest" %}For more information, see "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners)" and "[Adding self-hosted runners](/actions/hosting-your-own-runners/adding-self-hosted-runners)."{% endif %}
{{ site.data.variables.product.prodname_codeql }} {{ site.data.variables.product.prodname_code_scanning }} 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 {% if currentVersion ver_gt "enterprise-server@2.21" %}"[Workflow syntax for GitHub Actions](/actions/reference/workflow-syntax-for-github-actions#self-hosted-runners)" and "[Using labels with self-hosted runners](/actions/hosting-your-own-runners/using-labels-with-self-hosted-runners){% else %}"[Workflow syntax for GitHub Actions](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on){% endif %}."
{% if currentVersion ver_gt "enterprise-server@2.21" %}You must ensure that Git is in the PATH variable on your self-hosted runners.{% else %}If you use a self-hosted runner, you must ensure that Git is in the PATH variable.{% endif %}
### Changing the languages that are analyzed
{{ site.data.variables.product.prodname_codeql }} {{ site.data.variables.product.prodname_code_scanning }} automatically detects code written in the supported languages.
{{ site.data.reusables.code-scanning.supported-languages }}
The default {{ site.data.variables.product.prodname_codeql_workflow }} file contains a build matrix called `language` which lists the languages in your repository that are analyzed. {{ site.data.variables.product.prodname_codeql }} automatically populates this matrix when you add {{ site.data.variables.product.prodname_code_scanning }} to a repository. Using the `language` matrix optimizes {{ site.data.variables.product.prodname_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](/actions/learn-github-actions/managing-complex-workflows#using-a-build-matrix)."
{{ site.data.reusables.code-scanning.specify-language-to-analyze }}
If your workflow uses the `language` matrix then {{ site.data.variables.product.prodname_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 {{ site.data.variables.product.prodname_code_scanning }} was enabled. For example, if the repository initially only contained JavaScript when {{ site.data.variables.product.prodname_code_scanning }} was enabled, and you later added Python code, you will need to add `python` to the matrix.
```yaml
jobs:
analyze:
name: Analyze
...
strategy:
fail-fast: false
matrix:
language: ['javascript', 'python']
```
If your workflow does not contain a matrix called `language`, then {{ site.data.variables.product.prodname_codeql }} is configured to run analysis sequentially. If you don't specify languages in the workflow, {{ site.data.variables.product.prodname_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.
```yaml
- uses: github/codeql-action/init@v1
with:
languages: cpp, csharp, python
```
### Running additional queries
{{ site.data.reusables.code-scanning.run-additional-queries }}
To add one or more queries, add a `with: queries:` entry within the `uses: github/codeql-action/init@v1` section of the workflow.
``` yaml
- uses: github/codeql-action/init@v1
with:
- queries: COMMA-SEPARATED LIST OF PATHS
```
You can also specify query suites in the value of `queries`. Query suites are collections of queries, usually grouped by purpose or language.
{{ site.data.reusables.code-scanning.codeql-query-suites }}
If you are also using a configuration file for custom settings, any additional queries specified in your workflow are used instead of any specified in the configuration file. If you want to run the combined set of additional queries specified here and in the configuration file, prefix the value of `queries` in the workflow with the `+` symbol. For more information, see "[Using a custom configuration file](#using-a-custom-configuration-file)."
In the following example, the `+` symbol ensures that the specified additional queries are used together with any queries specified in the referenced configuration file.
``` yaml
- 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
As an alternative to specifying which queries to run in the workflow file, you can do this in a separate configuration file. You can also use a configuration 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_.
``` yaml
- uses: github/codeql-action/init@v1
with:
config-file: ./.github/codeql/codeql-config.yml
```
The configuration file can be located within the local repository, or in a public, remote repository. For remote repositories, you can use the _owner/repository/file.yml@branch_ syntax. The settings in the 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.
``` yaml
queries:
- uses: ./my-basic-queries/example-query.ql
- uses: ./my-advanced-queries
- uses: ./codeql-qlpacks/complex-python-qlpack/rootAndBar.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](#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 {{ site.data.variables.product.prodname_codeql }} supports (Python and JavaScript/TypeScript), you can restrict {{ site.data.variables.product.prodname_code_scanning }} to files in specific directories by adding a `paths` array to the configuration file. You can exclude the files in specific directories from scans by adding a `paths-ignore` array.
``` yaml
paths:
- src
paths-ignore:
- node_modules
- '**/*.test.js'
```
{% note %}
**Note**:
* The `paths` and `paths-ignore` keywords, used in the context of the {{ site.data.variables.product.prodname_code_scanning }} configuration file, should not be confused with the same keywords when used for `on.<push|pull_request>.paths` in a workflow. When they are used to modify `on.<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 {{ site.data.variables.product.prodname_actions }}](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths)."
* `**` 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`, and `foo/**/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.
{% endnote %}
For C/C++, C#, and Java, if you want to limit {{ site.data.variables.product.prodname_code_scanning }} 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 {{ site.data.variables.product.prodname_codeql }} workflow for compiled languages](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-the-codeql-workflow-for-compiled-languages#adding-build-steps-for-a-compiled-language)."
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>`](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths) in your workflow.
#### Example configuration files
{{ site.data.reusables.code-scanning.example-configuration-files }}
### Configuring {{ site.data.variables.product.prodname_code_scanning }} for compiled languages
{{ site.data.reusables.code-scanning.autobuild-compiled-languages }} In contrast to the other compiled languages, CodeQL can successfully analyze Go without building the code.
{{ site.data.reusables.code-scanning.autobuild-add-build-steps }} For more information about how to configure {{ site.data.variables.product.prodname_codeql }} {{ site.data.variables.product.prodname_code_scanning }} for compiled languages, see "[Configuring the {{ site.data.variables.product.prodname_codeql }} workflow for compiled languages](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-the-codeql-workflow-for-compiled-languages)."
### Accessing private repositories
If your workflow for {{ site.data.variables.product.prodname_code_scanning }} accesses a private repository, other than the repository that contains the workflow, you'll need to configure Git to authenticate with a personal access token. Define the secret in the runner environment by using `jobs.<job_id>.steps.env` in your workflow before any {{ site.data.variables.product.prodname_codeql }} actions. For more information, see "[Creating a personal access token for the command line](/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line)" and "[Creating and storing encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)."
For example, the following configuration has Git replace the full URLs to the `github/foo`, `github/bar`, and `github/baz` repositories on {{ site.data.variables.product.prodname_dotcom_the_website }} with URLs that include the personal access token that you store in the `ACCESS_TOKEN` environment variable.
{% raw %}
```yaml
steps:
- name: Configure access to private repositories
env:
TOKEN: ${{ secrets.ACCESS_TOKEN }}
run: |
git config --global url."https://${TOKEN}@github.com/github/foo".insteadOf "https://github.com/github/foo"
git config --global url."https://${TOKEN}@github.com/github/bar".insteadOf "https://github.com/github/bar"
git config --global url."https://${TOKEN}@github.com/github/baz".insteadOf "https://github.com/github/baz"
```
{% endraw %}
### Uploading {{ site.data.variables.product.prodname_code_scanning }} data to {{ site.data.variables.product.prodname_dotcom }}
{{ site.data.variables.product.prodname_dotcom }} 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](/github/finding-security-vulnerabilities-and-errors-in-your-code/uploading-a-sarif-file-to-github)."

View File

@@ -0,0 +1,111 @@
---
title: Configuring the CodeQL workflow for compiled languages
shortTitle: Configuring for compiled languages
intro: 'You can configure how {{ site.data.variables.product.prodname_dotcom }} uses the {{ site.data.variables.product.prodname_codeql_workflow }} to scan code written in compiled languages for vulnerabilities and errors.'
product: '{{ site.data.reusables.gated-features.code-scanning }}'
permissions: 'People with write permissions to a repository can configure {{ site.data.variables.product.prodname_code_scanning }} for the repository.'
redirect_from:
- /github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning-for-compiled-languages
- /github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-the-codeql-action-for-compiled-languages
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
---
{{ site.data.reusables.code-scanning.beta }}
{{ site.data.reusables.code-scanning.enterprise-enable-code-scanning-actions }}
### About the {{ site.data.variables.product.prodname_codeql_workflow }} and compiled languages
You enable {{ site.data.variables.product.prodname_dotcom }} to run {{ site.data.variables.product.prodname_code_scanning }} for your repository by adding a {{ site.data.variables.product.prodname_actions }} workflow to the repository. For {{ site.data.variables.product.prodname_codeql }} {{ site.data.variables.product.prodname_code_scanning }}, you add the {{ site.data.variables.product.prodname_codeql_workflow }}. For more information, see "[Enabling {{ site.data.variables.product.prodname_code_scanning }} for a repository](/github/finding-security-vulnerabilities-and-errors-in-your-code/enabling-code-scanning-for-a-repository)."
{{ site.data.reusables.code-scanning.edit-workflow }}
For general information about configuring {{ site.data.variables.product.prodname_code_scanning }} and editing workflow files, see "[Configuring {{ site.data.variables.product.prodname_code_scanning }}](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning)" and "[Learn {{ site.data.variables.product.prodname_actions }}](/actions/learn-github-actions)."
### About autobuild for {{ site.data.variables.product.prodname_codeql }}
Code scanning works by running queries against one or more databases. Each database contains a representation of all of the code in a single language in your repository. For the compiled languages C/C++, C#, and Java, the process of populating this database involves building the code and extracting data. In contrast to the other compiled languages, CodeQL can generate a database for Go without building the code.
{{ site.data.reusables.code-scanning.autobuild-compiled-languages }}
If your workflow uses a `language` matrix, `autobuild` attempts to build each of the compiled languages listed in the matrix. Without a matrix `autobuild` attempts to build the supported compiled language that has the most source files in the repository. With the exception of Go, analysis of other compiled languages in your repository will fail unless you supply explicit build commands.
{% note %}
**Note**: If you use self-hosted runners for {{ site.data.variables.product.prodname_actions }}, you may need to install additional software to use the `autobuild` process. Additionally, if your repository requires a specific version of a build tool, you may need to install it manually. For more information, see "[Specifications for {{ site.data.variables.product.prodname_dotcom }}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software)".
{% endnote %}
#### C/C++
| Supported system type | System name |
|----|----|
| Operating system | Windows and Linux |
| Build system | Autoconf, CMake, qmake, Meson, Waf, SCons, and Linux Kbuild |
The behavior of the `autobuild` step varies according to the operating system that the extraction runs on. On Windows, the step has no default actions. On Linux, this step reviews the files present in the repository to determine the build system used:
1. Look for a build system in the root directory.
2. If none are found, search subdirectories for a unique directory with a build system for C/C++.
3. Run an appropriate command to configure the system.
#### C#
| Supported system type | System name |
|----|----|
| Operating system | Windows and Linux |
| Build system | .NET and MSbuild, as well as build scripts |
The `autobuild` process attempts to autodetect a suitable build method for C# using the following approach:
1. Invoke `dotnet build` on the solution (`.sln`) or project (`.csproj`) file closest to the root.
2. Invoke `MSbuild` (Linux) or `MSBuild.exe` (Windows) on the solution or project file closest to the root.
If `autobuild` detects multiple solution or project files at the same (shortest) depth from the top level directory, it will attempt to build all of them.
3. Invoke a script that looks like a build script—_build_ and _build.sh_ (in that order, for Linux) or _build.bat_, _build.cmd_, _and build.exe_ (in that order, for Windows).
#### Java
| Supported system type | System name |
|----|----|
| Operating system | Windows, macOS and Linux (no restriction) |
| Build system | Gradle, Maven and Ant |
The `autobuild` process tries to determine the build system for Java codebases by applying this strategy:
1. Search for a build file in the root directory. Check for Gradle then Maven then Ant build files.
2. Run the first build file found. If both Gradle and Maven files are present, the Gradle file is used.
3. Otherwise, search for build files in direct subdirectories of the root directory. If only one subdirectory contains build files, run the first file identified in that subdirectory (using the same preference as for 1). If more than one subdirectory contains build files, report an error.
### Adding build steps for a compiled language
{{ site.data.reusables.code-scanning.autobuild-add-build-steps }} For information on how to edit the workflow file, see "[Configuring {{ site.data.variables.product.prodname_code_scanning }}](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#editing-a-code-scanning-workflow)."
After removing the `autobuild` step, uncomment the `run` step and add build commands that are suitable for your repository. The workflow `run` step runs command-line programs using the operating system's shell. You can modify these commands and add more commands to customize the build process.
``` yaml
- run: |
make bootstrap
make release
```
For more information about the `run` keyword, see "[Workflow syntax for {{ site.data.variables.product.prodname_actions }}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsrun)."
If your repository contains multiple compiled languages, you can specify language-specific build commands. For example, if your repository contains C/C++, C# and Java, and `autobuild` correctly builds C/C++ and C# but fails to build Java, you could use the following configuration in your workflow, after the `init` step. This specifies build steps for Java while still using `autobuild` for C/C++ and C#:
```yaml
- if: matrix.language == 'cpp' || matrix.language == 'csharp'
name: Autobuild
uses: github/codeql-action/autobuild@v1
- if: matrix.language == 'java'
name: Build Java
run: |
make bootstrap
make release
```
For more information about the `if` conditional, see "[Workflow syntax for GitHub Actions](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsif)."
For more tips and tricks about why `autobuild` won't build your code, see "[Troubleshooting the {{ site.data.variables.product.prodname_codeql }} workflow](/github/finding-security-vulnerabilities-and-errors-in-your-code/troubleshooting-the-codeql-workflow)."
If you added manual build steps for compiled languages and {{ site.data.variables.product.prodname_code_scanning }} is still not working on your repository, contact {{ site.data.variables.contact.contact_support }}.

View File

@@ -0,0 +1,49 @@
---
title: Enabling code scanning for a repository
shortTitle: Enabling code scanning
intro: 'You can enable {{ site.data.variables.product.prodname_code_scanning }} for your project''s repository.'
product: '{{ site.data.reusables.gated-features.code-scanning }}'
permissions: 'People with write permissions to a repository can enable {{ site.data.variables.product.prodname_code_scanning }} for the repository.'
redirect_from:
- /github/managing-security-vulnerabilities/configuring-automated-code-scanning
- /github/finding-security-vulnerabilities-and-errors-in-your-code/enabling-code-scanning
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
---
{{ site.data.reusables.code-scanning.beta }}
{{ site.data.reusables.code-scanning.enterprise-enable-code-scanning-actions }}
### Options for enabling {{ site.data.variables.product.prodname_code_scanning }}
You decide how you generate {{ site.data.variables.product.prodname_code_scanning }} alerts, and which tools you use, at a repository level. {{ site.data.variables.product.product_name }} provides fully integrated support for {{ site.data.variables.product.prodname_codeql }} analysis, and also supports analysis using third-party tools. For more information, see "[About {{ site.data.variables.product.prodname_codeql }}](/github/finding-security-vulnerabilities-and-errors-in-your-code/about-code-scanning#about-codeql)."
{{ site.data.reusables.code-scanning.enabling-options }}
### Enabling {{ site.data.variables.product.prodname_code_scanning }} using actions
{% if currentVersion == "free-pro-team@latest" %}Using actions to run {{ site.data.variables.product.prodname_code_scanning }} will use minutes. For more information, see "[About billing for {{ site.data.variables.product.prodname_actions }}](/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions)."{% endif %}
{{ site.data.reusables.repositories.navigate-to-repo }}
{{ site.data.reusables.repositories.sidebar-security }}
3. To the right of "Code scanning", click **Set up code scanning**.
!["Set up code scanning" button to the right of "Code scanning" in the Security Overview](/assets/images/help/security/overview-set-up-code-scanning.png)
4. Under "Get started with code scanning", click **Set up this workflow** on the {{ site.data.variables.product.prodname_codeql_workflow }} or on a third-party workflow.
!["Set up this workflow" button under "Get started with code scanning" heading](/assets/images/help/repository/code-scanning-set-up-this-workflow.png)
5. Optionally, to customize how {{ site.data.variables.product.prodname_code_scanning }} scans your code, edit the workflow. For more information, see "[Configuring {{ site.data.variables.product.prodname_code_scanning }}](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning)."
6. Use the **Start commit** drop-down, and type a commit message.
![Start commit](/assets/images/help/repository/start-commit-commit-new-file.png)
7. Choose whether you'd like to commit directly to the default branch, or create a new branch and start a pull request.
![Choose where to commit](/assets/images/help/repository/start-commit-choose-where-to-commit.png)
8. Click **Commit new file** or **Propose new file**.
After you commit the workflow file or create a pull request, {{ site.data.variables.product.prodname_code_scanning }} will analyze your code according to the frequency you specified in your workflow file. If you created a pull request, {{ site.data.variables.product.prodname_code_scanning }} will only analyze the code on the pull request's topic branch until you merge the pull request into the default branch of the repository.
### Next steps
After you enable {{ site.data.variables.product.prodname_code_scanning }}, you can monitor analysis, view results, and further customize how you scan your code.
- You can view the run status of {{ site.data.variables.product.prodname_code_scanning }} and get notifications for completed runs. For more information, see "[Managing a workflow run](/actions/configuring-and-managing-workflows/managing-a-workflow-run)" and "[Configuring notifications](/github/managing-subscriptions-and-notifications-on-github/configuring-notifications#github-actions-notification-options)."
- After a scan completes, you can view alerts from a completed scan. For more information, see "[Managing alerts from {{ site.data.variables.product.prodname_code_scanning }}](/github/finding-security-vulnerabilities-and-errors-in-your-code/managing-alerts-from-code-scanning)."
- You can customize how {{ site.data.variables.product.prodname_code_scanning }} scans the code in your repository. For more information, see "[Configuring code scanning](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning)."

View File

@@ -0,0 +1,25 @@
---
title: Finding security vulnerabilities and errors in your code
redirect_from:
- /github/managing-security-vulnerabilities/finding-security-vulnerabilities-in-your-projects-code
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
---
### Table of Contents
{% topic_link_in_list /automatically-scanning-your-code-for-vulnerabilities-and-errors %}
{% link_in_list /about-code-scanning %}
{% link_in_list /enabling-code-scanning-for-a-repository %}
{% link_in_list /managing-alerts-from-code-scanning %}
{% link_in_list /configuring-code-scanning %}
{% link_in_list /configuring-the-codeql-workflow-for-compiled-languages %}
{% link_in_list /troubleshooting-the-codeql-workflow %}
{% topic_link_in_list /integrating-with-code-scanning %}
{% link_in_list /about-integration-with-code-scanning %}
{% link_in_list /running-code-scanning-in-your-ci-system %}
{% link_in_list /configuring-code-scanning-in-your-ci-system %}
{% link_in_list /troubleshooting-code-scanning-in-your-ci-system %}
{% link_in_list /uploading-a-sarif-file-to-github %}
{% link_in_list /sarif-support-for-code-scanning %}

View File

@@ -0,0 +1,12 @@
---
title: Integrating with code scanning
shortTitle: Integration
intro: 'You can integrate {{ site.data.variables.product.prodname_codeql }} {{ site.data.variables.product.prodname_code_scanning }} with your existing CI systems or upload results from other tools.'
mapTopic: true
redirect_from:
- /github/finding-security-vulnerabilities-and-errors-in-your-code/managing-results-from-code-scanning
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
---

View File

@@ -0,0 +1,60 @@
---
title: Managing alerts from code scanning
shortTitle: Managing alerts
intro: 'You can view, fix, and close alerts for potential vulnerabilities or errors in your project''s code.'
product: '{{ site.data.reusables.gated-features.code-scanning }}'
permissions: 'People with write permissions to a repository can manage {{ site.data.variables.product.prodname_code_scanning }} alerts for the repository.'
redirect_from:
- /github/managing-security-vulnerabilities/managing-alerts-from-automated-code-scanning
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
---
{{ site.data.reusables.code-scanning.beta }}
{{ site.data.reusables.code-scanning.enterprise-enable-code-scanning }}
### About alerts from {{ site.data.variables.product.prodname_code_scanning }}
After you enable {{ site.data.variables.product.prodname_code_scanning }}, {{ site.data.variables.product.prodname_dotcom }} displays {{ site.data.variables.product.prodname_code_scanning }} alerts in your repository. For more information, see "[Enabling {{ site.data.variables.product.prodname_code_scanning }} for a repository](/github/finding-security-vulnerabilities-and-errors-in-your-code/enabling-code-scanning-for-a-repository)."
Each alert highlights a problem with the code and the name of the tool that identified it. You can see the line of code that triggered the alert, as well as properties of the alert, such as the severity and the nature of the problem. Alerts also tell you when the issue was first introduced. For alerts identified by {{ site.data.variables.product.prodname_codeql }} analysis, you will also see information on how to fix the problem.
![Example alert from {{ site.data.variables.product.prodname_code_scanning }}](/assets/images/help/repository/code-scanning-alert.png)
If you won't take the action that the alert recommends, you can close the alert manually. For example, you can close an alert for code that's used for testing, or if you believe the alert is a false positive. You might also want to close an alert if the effort of fixing the coding error is greater than the potential benefit of improving the code.
By default, {{ site.data.variables.product.prodname_dotcom }} displays alerts for the default branch and any protected branches. You can sort and filter the list of alerts to see only the alerts you're interested in.
You can see the alerts introduced in a pull request, and take immediate action. When {{ site.data.variables.product.prodname_code_scanning }} finds vulnerabilities or errors in a pull request, {{ site.data.variables.product.prodname_dotcom }} displays annotations in the timeline and the diff views of the pull request.
If you enable {{ site.data.variables.product.prodname_code_scanning }} using {{ site.data.variables.product.prodname_codeql }}, this can also detect data-flow problems in your code. Data-flow analysis finds potential security issues in code, such as: using data insecurely, passing dangerous arguments to functions, and leaking sensitive information.
When {{ site.data.variables.product.prodname_code_scanning }} reports data-flow alerts, {{ site.data.variables.product.prodname_dotcom }} shows you how data moves through the code. {{ site.data.variables.product.prodname_code_scanning_capc }} allows you to identify the areas of your code that leak sensitive information, and that could be the entry point for attacks by malicious users.
{{ site.data.reusables.code-scanning.you-can-upload-third-party-analysis }} {{ site.data.reusables.code-scanning.get-started-uploading-third-party-data }}
If you scan your code using a third-party tool or scan your code with custom {{ site.data.variables.product.prodname_codeql }} queries, {{ site.data.variables.product.prodname_dotcom }} will only use the supported SARIF 2.1.0 properties to display alerts. Results from third-party tools or custom queries may not include all of the properties that you see when you scan your code using {{ site.data.variables.product.company_short }}'s default {{ site.data.variables.product.prodname_codeql }} queries. For more information, see "[SARIF support for {{ site.data.variables.product.prodname_code_scanning }}](/github/finding-security-vulnerabilities-and-errors-in-your-code/sarif-support-for-code-scanning)."
### Viewing an alert
{{ site.data.reusables.repositories.navigate-to-repo }}
{{ site.data.reusables.repositories.sidebar-security }}
{{ site.data.reusables.repositories.sidebar-code-scanning-alerts }}
{{ site.data.reusables.code-scanning.click-alert-in-list }}
5. Optionally, if the alert highlights a problem with data flow, click **Show paths** to review the data's path.
![Example data-flow alert](/assets/images/help/repository/code-scanning-show-paths.png)
### Closing an alert
{{ site.data.reusables.repositories.navigate-to-repo }}
{{ site.data.reusables.repositories.sidebar-security }}
{{ site.data.reusables.repositories.sidebar-code-scanning-alerts }}
{{ site.data.reusables.code-scanning.click-alert-in-list }}
5. Use the "Close" drop-down, and click a reason for closing the alert.
![Choosing reason for closing the alert via the "Close" drop-down](/assets/images/help/repository/code-scanning-alert-close-drop-down.png)
### Further reading
- "[Running code scanning in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/running-code-scanning-in-your-ci-system)"
- "[{{ site.data.variables.product.prodname_code_scanning_capc }} API](/v3/code-scanning)"

View File

@@ -0,0 +1,145 @@
---
title: Running code scanning in your CI system
shortTitle: Running in your CI
intro: 'If you use a third-party continuous integration system, you can integrate {{ site.data.variables.product.prodname_codeql }} {{ site.data.variables.product.prodname_code_scanning }} into this system using the {{ site.data.variables.product.prodname_codeql_runner }}.'
product: '{{ site.data.reusables.gated-features.code-scanning }}'
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
---
{{ site.data.reusables.code-scanning.beta }}
{{ site.data.reusables.code-scanning.enterprise-enable-code-scanning }}
### About the {{ site.data.variables.product.prodname_codeql_runner }}
{{ site.data.reusables.code-scanning.about-code-scanning }} For information, see "[About {{ site.data.variables.product.prodname_code_scanning }}](/github/finding-security-vulnerabilities-and-errors-in-your-code/about-code-scanning)."
You can use the {{ site.data.variables.product.prodname_codeql_runner }} to run {{ site.data.variables.product.prodname_code_scanning }} on code that you're processing in a third-party continuous integration (CI) system. Alternatively, you can use {{ site.data.variables.product.prodname_actions }} to run {{ site.data.variables.product.prodname_code_scanning }} on {{ site.data.variables.product.product_location }}. For information, see "[Enabling {{ site.data.variables.product.prodname_code_scanning }} for a repository](/github/finding-security-vulnerabilities-and-errors-in-your-code/enabling-code-scanning-for-a-repository)."
The {{ site.data.variables.product.prodname_codeql_runner }} is a command-line tool that runs {{ site.data.variables.product.prodname_codeql }} analysis on a checkout of a {{ site.data.variables.product.prodname_dotcom }} repository. You add the runner to your third-party system, then call the runner to analyze code and upload the results to {{ site.data.variables.product.product_location }}. These results are displayed as {{ site.data.variables.product.prodname_code_scanning }} alerts in the repository.
{{ site.data.reusables.code-scanning.codeql-runner-license }}
### Downloading the {{ site.data.variables.product.prodname_codeql_runner }}
You can download the {{ site.data.variables.product.prodname_codeql_runner }} from https://github.com/github/codeql-action/releases. On some operating systems, you may need to change permissions for the downloaded file before you can run it.
On Linux:
```shell
chmod +x codeql-runner-linux
```
On MacOS:
```shell
chmod +x codeql-runner-macos
sudo xattr -d com.apple.quarantine codeql-runner-macos
```
### Adding the {{ site.data.variables.product.prodname_codeql_runner }} to your CI system
Once you have downloaded the {{ site.data.variables.product.prodname_codeql_runner }} and verified that it can be executed, you should make the runner available to each CI server that you intend to use for {{ site.data.variables.product.prodname_code_scanning }}. In addition to this, each CI server also needs:
- A {{ site.data.variables.product.prodname_github_apps }} or personal access token for the {{ site.data.variables.product.prodname_codeql_runner }} to use. For private repositories the token must have the `repo` scope. For public the token needs only the `public_repo` and `repo:security_events` scopes. For information, see "[Building {{ site.data.variables.product.prodname_github_apps }}](/developers/apps/building-github-apps)" and "[Creating a personal access token](/github/authenticating-to-github/creating-a-personal-access-token)."
- Access to the {{ site.data.variables.product.prodname_codeql }} bundle associated with this release of the {{ site.data.variables.product.prodname_codeql_runner }}. This package contains the {{ site.data.variables.product.prodname_codeql }} CLI, queries, and libraries needed for {{ site.data.variables.product.prodname_codeql }} analysis. For information, see "[{{ site.data.variables.product.prodname_codeql }} CLI](https://help.semmle.com/codeql/codeql-cli.html)."
The options for providing access to the {{ site.data.variables.product.prodname_codeql }} bundle are:
1. Allow the CI servers access to {{ site.data.variables.product.prodname_dotcom_the_website }} so that the {{ site.data.variables.product.prodname_codeql_runner }} can download the bundle automatically.
1. Manually download/extract the bundle, store it with other central resources, and use the `--codeql-path` flag to specify the location of the bundle in calls to initialize the {{ site.data.variables.product.prodname_codeql_runner }}.
{% if currentVersion != "free-pro-team@latest" %}
1. You can mirror the `github/codeql-action` repository on {{ site.data.variables.product.product_location }}. Unless you specify the <nobr>`--codeql-path`</nobr> flag, the runner automatically checks for the bundle in this location and on {{ site.data.variables.product.prodname_dotcom_the_website }}.{% endif %}
### Calling the {{ site.data.variables.product.prodname_codeql_runner }}
You should call the {{ site.data.variables.product.prodname_codeql_runner }} from the checkout location of the repository you want to analyze. The two main commands are:
1. `init` required to initialize the runner and create a {{ site.data.variables.product.prodname_codeql }} database for each language to be analyzed. These databases are populated and analyzed by subsequent commands.
1. `analyze` required to populate the {{ site.data.variables.product.prodname_codeql }} databases, analyze them, and upload results to {{ site.data.variables.product.product_location }}.
For both commands, you must specify the URL of {{ site.data.variables.product.product_location }}, the repository *OWNER/NAME*, and the GitHub Apps or personal access token to use for authentication. You also need to specify the location of the CodeQL bundle unless the CI server has access to download it directly from the `github/codeql-action` repository on {{ site.data.variables.product.prodname_dotcom_the_website}}{% if currentVersion != "free-pro-team@latest" %} or mirrored on {{ site.data.variables.product.product_location }}{% endif %}.
You can configure where the {{ site.data.variables.product.prodname_codeql_runner }} stores the CodeQL bundle for future analysis on a server using the <nobr>`--tools-dir`</nobr> flag and where it stores temporary files during analysis using <nobr>`--temp-dir`</nobr>.
To view the command-line reference for the runner, use the `-h` flag. For example, to list all commands run: `codeql-runner-OS -h`, or to list all the flags available for the `init` command run: `codeql-runner-OS init -h` (where `OS` varies according to the executable that you are using). For more information, see "[Configuring {{ site.data.variables.product.prodname_code_scanning }} in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning-in-your-ci-system#codeql-runner-command-reference)."
#### Basic example
This example runs {{ site.data.variables.product.prodname_codeql }} analysis on a Linux CI server for the `octo-org/example-repo` repository hosted on `{{ site.data.variables.command_line.git_url_example }}`. The process is very simple because the repository contains only languages that can be analyzed by {{ site.data.variables.product.prodname_codeql }} directly, without being built (that is, Go, JavaScript, Python, and TypeScript).
1. Check out the repository to analyze.
1. Move into the directory where the repository is checked out.
1. Initialize the {{ site.data.variables.product.prodname_codeql_runner }} and create {{ site.data.variables.product.prodname_codeql }} databases for the languages detected.
```shell
$ /path/to-runner/codeql-runner-linux init --repository octo-org/example-repo
--github-url {{ site.data.variables.command_line.git_url_example }} --github-auth TOKEN
> Cleaning temp directory /srv/checkout/example-repo/codeql-runner
> ...
> Created CodeQL database at /srv/checkout/example-repo/codeql-runner/codeql_databases/javascript.
```
1. Populate the {{ site.data.variables.product.prodname_codeql_runner }} databases, analyze them, and upload the results to {{ site.data.variables.product.product_name }}.
```shell
$ /path/to-runner/codeql-runner-linux analyze --repository octo-org/example-repo
--github-url {{ site.data.variables.command_line.git_url_example }} --github-auth TOKEN
--commit 5b6a3078b31dc346e5ce7b86837d6abbe7a18bbd --ref refs/heads/main
> Finalizing database creation
> ...
> POST /repos/octo-org/example-repo/code-scanning/sarifs - 202 in 786ms
> Successfully uploaded results
```
The server has access to download the {{ site.data.variables.product.prodname_codeql }} bundle directly from the `github/codeql-action` repository on {{ site.data.variables.product.prodname_dotcom_the_website}}{% if currentVersion != "free-pro-team@latest" %} or mirrored on {{ site.data.variables.product.product_location }}{% endif %}, so there is no need to use the `--codeql-path` flag. When the analysis is complete, the {{ site.data.variables.product.prodname_codeql_runner }} uploads the results to the {{ site.data.variables.product.prodname_code_scanning }} view. For more information, see "[Managing alerts from {{ site.data.variables.product.prodname_code_scanning }}](/github/finding-security-vulnerabilities-and-errors-in-your-code/managing-alerts-from-code-scanning)."
#### Compiled language example
This example is similar to the previous example, however this time the repository has code in C/C++, C#, or Java. To create a {{ site.data.variables.product.prodname_codeql }} database for these languages, the CLI needs to trace the build. At the end of the initialization process, the runner reports the command you need to set up the environment before building the code. You need to run this command, before calling the normal CI build process, and then running the `analyze` command.
1. Check out the repository to analyze.
1. Move into the directory where the repository is checked out.
1. Initialize the {{ site.data.variables.product.prodname_codeql_runner }} and create {{ site.data.variables.product.prodname_codeql }} databases for the languages detected.
```shell
$ /path/to-runner/codeql-runner-linux init --repository octo-org/example-repo-2
--github-url {{ site.data.variables.command_line.git_url_example }} --github-auth TOKEN
> Cleaning temp directory /srv/checkout/example-repo-2/codeql-runner
> ...
> CodeQL environment output to "/srv/checkout/example-repo-2/codeql-runner/codeql-env.json"
and "/srv/checkout/example-repo-2/codeql-runner/codeql-env.sh".
Please export these variables to future processes so the build can be traced, for example by running "
. /srv/checkout/example-repo-2/codeql-runner/codeql-env.sh".
```
1. Run the script generated by the `init` action to set up the environment to trace the build.
```shell
$ . /srv/checkout/example-repo-2/codeql-runner/codeql-env.sh
```
1. Build the code.
1. Populate the {{ site.data.variables.product.prodname_codeql }} databases, analyze them, and upload the results to GitHub.
```shell
$ /path/to-runner/codeql-runner-linux analyze --repository octo-org/example-repo-2
--github-url {{ site.data.variables.command_line.git_url_example }} --github-auth TOKEN
--commit ae7b655ef30b50fb726ae7b3daa79571a39d194d --ref refs/heads/main
> Finalizing database creation
> ...
> POST /repos/octo-org/example-repo-2/code-scanning/sarifs - 202 in 573ms
> Successfully uploaded results
```
{% note %}
**Note:** If you use a containerized build, you need to run the {{ site.data.variables.product.prodname_codeql_runner }} in the container where your build task takes place.
{% endnote %}
### Further reading
- "[Configuring {{ site.data.variables.product.prodname_code_scanning }} in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning-in-your-ci-system)"
- "[Troubleshooting {{ site.data.variables.product.prodname_code_scanning }} in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/troubleshooting-code-scanning-in-your-ci-system)"

View File

@@ -0,0 +1,422 @@
---
title: SARIF support for code scanning
shortTitle: SARIF support
intro: 'To display results from a third-party static analysis tool in your repository on {{ site.data.variables.product.prodname_dotcom }}, you''ll need your results stored in a SARIF file that supports a specific subset of the SARIF 2.1.0 JSON schema for code scanning. If you use the default {{ site.data.variables.product.prodname_codeql }} static analysis engine, then your results will display in your repository on {{ site.data.variables.product.prodname_dotcom }} automatically.'
product: '{{ site.data.reusables.gated-features.code-scanning }}'
redirect_from:
- /github/finding-security-vulnerabilities-and-errors-in-your-code/about-sarif-support-for-code-scanning
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
---
{{ site.data.reusables.code-scanning.beta }}
{{ site.data.reusables.code-scanning.enterprise-enable-code-scanning }}
### About SARIF support
SARIF (Static Analysis Results Interchange Format) is an [OASIS Standard](https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html) that defines an output file format. The SARIF standard is used to streamline how static analysis tools share their results. {{ site.data.variables.product.prodname_code_scanning_capc }} supports a subset of the SARIF 2.1.0 JSON schema.
To upload a SARIF file from a third-party static code analysis engine, you'll need to ensure that uploaded files use the SARIF 2.1.0 version. {{ site.data.variables.product.prodname_dotcom }} will parse the SARIF file and show alerts using the results in your repository as a part of the code scanning experience. For more information, see "[Uploading a SARIF file to {{ site.data.variables.product.prodname_dotcom }}](/github/finding-security-vulnerabilities-and-errors-in-your-code/uploading-a-sarif-file-to-github)." For more information about the SARIF 2.1.0 JSON schema, see [`sarif-schema-2.1.0.json`](https://github.com/oasis-tcs/sarif-spec/blob/master/Schemata/sarif-schema-2.1.0.json).
If you're using {{ site.data.variables.product.prodname_actions}} with the {{ site.data.variables.product.prodname_codeql_workflow }} or using the {{ site.data.variables.product.prodname_codeql_runner }}, then the {{ site.data.variables.product.prodname_code_scanning }} results will automatically use the supported subset of SARIF 2.1.0. For more information, see "[Enabling {{ site.data.variables.product.prodname_code_scanning }}](/github/finding-security-vulnerabilities-and-errors-in-your-code/enabling-code-scanning)" or "[Running code scanning in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/running-code-scanning-in-your-ci-system)."
{{ site.data.variables.product.prodname_dotcom }} uses properties in the SARIF file to display alerts. For example, the `shortDescription` and `fullDescription` appear at the top of a {{ site.data.variables.product.prodname_code_scanning }} alert. The `location` allows {{ site.data.variables.product.prodname_dotcom }} to show annotations in your code file. For more information, see "[Managing alerts from {{ site.data.variables.product.prodname_code_scanning }}](/github/finding-security-vulnerabilities-and-errors-in-your-code/managing-alerts-from-code-scanning)."
If you're new to SARIF and want to learn more, see Microsoft's [`SARIF tutorials`](https://github.com/microsoft/sarif-tutorials) repository.
### Preventing duplicate alerts using fingerprints
Each time the results of a new code scan are uploaded, the results are processed and alerts are added to the repository. To prevent duplicate alerts for the same problem, {{ site.data.variables.product.prodname_code_scanning }} uses fingerprints to match results across various runs so they only appear once in the latest run for the selected branch. This makes it possible to match alerts to the right line of code when files are edited.
{{ site.data.variables.product.prodname_dotcom }} uses the `partialFingerprints` property in the OASIS standard to detect when two results are logically identical. For more information, see the "[partialFingerprints property](https://docs.oasis-open.org/sarif/sarif/v2.1.0/cs01/sarif-v2.1.0-cs01.html#_Toc16012611)" entry in the OASIS documentation.
SARIF files created by the {{ site.data.variables.product.prodname_codeql_workflow }} or using the {{ site.data.variables.product.prodname_codeql_runner }} include fingerprint data. If you upload a SARIF file using the `upload-sarif` action and this data is missing, {{ site.data.variables.product.prodname_dotcom }} attempts to populate the `partialFingerprints` field from the source files. For more information about uploading results, see "[Uploading a SARIF file to {{ site.data.variables.product.prodname_dotcom }}](/github/finding-security-vulnerabilities-and-errors-in-your-code/uploading-a-sarif-file-to-github#uploading-a-code-scanning-analysis-with-github-actions)."
If you upload a SARIF file without fingerprint data using the `/code-scanning/sarifs` API endpoint, the code scanning alerts will be processed and displayed, but users may see duplicate alerts. To avoid seeing duplicate alerts, you should calculate fingerprint data and populate the `partialFingerprints` property before you upload the SARIF file. You may find the script that the `upload-sarif` action uses a helpful starting point: https://github.com/github/codeql-action/blob/main/src/fingerprints.ts. For more information about the API, see "[Upload a SARIF file](/rest/reference/code-scanning#upload-a-sarif-file)."
### Validating your SARIF file
You can check a SARIF file is compatible with code scanning by testing it against the GitHub ingestion rules. For more information, visit the [Microsoft SARIF validator](https://sarifweb.azurewebsites.net/).
### Supported SARIF output file properties
If you use a code analysis engine other than {{ site.data.variables.product.prodname_codeql }}, you can review the supported SARIF properties to optimize how your analysis results will appear on {{ site.data.variables.product.prodname_dotcom }}.
Any valid SARIF 2.1.0 output file can be uploaded, however, {{ site.data.variables.product.prodname_code_scanning }} will only use the following supported properties.
#### `sarifLog` object
| Name | Description |
|----|----|
| `$schema` | **Required.** The URI of the SARIF JSON schema for version 2.1.0. For example, `https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json`. |
| `version` | **Required.** {{ site.data.variables.product.prodname_code_scanning_capc }} only supports SARIF version `2.1.0`.
| `runs[]` | **Required.** A SARIF file contains an array of one or more runs. Each run represents a single run of an analysis tool. For more information about a `run`, see the [`run` object](#run-object).
#### `run` object
{{ site.data.variables.product.prodname_code_scanning_capc }} uses the `run` object to filter results by tool and provide information about the source of a result. The `run` object contains the `tool.driver` tool component object, which contains information about the tool that generated the results. Each `run` can only have results for one analysis tool.
| Name | Description |
|----|----|
| `tool.driver.name` | **Required.** The name of the analysis tool. {{ site.data.variables.product.prodname_code_scanning_capc }} displays the name on {{ site.data.variables.product.prodname_dotcom }} to allow you to filter results by tool. |
| `tool.driver.version` | **Optional.** The version of the analysis tool. {{ site.data.variables.product.prodname_code_scanning_capc }} uses the version number to track when results may have changed due to a tool version change rather than a change in the code being analyzed. If the SARIF file includes the `semanticVersion` field, `version` is not used by {{ site.data.variables.product.prodname_code_scanning }}. |
| `tool.driver.semanticVersion` | **Optional.** The version of the analysis tool, specified by the Semantic Versioning 2.0 format. {{ site.data.variables.product.prodname_code_scanning_capc }} uses the version number to track when results may have changed due to a tool version change rather than a change in the code being analyzed. If the SARIF file includes the `semanticVersion` field, `version` is not used by {{ site.data.variables.product.prodname_code_scanning }}. For more information, see "[Semantic Versioning 2.0.0](https://semver.org/)" in the Semantic Versioning documentation. |
| `tool.driver.rules[]` | **Required.** An array of `reportingDescriptor` objects that represent rules. The analysis tool uses rules to find problems in the code being analyzed. For more information, see the [`reportingDescriptor` object](#reportingdescriptor-object). |
| `results[]` | **Required.** The results of the analysis tool. {{ site.data.variables.product.prodname_code_scanning_capc }} displays the results on {{ site.data.variables.product.prodname_dotcom }}. For more information, see the [`result` object](#result-object).
#### `reportingDescriptor` object
| Name | Description |
|----|----|
| `id` | **Required.** A unique identifier for the rule. The `id` is referenced from other parts of the SARIF file and may be used by {{ site.data.variables.product.prodname_code_scanning }} to display URLs on {{ site.data.variables.product.prodname_dotcom }}. |
| `name` | **Optional.** The name of the rule. {{ site.data.variables.product.prodname_code_scanning_capc }} displays the name to allow results to be filtered by rule on {{ site.data.variables.product.prodname_dotcom }}. |
| `shortDescription.text` | **Required.** A concise description of the rule. {{ site.data.variables.product.prodname_code_scanning_capc }} displays the short description on {{ site.data.variables.product.prodname_dotcom }} next to the associated results.
| `fullDescription.text` | **Required.** A description of the rule. {{ site.data.variables.product.prodname_code_scanning_capc }} displays the full description on {{ site.data.variables.product.prodname_dotcom }} next to the associated results. The max number of characters is limited to 1000.
| `defaultConfiguration.level` | **Optional.** Default severity level of the rule. {{ site.data.variables.product.prodname_code_scanning_capc }} uses severity levels to help you understand how critical the result is for a given rule. This value can be overridden by the `level` attribute in the `result` object. For more information, see the [`result` object](#result-object). Default: `warning`.
| `help.text` | **Required.** Documentation for the rule using text format. {{ site.data.variables.product.prodname_code_scanning_capc }} displays this help documentation next to the associated results.
| `help.markdown` | **Recommended.** Documentation for the rule using Markdown format. {{ site.data.variables.product.prodname_code_scanning_capc }} displays this help documentation next to the associated results. When `help.markdown` is available, it is displayed instead of `help.text`.
| `properties.tags[]` | **Optional.** An array of strings. {{ site.data.variables.product.prodname_code_scanning_capc }} uses `tags` to allow you to filter results on {{ site.data.variables.product.prodname_dotcom }}. For example, it is possible to filter to all results that have the tag `security`.
| `properties.precision` | **Recommended.** A string that indicates how often the results indicated by this rule are true. For example, if a rule has a known high false-positive rate, the precision should be `low`. {{ site.data.variables.product.prodname_code_scanning_capc }} orders results by precision on {{ site.data.variables.product.prodname_dotcom }} so that the results with the highest `level`, and highest `precision` are shown first. Can be one of: `very-high`, `high`, `medium`, or `low`.
#### `result` object
| Name | Description |
|----|----|
| `ruleId`| **Optional.** The unique identifier of the rule (`reportingDescriptor.id`). For more information, see the [`reportingDescriptor` object](#reportingdescriptor-object). {{ site.data.variables.product.prodname_code_scanning_capc }} uses the rule identifier to filter results by rule on {{ site.data.variables.product.prodname_dotcom }}.
| `ruleIndex`| **Optional.** The index of the associated rule (`reportingDescriptor` object) in the tool component `rules` array. For more information, see the [`run` object](#run-object).
| `rule`| **Optional.** A reference used to locate the rule (reporting descriptor) for this result. For more information, see the [`reportingDescriptor` object](#reportingdescriptor-object).
| `level`| **Optional.** The severity of the result. This level overrides the default severity defined by the rule. {{ site.data.variables.product.prodname_code_scanning_capc }} uses the level to filter results by severity on {{ site.data.variables.product.prodname_dotcom }}.
| `message.text`| **Required.** A message that describes the result. {{ site.data.variables.product.prodname_code_scanning_capc }} displays the message text as the title of the result. Only the first sentence of the message will be displayed when visible space is limited.
| `locations[]`| **Required.** The set of locations where the result was detected. Only one location should be included unless the problem can only be corrected by making a change at every specified location. **Note:** At least one location is required for {{ site.data.variables.product.prodname_code_scanning }} to display a result. {{ site.data.variables.product.prodname_code_scanning_capc }} will use this property to decide which file to annotate with the result. Only the first value of this array is used. All other values are ignored.
| `partialFingerprints`| **Required.** A set of strings used to track the unique identity of the result. {{ site.data.variables.product.prodname_code_scanning_capc }} uses `partialFingerprints` to accurately identify which results are the same across commits and branches. {{ site.data.variables.product.prodname_code_scanning_capc }} will attempt to use `partialFingerprints` if they exist. If you are uploading third-party SARIF files with the `upload-action`, the action will create `partialFingerprints` for you when they are not included in the SARIF file. For more information, see "[Preventing duplicate alerts using fingerprints](#preventing-duplicate-alerts-using-fingerprints)." **Note:** {{ site.data.variables.product.prodname_code_scanning_capc }} only uses the `primaryLocationLineHash`.
| `codeFlows[].threadFlows[].locations[]`| **Optional.** An array of `location` objects for a `threadFlow` object, which describes the progress of a program through a thread of execution. A `codeFlow` object describes a pattern of code execution used to detect a result. If code flows are provided, {{ site.data.variables.product.prodname_code_scanning }} will expand code flows on {{ site.data.variables.product.prodname_dotcom }} for the relevant result. For more information, see the [`location` object](#location-object).
| `relatedLocations[]`| A set of locations relevant to this result. {{ site.data.variables.product.prodname_code_scanning_capc }} will link to related locations when they are embedded in the result message. For more information, see the [`location` object](#location-object).
| `suppressions[].state`| **Optional.** When the `state` is set to `accepted`, {{ site.data.variables.product.prodname_code_scanning }} will update the state of the result to `Closed` on {{ site.data.variables.product.prodname_dotcom }}.
#### `location` object
A location within a programming artifact, such as a file in the repository or a file that was generated during a build.
| Name | Description |
|----|----|
| `location.id` | **Optional.** A unique identifier that distinguishes this location from all other locations within a single result object.
| `location.physicalLocation` | **Required.** Identifies the artifact and region. For more information, see the [`physicalLocation`](#physicallocation-object).
| `location.message.text` | **Optional.** A message relevant to the location.
#### `physicalLocation` object
| Name | Description |
|----|----|
| `artifactLocation.uri`| **Required.** A URI indicating the location of an artifact, usually a file either in the repository or generated during a build. If the URI is relative, it should be relative to the root of the {{ site.data.variables.product.prodname_dotcom }} repository being analyzed. For example, main.js or src/script.js are relative to the root of the repository. If the URI is absolute, {{ site.data.variables.product.prodname_code_scanning }} can use the URI to checkout the artifact and match up files in the repository. For example, `https://github.com/github/example/blob/00/src/promiseUtils.js`.
| `region.startLine` | **Required.** The line number of the first character in the region.
| `region.startColumn` | **Required.** The column number of the first character in the region.
| `region.endLine` | **Required.** The line number of the last character in the region.
| `region.endColumn` | **Required.** The column number of the character following the end of the region.
### SARIF output file examples
These example SARIF output files show supported properties and example values.
#### Example with minimum required properties
This SARIF output file has example values to show the minimum required properties for {{ site.data.variables.product.prodname_code_scanning }} results to work as expected. If you remove any properties or don't include values, this data will not be displayed correctly or sync on {{ site.data.variables.product.prodname_dotcom }}.
```json
{
"$schema" : "https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json",
"version" : "2.1.0",
"runs" :
[
{
"tool" : {
"driver" : {
"name" : "Tool Name"
}
},
"results" : [ {
"message" : {
"text" : "Result text. This result does not have a rule associated."
},
"locations" : [ {
"physicalLocation" : {
"artifactLocation" : {
"uri" : "src/build.cmd"
},
"region" : {
"startLine" : 2,
"startColumn" : 7,
"endColumn" : 10
}
}
} ],
"partialFingerprints" : {
"primaryLocationLineHash" : "39fa2ee980eb94b0:1"
}
}]
}
]
}
```
#### Example showing all supported SARIF properties
This SARIF output file has example values to show all supported SARIF properties for {{ site.data.variables.product.prodname_code_scanning }}.
```json
{
"$schema": "https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json",
"version": "2.1.0",
"runs": [
{
"tool": {
"driver": {
"name": "Tool Name",
"semanticVersion": "2.0.0",
"rules": [
{
"id": "js/unused-local-variable",
"name": "js/unused-local-variable",
"shortDescription": {
"text": "Unused variable, import, function or class"
},
"fullDescription": {
"text": "Unused variables, imports, functions or classes may be a symptom of a bug and should be examined carefully."
},
"defaultConfiguration": {
"level": "note"
},
"properties": {
"tags": [
"maintainability"
],
"precision": "very-high"
}
},
{
"id": "js/inconsistent-use-of-new",
"name": "js/inconsistent-use-of-new",
"shortDescription": {
"text": "Inconsistent use of 'new'"
},
"fullDescription": {
"text": "If a function is intended to be a constructor, it should always be invoked with 'new'. Otherwise, it should always be invoked as a normal function, that is, without 'new'."
},
"defaultConfiguration": null,
"properties": {
"tags": [
"reliability",
"correctness",
"language-features"
],
"precision": "very-high"
}
}
]
}
},
"results": [
{
"ruleId": "js/unused-local-variable",
"ruleIndex": 0,
"message": {
"text": "Unused variable foo."
},
"locations": [
{
"physicalLocation": {
"artifactLocation": {
"uri": "main.js",
"uriBaseId": "%SRCROOT%",
"index": 0
},
"region": {
"startLine": 2,
"startColumn": 7,
"endColumn": 10
}
}
}
],
"partialFingerprints": {
"primaryLocationLineHash": "39fa2ee980eb94b0:1",
"primaryLocationStartColumnFingerprint": "4"
}
},
{
"ruleId": "js/inconsistent-use-of-new",
"ruleIndex": 1,
"message": {
"text": "Function resolvingPromise is sometimes invoked as a constructor (for example [here](1)), and sometimes as a normal function (for example [here](2))."
},
"locations": [
{
"physicalLocation": {
"artifactLocation": {
"uri": "https://github.com/github/example/blob/0000000000000000000000000000000000000000/src/promiseUtils.js",
"index": 1
},
"region": {
"startLine": 2
}
}
}
],
"partialFingerprints": {
"primaryLocationLineHash": "5061c3315a741b7d:1",
"primaryLocationStartColumnFingerprint": "7"
},
"relatedLocations": [
{
"id": 1,
"physicalLocation": {
"artifactLocation": {
"uri": "src/ParseObject.js",
"uriBaseId": "%SRCROOT%",
"index": 3
},
"region": {
"startLine": 2281,
"startColumn": 33,
"endColumn": 55
}
},
"message": {
"text": "here"
}
},
{
"id": 2,
"physicalLocation": {
"artifactLocation": {
"uri": "src/LiveQueryClient.js",
"uriBaseId": "%SRCROOT%",
"index": 2
},
"region": {
"startLine": 166
}
},
"message": {
"text": "here"
}
}
]
},
{
"message": {
"text": "Specifying both [ruleIndex](1) and [ruleID](2) might lead to inconsistencies."
},
"level": "error",
"locations": [
{
"physicalLocation": {
"artifactLocation": {
"uri": "full.sarif",
"uriBaseId": "%SRCROOT%",
"index": 0
},
"region": {
"startLine": 54,
"startColumn": 10,
"endLine": 55,
"endColumn": 25
}
}
}
],
"relatedLocations": [
{
"id": 1,
"physicalLocation": {
"artifactLocation": {
"uri": "full.sarif"
},
"region": {
"startLine": 81,
"startColumn": 10,
"endColumn": 18
}
},
"message": {
"text": "here"
}
},
{
"id": 2,
"physicalLocation": {
"artifactLocation": {
"uri": "full.sarif"
},
"region": {
"startLine": 82,
"startColumn": 10,
"endColumn": 21
}
},
"message": {
"text": "here"
}
}
],
"codeFlows": [
{
"threadFlows": [
{
"locations": [
{
"location": {
"physicalLocation": {
"region": {
"startLine": 11,
"endLine": 29,
"startColumn": 10,
"endColumn": 18
},
"artifactLocation": {
"uriBaseId": "%SRCROOT%",
"uri": "full.sarif"
}
},
"message": {
"text": "Rule has index 0"
}
}
},
{
"location": {
"physicalLocation": {
"region": {
"endColumn": 47,
"startColumn": 12,
"startLine": 12
},
"artifactLocation": {
"uriBaseId": "%SRCROOT%",
"uri": "full.sarif"
}
}
}
}
]
}
]
}
],
"partialFingerprints": {
"primaryLocationLineHash": "ABC:2"
}
}
],
"newlineSequences": [
"\r\n",
"\n",
"",
""
],
"columnKind": "utf16CodeUnits"
}
]
}
```

View File

@@ -0,0 +1,31 @@
---
title: Troubleshooting code scanning in your CI system
shortTitle: Troubleshooting in your CI
intro: 'If you''re having problems with the {{ site.data.variables.product.prodname_codeql_runner }}, you can troubleshoot by using these tips.'
product: '{{ site.data.reusables.gated-features.code-scanning }}'
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
---
{{ site.data.reusables.code-scanning.beta }}
{{ site.data.reusables.code-scanning.enterprise-enable-code-scanning }}
### The `init` command takes too long
Before the {{ site.data.variables.product.prodname_codeql_runner }} can build and analyze code, it needs access to the {{ site.data.variables.product.prodname_codeql }} bundle, which contains the {{ site.data.variables.product.prodname_codeql }} CLI and the {{ site.data.variables.product.prodname_codeql }} libraries.
When you use the {{ site.data.variables.product.prodname_codeql_runner }} for the first time on your machine, the `init` command downloads the {{ site.data.variables.product.prodname_codeql }} bundle to your machine. This download can take a few minutes.
The {{ site.data.variables.product.prodname_codeql }} bundle is cached between runs, so if you use the {{ site.data.variables.product.prodname_codeql_runner }} again on the same machine, it won't download the {{ site.data.variables.product.prodname_codeql }} bundle again.
To avoid this automatic download, you can manually download the {{ site.data.variables.product.prodname_codeql }} bundle to your machine and specify the path using the `--codeql-path` flag of the `init` command.
### No code found during the build
If the `analyze` command for the {{ site.data.variables.product.prodname_codeql_runner }} fails with an error `No source code was seen during the build`, this indicates that {{ site.data.variables.product.prodname_codeql }} was unable to trace your code. Several reasons can explain such a failure.
1. Automatic language detection identified a supported language, but there is no analyzable code of that language in the repository. A typical example is when our language detection service finds a file associated with a particular programming language like a `.h`, or `.gyp` file, but no corresponding executable code is present in the repository. To solve the problem, you can manually define the languages you want to analyze by using the `--languages` flag of the `init` command. For more information, see "[Configuring {{ site.data.variables.product.prodname_code_scanning }} in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning-in-your-ci-system)."
1. You're analyzing a compiled language without using the `autobuild` command and you run the build steps yourself after the `init` step. For the build to work, you must set up the environment such that the {{ site.data.variables.product.prodname_codeql_runner }} can trace the code. The `init` command generates instructions for how to export the required environment variables, so you can copy and run the script. For more information, see "[Running {{ site.data.variables.product.prodname_code_scanning }} in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/running-code-scanning-in-your-ci-system#compiled-language-example)."
1. The code is built in a container or on a separate machine. If you use a containerized build or if you outsource the build to another machine, make sure to run the {{ site.data.variables.product.prodname_codeql_runner }} in the container or on the machine where your build task takes place.

View File

@@ -0,0 +1,116 @@
---
title: Troubleshooting the CodeQL workflow
shortTitle: Troubleshooting CodeQL
intro: 'If you''re having problems with {{ site.data.variables.product.prodname_code_scanning }}, you can troubleshoot by using these tips for resolving issues.'
product: '{{ site.data.reusables.gated-features.code-scanning }}'
redirect_from:
- /github/finding-security-vulnerabilities-and-errors-in-your-code/troubleshooting-code-scanning
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
---
{{ site.data.reusables.code-scanning.beta }}
{{ site.data.reusables.code-scanning.enterprise-enable-code-scanning-actions }}
### Automatic build for a compiled language fails
If an automatic build of code for a compiled language within your project fails, try the following troubleshooting steps.
- Remove the `autobuild` step from your {{ site.data.variables.product.prodname_code_scanning }} workflow and add specific build steps. For information about editing the workflow, see "[Configuring {{ site.data.variables.product.prodname_code_scanning }}](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#editing-a-code-scanning-workflow)." For more information about replacing the `autobuild` step, see "[Configuring the {{ site.data.variables.product.prodname_codeql }} workflow for compiled languages](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-the-codeql-workflow-for-compiled-languages#adding-build-steps-for-a-compiled-language)."
- If your workflow doesn't explicitly specify the languages to analyze, {{ site.data.variables.product.prodname_codeql }} implicitly detects the supported languages in your code base. In this configuration, out of the compiled languages C/C++, C#, and Java, {{ site.data.variables.product.prodname_codeql }} only analyzes the language with the most source files. Edit the workflow and add a build matrix specifying the languages you want to analyze. The default CodeQL analysis workflow uses such a matrix.
The following extracts from a workflow show how you can use a matrix within the job strategy to specify languages, and then reference each language within the "Initialize {{ site.data.variables.product.prodname_codeql }}" step:
```yaml
jobs:
analyze:
...
strategy:
fail-fast: false
matrix:
language: ['csharp', 'cpp', 'javascript']
...
- name: Initialize {{ site.data.variables.product.prodname_codeql }}
uses: github/codeql-action/init@v1
with:
languages: {% raw %}${{ matrix.language }}{% endraw %}
```
For more information about editing the workflow, see "[Configuring code scanning](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning)."
### No code found during the build
If your workflow fails with an error `No source code was seen during the build` or `The process '/opt/hostedtoolcache/CodeQL/0.0.0-20200630/x64/codeql/codeql' failed with exit code 32`, this indicates that {{ site.data.variables.product.prodname_codeql }} was unable to trace your code. Several reasons can explain such a failure:
1. Automatic language detection identified a supported language, but there is no analyzable code of that language in the repository. A typical example is when our language detection service finds a file associated with a particular programming language like a `.h`, or `.gyp` file, but no corresponding executable code is present in the repository. To solve the problem, you can manually define the languages you want to analyze by updating the list of languages in the `language` matrix. For example, the following configuration will analyze only Go, and JavaScript.
```yaml
strategy:
fail-fast: false
matrix:
# Override automatic language detection by changing the list below
# Supported options are:
# ['csharp', 'cpp', 'go', 'java', 'javascript', 'python']
language: ['go', 'javascript']
```
1. Your {{ site.data.variables.product.prodname_code_scanning }} workflow is analyzing a compiled language (C, C++, C#, or Java), but the code was not compiled. By default, the {{ site.data.variables.product.prodname_codeql }} analysis workflow contains an `autobuild` step, however, this step represents a best effort process, and may not succeed in building your code, depending on your specific build environment. Compilation may also fail if you have removed the `autobuild` step and did not include build steps manually. For more information about specifying build steps, see "[Configuring the {{ site.data.variables.product.prodname_codeql }} workflow for compiled languages](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-the-codeql-workflow-for-compiled-languages#adding-build-steps-for-a-compiled-language)."
1. Your workflow is analyzing a compiled language (C, C++, C#, or Java), but portions of your build are cached to improve performance (most likely to occur with build systems like Gradle or Bazel). Since {{ site.data.variables.product.prodname_codeql }} observes the activity of the compiler to understand the data flows in a repository, {{ site.data.variables.product.prodname_codeql }} requires a complete build to take place in order to perform analysis.
1. Your workflow is analyzing a compiled language (C, C++, C#, or Java), but compilation does not occur between the `init` and `analyze` steps in the workflow. {{ site.data.variables.product.prodname_codeql }} requires that your build happens in between these two steps in order to observe the activity of the compiler and perform analysis.
1. Your compiled code (in C, C++, C#, or Java) was compiled successfully, but {{ site.data.variables.product.prodname_codeql }} was unable to detect the compiler invocations. The most common causes are certain configuration options like running your build process in a container, if you're building using a distributed build system external to {{ site.data.variables.product.prodname_actions }} using a daemon process, or if {{ site.data.variables.product.prodname_codeql }} isn't aware of the specific compiler you are using.
For C# projects using either `dotnet build` or `msbuild` which target .NET Core 2, you should specify `/p:UseSharedCompilation=false` in your workflow's `run` step, when you build your code. The `UseSharedCompilation` flag isn't necessary for .NET Core 3.0 and later.
For example, the following configuration for C# will pass the flag during the first build step.
``` yaml
- run: |
dotnet build /p:UseSharedCompilation=false
```
If you encounter another problem with your specific compiler or configuration, contact {{ site.data.variables.contact.contact_support }}.
For more information about specifying build steps, see "[Configuring the {{ site.data.variables.product.prodname_codeql }} workflow for compiled languages](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-the-codeql-workflow-for-compiled-languages#adding-build-steps-for-a-compiled-language)."
### Portions of my repository were not analyzed using `autobuild`
The {{ site.data.variables.product.prodname_codeql }} `autobuild` feature uses heuristics to build the code in a repository, however, sometimes this approach results in incomplete analysis of a repository. For example, when multiple `build.sh` commands exist in a single repository, the analysis may not complete since the `autobuild` step will only execute one of the commands. The solution is to replace the `autobuild` step with build steps which build all of the source code which you wish to analyze. For more information, see "[Configuring the {{ site.data.variables.product.prodname_codeql }} workflow for compiled languages](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-the-codeql-workflow-for-compiled-languages#adding-build-steps-for-a-compiled-language)."
### Error: "Server error"
If the run of a workflow for {{ site.data.variables.product.prodname_code_scanning }} fails due to a server error, try running the workflow again. If the problem persists, contact {{ site.data.variables.contact.contact_support }}.
### Error: "Out of disk" or "Out of memory"
On very large projects, {{ site.data.variables.product.prodname_codeql }} may run out of disk or memory on the runner.
{% if currentVersion == "free-pro-team@latest" %}If you encounter this issue on a hosted {{ site.data.variables.product.prodname_actions }} runner, contact {{ site.data.variables.contact.contact_support }} so that we can investigate the problem.
{% else %}If you encounter this issue, try increasing the memory on the runner.{% endif %}
### The build takes too long
If your build with {{ site.data.variables.product.prodname_codeql }} analysis takes too long to run, there are several approaches you can try to reduce the build time.
#### Increase the memory or cores
If you use self-hosted runners to run {{ site.data.variables.product.prodname_codeql }} analysis, you can increase the memory or the number of cores on those runners.
#### Use matrix builds to parallelize the analysis
The default {{ site.data.variables.product.prodname_codeql_workflow }} uses a build matrix of languages, which causes the analysis of each language to run in parallel. If you have specified the languages you want to analyze directly in the "Initialize CodeQL" step, analysis of each language will happen sequentially. To speed up analysis of multiple languages, modify your workflow to use a matrix. For more information, see "[Managing complex workflows](/actions/learn-github-actions/managing-complex-workflows/#using-a-build-matrix)."
#### Reduce the amount of code being analyzed in a single workflow
Analysis time is typically proportional to the amount of code being analyzed. You can reduce the analysis time by reducing the amount of code being analyzed at once, for example, by excluding test code, or breaking analysis into multiple workflows that analyze only a subset of your code at a time.
For compiled languages like Java, C, C++, and C#, {{ site.data.variables.product.prodname_codeql }} analyzes all of the code which was built during the workflow run. To limit the amount of code being analyzed, build only the code which you wish to analyze by specifying your own build steps in a `run` block. You can combine specifying your own build steps with using the `paths` or `paths-ignore` filters on the `pull_request` and `push` events to ensure that your workflow only runs when specific code is changed. For more information, see "[Workflow syntax for {{ site.data.variables.product.prodname_actions }}](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths)."
For interpreted languages like Go, JavaScript, Python, and TypeScript, that {{ site.data.variables.product.prodname_codeql }} analyzes without a specific build, you can specify additional configuration options to limit the amount of code to analyze. For more information, see "[Specifying directories to scan](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#specifying-directories-to-scan)."
If you split your analysis into multiple workflows as described above, we still recommend that you have at least one workflow which runs on a `schedule` which analyzes all of the code in your repository. Because {{ site.data.variables.product.prodname_codeql }} analyzes data flows between components, some complex security behaviors may only be detected on a complete build.
#### Run only during a `schedule` event
If your analysis is still too slow to be run during `push` or `pull_request` events, then you may want to only trigger analysis on the `schedule` event. For more information, see "[Events](/actions/learn-github-actions/introduction-to-github-actions#events)."

View File

@@ -0,0 +1,114 @@
---
title: Uploading a SARIF file to GitHub
shortTitle: Uploading a SARIF file
intro: '{{ site.data.reusables.code-scanning.you-can-upload-third-party-analysis }}'
permissions: 'People with write permissions to a repository can upload {{ site.data.variables.product.prodname_code_scanning }} data generated outside {{ site.data.variables.product.prodname_dotcom }}.'
product: '{{ site.data.reusables.gated-features.code-scanning }}'
redirect_from:
- /github/managing-security-vulnerabilities/uploading-a-code-scanning-analysis-to-github
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
---
{{ site.data.reusables.code-scanning.beta }}
{{ site.data.reusables.code-scanning.enterprise-enable-code-scanning }}
### About SARIF file uploads for {{ site.data.variables.product.prodname_code_scanning }}
{{ site.data.variables.product.prodname_dotcom }} creates {{ site.data.variables.product.prodname_code_scanning }} alerts in a repository using information from Static Analysis Results Interchange Format (SARIF) files. SARIF files can be uploaded to a repository using the API or {{ site.data.variables.product.prodname_actions }}. For more information, see "[Managing alerts from {{ site.data.variables.product.prodname_code_scanning }}](/github/finding-security-vulnerabilities-and-errors-in-your-code/managing-alerts-from-code-scanning)."
You can generate SARIF files using many static analysis security testing tools, including {{ site.data.variables.product.prodname_codeql }}. The results must use SARIF version 2.1.0. For more information, see "[About SARIF support for {{ site.data.variables.product.prodname_code_scanning }}](/github/finding-security-vulnerabilities-and-errors-in-your-code/about-sarif-support-for-code-scanning)."
You can upload the results using {{ site.data.variables.product.prodname_actions }}{% if currentVersion == "enterprise-server@2.22" %} (available if your organization is taking part in the beta program){% endif %}, the {{ site.data.variables.product.prodname_code_scanning }} API, or the {{ site.data.variables.product.prodname_codeql_runner }}. The best upload method will depend on how you generate the SARIF file, for example, if you use:
- {{ site.data.variables.product.prodname_actions }} to run the {{ site.data.variables.product.prodname_codeql }} action, there is no further action required. The {{ site.data.variables.product.prodname_codeql }} action uploads the SARIF file automatically when it completes analysis.
- {{ site.data.variables.product.prodname_actions }} to run a SARIF-compatible analysis tool, you could update the workflow to include a final step that uploads the results (see below).
- The {{ site.data.variables.product.prodname_codeql_runner }}, to run {{ site.data.variables.product.prodname_code_scanning }} in your CI system, by default the runner automatically uploads results to {{ site.data.variables.product.prodname_dotcom }} on completion. If you block the automatic upload, when you are ready to upload results you can use the `upload` command (for more information, see "[Running {{ site.data.variables.product.prodname_code_scanning }} in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/running-code-scanning-in-your-ci-system)").
- A tool that generates results as an artifact outside of your repository, you can use the {{ site.data.variables.product.prodname_code_scanning }} API to upload the file (for more information, see "[Upload a SARIF file](/rest/reference/code-scanning#upload-a-sarif-file)").
### Uploading a {{ site.data.variables.product.prodname_code_scanning }} analysis with {{ site.data.variables.product.prodname_actions }}
To use {{ site.data.variables.product.prodname_actions }} to upload a third-party SARIF file to a repository, you'll need a workflow. For more information, see "[Learn {{ site.data.variables.product.prodname_actions }}](/actions/getting-started-with-github-actions/about-github-actions)" and "[Learn {{ site.data.variables.product.prodname_actions }}](/actions/learn-github-actions)."
Your workflow will need to use the `upload-sarif` action, which is part of the `github/codeql-action` repository. It has input parameters that you can use to configure the upload. The main input parameter you'll use is `sarif-file`, which configures the file or directory of SARIF files to be uploaded. The directory or file path is relative to the root of the repository. For more information see the [`upload-sarif` action](https://github.com/github/codeql-action/tree/HEAD/upload-sarif).
The `upload-sarif` action can be configured to run when the `push` and `scheduled` event occur. For more information about {{ site.data.variables.product.prodname_actions }} events, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows)."
If your SARIF file doesn't include `partialFingerprints`, the `upload-sarif` action will calculate the `partialFingerprints` field for you and attempt to prevent duplicate alerts. {{ site.data.variables.product.prodname_dotcom }} can only create `partialFingerprints` when the repository contains both the SARIF file and the source code used in the static analysis. For more information about preventing duplicate alerts, see "[About SARIF support for code scanning](/github/finding-security-vulnerabilities-and-errors-in-your-code/about-sarif-support-for-code-scanning#preventing-duplicate-alerts-using-fingerprints)."
#### Example workflow for SARIF files generated outside of a repository
You can create a new workflow that uploads SARIF files after you commit them to your repository. This is useful when the SARIF file is generated as an artifact outside of your repository.
This example workflow runs anytime commits are pushed to the repository. The action uses the `partialFingerprints` property to determine if changes have occurred. In addition to running when commits are pushed, the workflow is scheduled to run once per week. For more information, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows)."
This workflow uploads the `results.sarif` file located in the root of the repository. For more information about creating a workflow file, see "[Learn {{ site.data.variables.product.prodname_actions }}](/actions/learn-github-actions)."
Alternatively, you could modify this workflow to upload a directory of SARIF files. For example, you could place all SARIF files in a directory in the root of your repository called `sarif-output` and set the action's input parameter `sarif_file` to `sarif-output`.
```yaml
name: "Upload SARIF"
# Run workflow each time code is pushed to your repository and on a schedule.
# The scheduled workflow runs every at 00:00 on Sunday UTC time.
on:
push:
schedule:
- cron: '0 0 * * 0'
jobs:
build:
runs-on: ubuntu-latest
steps:
# This step checks out a copy of your repository.
- name: Checkout repository
uses: actions/checkout@v2
- name: Upload SARIF file
uses: github/codeql-action/upload-sarif@v1
with:
# Path to SARIF file relative to the root of the repository
sarif_file: results.sarif
```
#### Example workflow that runs the ESLint analysis tool
If you generate your third-party SARIF file as part of a continuous integration (CI) workflow, you can add the `upload-sarif` action as a step after running your CI tests. If you don't already have a CI workflow, you can create one using a {{ site.data.variables.product.prodname_actions }} template. For more information, see the "[{{ site.data.variables.product.prodname_actions }} quickstart](/actions/quickstart)."
This example workflow runs anytime commits are pushed to the repository. The action uses the `partialFingerprints` property to determine if changes have occurred. In addition to running when commits are pushed, the workflow is scheduled to run once per week. For more information, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows)."
The workflow shows an example of running the ESLint static analysis tool as a step in a workflow. The `Run ESLint` step runs the ESLint tool and outputs the `results.sarif` file. The workflow then uploads the `results.sarif` file to {{ site.data.variables.product.prodname_dotcom }} using the `upload-sarif` action. For more information about creating a workflow file, see "[Introduction to GitHub Actions](/actions/learn-github-actions/introduction-to-github-actions)."
```yml
name: "ESLint analysis"
# Run workflow each time code is pushed to your repository and on a schedule.
# The scheduled workflow runs every at 00:00 on Sunday UTC time.
on:
push:
schedule:
- cron: '0 0 * * 0'
jobs:
build:
steps:
- uses: actions/checkout@v2
- name: Run npm install
run: npm install
# Runs the ESlint code analysis
- name: Run ESLint
# eslint exits 1 if it finds anything to report
run: node_modules/.bin/eslint build docs lib script spec-main -f node_modules/@microsoft/eslint-formatter-sarif/sarif.js -o results.sarif || true
# Uploads results.sarif to GitHub repository using the upload-sarif action
- uses: github/codeql-action/upload-sarif@v1
with:
# Path to SARIF file relative to the root of the repository
sarif_file: results.sarif
```
### Further reading
- "[Workflow syntax for {{ site.data.variables.product.prodname_actions }}](/actions/reference/workflow-syntax-for-github-actions)"
- "[Viewing your workflow history](/actions/managing-workflow-runs/viewing-workflow-run-history)"
- "[Running {{ site.data.variables.product.prodname_code_scanning }} in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/running-code-scanning-in-your-ci-system)"
- "[Upload a SARIF file](/rest/reference/code-scanning#upload-a-sarif-file)"