updating content files
This commit is contained in:
@@ -14,7 +14,7 @@ redirect_from:
|
||||
{% data reusables.code-scanning.beta %}
|
||||
{% data reusables.code-scanning.enterprise-enable-code-scanning %}
|
||||
|
||||
### About {% data variables.product.prodname_code_scanning %}
|
||||
## About {% data variables.product.prodname_code_scanning %}
|
||||
|
||||
{% data reusables.code-scanning.about-code-scanning %}
|
||||
|
||||
@@ -27,7 +27,7 @@ To monitor results from {% data variables.product.prodname_code_scanning %} acro
|
||||
|
||||
To get started with {% data variables.product.prodname_code_scanning %}, see "[Setting up {% data variables.product.prodname_code_scanning %} for a repository](/github/finding-security-vulnerabilities-and-errors-in-your-code/setting-up-code-scanning-for-a-repository)."
|
||||
|
||||
### About {% data variables.product.prodname_codeql %}
|
||||
## About {% data variables.product.prodname_codeql %}
|
||||
|
||||
You can use {% data variables.product.prodname_code_scanning %} with {% data variables.product.prodname_codeql %}, a semantic code analysis engine. {% 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.
|
||||
|
||||
@@ -39,7 +39,7 @@ You can use {% data variables.product.prodname_code_scanning %} with {% data var
|
||||
|
||||
You can view and contribute to the queries for {% data variables.product.prodname_code_scanning %} in the [`github/codeql`](https://github.com/github/codeql) repository. For more information, see [{% data variables.product.prodname_codeql %} queries](https://codeql.github.com/docs/writing-codeql-queries/codeql-queries/) in the {% data variables.product.prodname_codeql %} documentation.
|
||||
|
||||
### About third-party code scanning tools
|
||||
## About third-party code scanning tools
|
||||
|
||||
{% data reusables.code-scanning.you-can-upload-third-party-analysis %}
|
||||
|
||||
@@ -47,7 +47,7 @@ You can view and contribute to the queries for {% data variables.product.prodnam
|
||||
|
||||
{% data reusables.code-scanning.get-started-uploading-third-party-data %}
|
||||
|
||||
### Further reading
|
||||
## Further reading
|
||||
|
||||
- [{% 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
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Configuring code scanning
|
||||
intro: 'You can configure how {% data variables.product.prodname_dotcom %} scans the code in your project for vulnerabilities and errors.'
|
||||
product: '{% data reusables.gated-features.code-scanning %}'
|
||||
permissions: 'People with write permissions to a repository can configure {% data variables.product.prodname_code_scanning %} for the repository.'
|
||||
miniTocMaxHeadingLevel: 4
|
||||
miniTocMaxHeadingLevel: 3
|
||||
versions:
|
||||
enterprise-server: '2.22'
|
||||
topics:
|
||||
@@ -16,7 +16,7 @@ redirect_from:
|
||||
{% data reusables.code-scanning.beta %}
|
||||
{% data reusables.code-scanning.enterprise-enable-code-scanning-actions %}
|
||||
|
||||
### About {% data variables.product.prodname_code_scanning %} configuration
|
||||
## About {% data variables.product.prodname_code_scanning %} configuration
|
||||
|
||||
You can run {% data variables.product.prodname_code_scanning %} on {% data variables.product.product_name %}, using {% data variables.product.prodname_actions %}, or from your continuous integration (CI) system, using the {% data variables.product.prodname_codeql_runner %}. For more information about {% data variables.product.prodname_actions %}, see "[About {% data variables.product.prodname_actions %}](/actions/getting-started-with-github-actions/about-github-actions)." For more information about the {% data variables.product.prodname_codeql_runner %}, see "[Running {% data variables.product.prodname_code_scanning %} in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/running-codeql-code-scanning-in-your-ci-system)."
|
||||
|
||||
@@ -28,7 +28,7 @@ Before you can configure {% data variables.product.prodname_code_scanning %} for
|
||||
|
||||
{% data variables.product.prodname_codeql %} analysis is just one type of {% data variables.product.prodname_code_scanning %} you can do in {% data variables.product.prodname_dotcom %}. {% data variables.product.prodname_marketplace %} on {% data variables.product.prodname_dotcom_the_website %} contains other {% data variables.product.prodname_code_scanning %} workflows you can use. The specific examples given in this article relate to the {% data variables.product.prodname_codeql_workflow %} file.
|
||||
|
||||
### Editing a {% data variables.product.prodname_code_scanning %} workflow
|
||||
## Editing a {% data variables.product.prodname_code_scanning %} workflow
|
||||
|
||||
{% data variables.product.prodname_dotcom %} saves workflow files in the _.github/workflows_ directory of your repository. You can find a workflow you have added by searching for its file name. For example, by default, the workflow file for {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %} is called _codeql-analysis.yml_.
|
||||
|
||||
@@ -40,23 +40,23 @@ Before you can configure {% data variables.product.prodname_code_scanning %} for
|
||||
|
||||
For more information about editing workflow files, see "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."
|
||||
|
||||
### Configuring frequency
|
||||
## Configuring frequency
|
||||
|
||||
You can configure the {% 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 {% data variables.product.company_short %}, security researchers, and the community discover, even when developers aren't actively maintaining the repository.
|
||||
|
||||
#### Scanning on push
|
||||
### Scanning on push
|
||||
|
||||
By default, the {% 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 {% 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 {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#on)."
|
||||
|
||||
#### Scanning pull requests
|
||||
### Scanning pull requests
|
||||
|
||||
The default {% data variables.product.prodname_codeql_workflow %} uses the `pull_request` event to trigger a code scan on pull requests targeted against the default branch. The `pull_request` event is not triggered if the pull request was opened from a private fork.
|
||||
|
||||
For more information about the `pull_request` event, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestbranchestags)."
|
||||
|
||||
#### Avoiding unnecessary scans of pull requests
|
||||
### Avoiding unnecessary scans of pull requests
|
||||
|
||||
You might want to avoid a code scan being triggered on specific pull requests targeted against the default branch, irrespective of which files have been changed. You can configure this by specifying `on:pull_request:paths-ignore` or `on:pull_request:paths` in the {% data variables.product.prodname_code_scanning %} workflow. For example, if the only changes in a pull request are to files with the file extensions `.md` or `.txt` you can use the following `paths-ignore` array.
|
||||
|
||||
@@ -82,7 +82,7 @@ on:
|
||||
|
||||
For more information about using `on:pull_request:paths-ignore` and `on:pull_request:paths` to determine when a workflow will run for a pull request, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths)."
|
||||
|
||||
#### Scanning on a schedule
|
||||
### Scanning on a schedule
|
||||
|
||||
If you use the default {% 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 {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#onschedule)."
|
||||
|
||||
@@ -92,7 +92,7 @@ If you use the default {% data variables.product.prodname_codeql_workflow %}, th
|
||||
|
||||
{% endnote %}
|
||||
|
||||
#### Example
|
||||
### Example
|
||||
|
||||
The following example shows a {% data variables.product.prodname_codeql_workflow %} for a particular repository that has a default branch called `main` and one protected branch called `protected`.
|
||||
|
||||
@@ -111,7 +111,7 @@ This workflow scans:
|
||||
* Every pull request to the default branch
|
||||
* The default branch every Tuesday at 7:40 UTC
|
||||
|
||||
### Specifying an operating system
|
||||
## Specifying an operating system
|
||||
|
||||
If your code requires a specific operating system to compile, you can configure the operating system in your {% 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 {% data variables.product.prodname_code_scanning %} actions. You specify the operating system by using an appropriate label as the second element in a two-element array, after `self-hosted`.
|
||||
|
||||
@@ -126,7 +126,7 @@ jobs:
|
||||
|
||||
You must ensure that Git is in the PATH variable on your self-hosted runners.
|
||||
|
||||
### Changing the languages that are analyzed
|
||||
## Changing the languages that are analyzed
|
||||
|
||||
{% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %} automatically detects code written in the supported languages.
|
||||
|
||||
@@ -157,7 +157,7 @@ If your workflow does not contain a matrix called `language`, then {% data varia
|
||||
languages: cpp, csharp, python
|
||||
```
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
### Analyzing Python dependencies
|
||||
## Analyzing Python dependencies
|
||||
|
||||
For GitHub-hosted runners that use Linux only, the {% data variables.product.prodname_codeql_workflow %} will try to auto-install Python dependencies to give more results for the CodeQL analysis. You can control this behavior by specifying the `setup-python-dependencies` parameter for the action called by the "Initialize CodeQL" step. By default, this parameter is set to `true`:
|
||||
|
||||
@@ -202,7 +202,7 @@ jobs:
|
||||
```
|
||||
{% endif %}
|
||||
|
||||
### Running additional queries
|
||||
## Running additional queries
|
||||
|
||||
{% data reusables.code-scanning.run-additional-queries %}
|
||||
|
||||
@@ -236,7 +236,7 @@ In the following example, the `+` symbol ensures that the specified additional q
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
### Using a custom configuration file
|
||||
## 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.
|
||||
|
||||
@@ -262,7 +262,7 @@ with:
|
||||
|
||||
The settings in the configuration file are written in YAML format.
|
||||
|
||||
#### Specifying additional queries
|
||||
### 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.
|
||||
|
||||
@@ -277,11 +277,11 @@ Optionally, you can give each array element a name, as shown in the example conf
|
||||
|
||||
For more information about additional queries, see "[Running additional queries](#running-additional-queries)" above.
|
||||
|
||||
#### Disabling the default queries
|
||||
### 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
|
||||
### Specifying directories to scan
|
||||
|
||||
For the interpreted languages that {% data variables.product.prodname_codeql %} supports (Python and JavaScript/TypeScript), you can restrict {% 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 analysis by adding a `paths-ignore` array.
|
||||
|
||||
@@ -307,16 +307,16 @@ For compiled languages, if you want to limit {% data variables.product.prodname_
|
||||
|
||||
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
|
||||
### Example configuration files
|
||||
|
||||
{% data reusables.code-scanning.example-configuration-files %}
|
||||
|
||||
### Configuring {% data variables.product.prodname_code_scanning %} for compiled languages
|
||||
## Configuring {% data variables.product.prodname_code_scanning %} for compiled languages
|
||||
|
||||
{% data reusables.code-scanning.autobuild-compiled-languages %} {% data reusables.code-scanning.analyze-go %}
|
||||
|
||||
{% data reusables.code-scanning.autobuild-add-build-steps %} For more information about how to configure {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %} for compiled languages, see "[Configuring the {% 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)."
|
||||
|
||||
### Uploading {% data variables.product.prodname_code_scanning %} data to {% data variables.product.prodname_dotcom %}
|
||||
## Uploading {% data variables.product.prodname_code_scanning %} data to {% data variables.product.prodname_dotcom %}
|
||||
|
||||
{% 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)."
|
||||
|
||||
@@ -16,14 +16,14 @@ redirect_from:
|
||||
{% data reusables.code-scanning.beta %}
|
||||
{% data reusables.code-scanning.enterprise-enable-code-scanning-actions %}
|
||||
|
||||
### About the {% data variables.product.prodname_codeql_workflow %} and compiled languages
|
||||
## About the {% data variables.product.prodname_codeql_workflow %} and compiled languages
|
||||
|
||||
You set up {% data variables.product.prodname_dotcom %} to run {% data variables.product.prodname_code_scanning %} for your repository by adding a {% data variables.product.prodname_actions %} workflow to the repository. For {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %}, you add the {% data variables.product.prodname_codeql_workflow %}. For more information, see "[Setting up {% data variables.product.prodname_code_scanning %} for a repository](/github/finding-security-vulnerabilities-and-errors-in-your-code/setting-up-code-scanning-for-a-repository)."
|
||||
|
||||
{% data reusables.code-scanning.edit-workflow %}
|
||||
For general information about configuring {% data variables.product.prodname_code_scanning %} and editing workflow files, see "[Configuring {% data variables.product.prodname_code_scanning %}](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning)" and "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."
|
||||
|
||||
### About autobuild for {% data variables.product.prodname_codeql %}
|
||||
## About autobuild for {% 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. {% data reusables.code-scanning.analyze-go %}
|
||||
|
||||
@@ -37,7 +37,7 @@ If your workflow uses a `language` matrix, `autobuild` attempts to build each of
|
||||
|
||||
{% endnote %}
|
||||
|
||||
#### C/C++
|
||||
### C/C++
|
||||
|
||||
| Supported system type | System name |
|
||||
|----|----|
|
||||
@@ -56,7 +56,7 @@ On Linux and macOS, the `autobuild` step reviews the files present in the reposi
|
||||
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#
|
||||
### C#
|
||||
|
||||
| Supported system type | System name |
|
||||
|----|----|
|
||||
@@ -70,7 +70,7 @@ The `autobuild` process attempts to autodetect a suitable build method for C# us
|
||||
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
|
||||
### Java
|
||||
|
||||
| Supported system type | System name |
|
||||
|----|----|
|
||||
@@ -83,7 +83,7 @@ The `autobuild` process tries to determine the build system for Java codebases b
|
||||
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
|
||||
## Adding build steps for a compiled language
|
||||
|
||||
{% data reusables.code-scanning.autobuild-add-build-steps %} For information on how to edit the workflow file, see "[Configuring {% data variables.product.prodname_code_scanning %}](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#editing-a-code-scanning-workflow)."
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ redirect_from:
|
||||
|
||||
{% data reusables.code-scanning.beta %}
|
||||
|
||||
### About alerts from {% data variables.product.prodname_code_scanning %}
|
||||
## About alerts from {% data variables.product.prodname_code_scanning %}
|
||||
|
||||
You can set up {% data variables.product.prodname_code_scanning %} to check the code in a repository using the default {% data variables.product.prodname_codeql %} analysis, a third-party analysis, or multiple types of analysis. When the analysis is complete, the resulting alerts are displayed alongside each other in the security view of the repository. Results from third-party tools or from custom queries may not include all of the properties that you see for alerts detected by {% data variables.product.company_short %}'s default {% data variables.product.prodname_codeql %} analysis. For more information, see "[Setting up {% data variables.product.prodname_code_scanning %} for a repository](/github/finding-security-vulnerabilities-and-errors-in-your-code/setting-up-code-scanning-for-a-repository)."
|
||||
|
||||
@@ -21,7 +21,7 @@ By default, {% data variables.product.prodname_code_scanning %} analyzes your co
|
||||
|
||||
{% data reusables.code-scanning.upload-sarif-alert-limit %}
|
||||
|
||||
### About alerts details
|
||||
## About alerts details
|
||||
|
||||
Each alert highlights a problem with the code and the name of the tool that identified it. You can see the line of code that triggered the alert, as well as properties of the alert, such as the severity and the nature of the problem. Alerts also tell you when the issue was first introduced. For alerts identified by {% data variables.product.prodname_codeql %} analysis, you will also see information on how to fix the problem.
|
||||
|
||||
@@ -31,7 +31,7 @@ If you set up {% data variables.product.prodname_code_scanning %} using {% data
|
||||
|
||||
When {% data variables.product.prodname_code_scanning %} reports data-flow alerts, {% data variables.product.prodname_dotcom %} shows you how data moves through the code. {% 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.
|
||||
|
||||
### Viewing the alerts for a repository
|
||||
## Viewing the alerts for a repository
|
||||
|
||||
Anyone with read permission for a repository can see {% data variables.product.prodname_code_scanning %} annotations on pull requests. For more information, see "[Triaging {% data variables.product.prodname_code_scanning %} alerts in pull requests](/github/finding-security-vulnerabilities-and-errors-in-your-code/triaging-code-scanning-alerts-in-pull-requests)."
|
||||
|
||||
@@ -47,7 +47,7 @@ You need write permission to view a summary of all the alerts for a repository o
|
||||
1. Alerts from {% data variables.product.prodname_codeql %} analysis include a description of the problem. Click **Show more** for guidance on how to fix your code.
|
||||

|
||||
|
||||
### Fixing an alert
|
||||
## Fixing an alert
|
||||
|
||||
Anyone with write permission for a repository can fix an alert by committing a correction to the code. If the repository has {% data variables.product.prodname_code_scanning %} scheduled to run on pull requests, it's best to raise a pull request with your correction. This will trigger {% data variables.product.prodname_code_scanning %} analysis of the changes and test that your fix doesn't introduce any new problems. For more information, see "[Configuring {% data variables.product.prodname_code_scanning %}](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning)" and "[Triaging {% data variables.product.prodname_code_scanning %} alerts in pull requests](/github/finding-security-vulnerabilities-and-errors-in-your-code/triaging-code-scanning-alerts-in-pull-requests)."
|
||||
|
||||
@@ -57,7 +57,7 @@ Alerts may be fixed in one branch but not in another. You can use the "Branch" d
|
||||
|
||||

|
||||
|
||||
### Closing an alert
|
||||
## Closing an alert
|
||||
|
||||
Closing an alert is a way to resolve an alert that you don't think needs to be fixed. {% data reusables.code-scanning.close-alert-examples %}
|
||||
|
||||
@@ -70,7 +70,7 @@ Closing an alert is a way to resolve an alert that you don't think needs to be f
|
||||
|
||||
{% data reusables.code-scanning.false-positive-fix-codeql %}
|
||||
|
||||
### Further reading
|
||||
## Further reading
|
||||
|
||||
- "[Triaging {% data variables.product.prodname_code_scanning %} alerts in pull requests](/github/finding-security-vulnerabilities-and-errors-in-your-code/triaging-code-scanning-alerts-in-pull-requests)"
|
||||
- "[Setting up {% data variables.product.prodname_code_scanning %} for a repository](/github/finding-security-vulnerabilities-and-errors-in-your-code/setting-up-code-scanning-for-a-repository)"
|
||||
|
||||
@@ -14,13 +14,13 @@ redirect_from:
|
||||
|
||||
{% data reusables.code-scanning.beta %}
|
||||
|
||||
### About {% data variables.product.prodname_code_scanning %} with a containerized build
|
||||
## About {% data variables.product.prodname_code_scanning %} with a containerized build
|
||||
|
||||
If you're setting up {% data variables.product.prodname_code_scanning %} for a compiled language, and you're building the code in a containerized environment, the analysis may fail with the error message "No source code was seen during the build." This indicates that {% data variables.product.prodname_codeql %} was unable to monitor your code as it was compiled.
|
||||
|
||||
You must run {% data variables.product.prodname_codeql %} in the same container in which you build your code. This applies whether you are using the {% data variables.product.prodname_codeql_runner %}, or {% data variables.product.prodname_actions %}. If you're using the {% data variables.product.prodname_codeql_runner %}, run it in the container where your code builds. For more information about the {% data variables.product.prodname_codeql_runner %}, see "[Running {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %} in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/running-codeql-code-scanning-in-your-ci-system)." If you're using {% data variables.product.prodname_actions %}, configure your workflow to run all the actions in the same container. For more information, see "[Example workflow](#example-workflow)."
|
||||
|
||||
### Dependencies
|
||||
## Dependencies
|
||||
|
||||
You may have difficulty running {% data variables.product.prodname_code_scanning %} if the container you're using is missing certain dependencies (for example, Git must be installed and added to the PATH variable). If you encounter dependency issues, review the list of software typically included on {% data variables.product.prodname_dotcom %}'s virtual environments. For more information, see the version-specific `readme` files in these locations:
|
||||
|
||||
@@ -28,7 +28,7 @@ You may have difficulty running {% data variables.product.prodname_code_scanning
|
||||
* macOS: https://github.com/actions/virtual-environments/tree/main/images/macos
|
||||
* Windows: https://github.com/actions/virtual-environments/tree/main/images/win
|
||||
|
||||
### Example workflow
|
||||
## Example workflow
|
||||
|
||||
This sample workflow uses {% data variables.product.prodname_actions %} to run {% data variables.product.prodname_codeql %} analysis in a containerized environment. The value of `container.image` identifies the container to use. In this example the image is named `codeql-container`, with a tag of `f0f91db`. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontainer)."
|
||||
|
||||
|
||||
@@ -16,13 +16,13 @@ redirect_from:
|
||||
{% data reusables.code-scanning.beta %}
|
||||
{% data reusables.code-scanning.enterprise-enable-code-scanning-actions %}
|
||||
|
||||
### Options for setting up {% data variables.product.prodname_code_scanning %}
|
||||
## Options for setting up {% data variables.product.prodname_code_scanning %}
|
||||
|
||||
You decide how to generate {% data variables.product.prodname_code_scanning %} alerts, and which tools to use, at a repository level. {% data variables.product.product_name %} provides fully integrated support for {% data variables.product.prodname_codeql %} analysis, and also supports analysis using third-party tools. For more information, see "[About {% data variables.product.prodname_codeql %}](/github/finding-security-vulnerabilities-and-errors-in-your-code/about-code-scanning#about-codeql)."
|
||||
|
||||
{% data reusables.code-scanning.enabling-options %}
|
||||
|
||||
### Setting up {% data variables.product.prodname_code_scanning %} using actions
|
||||
## Setting up {% data variables.product.prodname_code_scanning %} using actions
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
@@ -43,10 +43,10 @@ You decide how to generate {% data variables.product.prodname_code_scanning %} a
|
||||
|
||||
In the default {% data variables.product.prodname_codeql_workflow %}, {% data variables.product.prodname_code_scanning %} is configured to analyze your code each time you either push a change to the default branch or any protected branches, or raise a pull request against the default branch. As a result, {% data variables.product.prodname_code_scanning %} will now commence.
|
||||
|
||||
### Bulk set up of {% data variables.product.prodname_code_scanning %}
|
||||
## Bulk set up of {% data variables.product.prodname_code_scanning %}
|
||||
You can set up {% data variables.product.prodname_code_scanning %} in many repositories at once using a script. For an example of a script that raises pull requests to add a {% data variables.product.prodname_actions %} workflow to multiple repositories, see the [`jhutchings1/Create-ActionsPRs`](https://github.com/jhutchings1/Create-ActionsPRs) repository.
|
||||
|
||||
### Viewing the logging output from {% data variables.product.prodname_code_scanning %}
|
||||
## Viewing the logging output from {% data variables.product.prodname_code_scanning %}
|
||||
|
||||
After setting up {% data variables.product.prodname_code_scanning %} for your repository, you can watch the output of the actions as they run.
|
||||
|
||||
@@ -74,7 +74,7 @@ After setting up {% data variables.product.prodname_code_scanning %} for your re
|
||||
|
||||
{% endnote %}
|
||||
|
||||
### Understanding the pull request checks
|
||||
## Understanding the pull request checks
|
||||
|
||||
Each {% data variables.product.prodname_code_scanning %} workflow you set to run on pull requests always has at least two entries listed in the checks section of a pull request. There is one entry for each of the analysis jobs in the workflow, and a final one for the results of the analysis.
|
||||
|
||||
@@ -86,7 +86,7 @@ When the {% data variables.product.prodname_code_scanning %} jobs complete, {% d
|
||||
|
||||

|
||||
|
||||
#### Reasons for the "missing analysis" message
|
||||
### Reasons for the "missing analysis" message
|
||||
|
||||
After {% data variables.product.prodname_code_scanning %} has analyzed the code in a pull request, it needs to compare the analysis of the topic branch (the branch you used to create the pull request) with the analysis of the base branch (the branch into which you want to merge the pull request). This allows {% data variables.product.prodname_code_scanning %} to compute which alerts are newly introduced by the pull request, which alerts were already present in the base branch, and whether any existing alerts are fixed by the changes in the pull request. Initially, if you use a pull request to add {% data variables.product.prodname_code_scanning %} to a repository, the base branch has not yet been analyzed, so it's not possible to compute these details. In this case, when you click through from the results check on the pull request you will see the "Missing analysis for base commit SHA-HASH" message.
|
||||
|
||||
@@ -108,7 +108,7 @@ There are other situations where there may be no analysis for the latest commit
|
||||
|
||||
Merge a trivial change into the base branch to trigger {% data variables.product.prodname_code_scanning %} on this latest commit, then push a change to the pull request to retrigger {% data variables.product.prodname_code_scanning %}.
|
||||
|
||||
### Next steps
|
||||
## Next steps
|
||||
|
||||
After setting up {% data variables.product.prodname_code_scanning %}, and allowing its actions to complete, you can:
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ redirect_from:
|
||||
|
||||
{% data reusables.code-scanning.beta %}
|
||||
|
||||
### About {% data variables.product.prodname_code_scanning %} results on pull requests
|
||||
## About {% data variables.product.prodname_code_scanning %} results on pull requests
|
||||
|
||||
In repositories where {% data variables.product.prodname_code_scanning %} is configured as a pull request check, {% data variables.product.prodname_code_scanning %} checks the code in the pull request. By default, this is limited to pull requests that target the default branch, but you can change this configuration within {% data variables.product.prodname_actions %} or in a third-party CI/CD system. If merging the changes would introduce new {% data variables.product.prodname_code_scanning %} alerts to the target branch, these are reported as check results in the pull request. The alerts are also shown as annotations in the **Files changed** tab of the pull request. If you have write permission for the repository, you can see any existing {% data variables.product.prodname_code_scanning %} alerts on the **Security** tab. For information about repository alerts, see "[Managing {% data variables.product.prodname_code_scanning %} alerts for your repository](/github/finding-security-vulnerabilities-and-errors-in-your-code/managing-code-scanning-alerts-for-your-repository)."
|
||||
|
||||
@@ -23,13 +23,13 @@ If {% data variables.product.prodname_code_scanning %} has any results with a se
|
||||
|
||||

|
||||
|
||||
### About {% data variables.product.prodname_code_scanning %} as a pull request check
|
||||
## About {% data variables.product.prodname_code_scanning %} as a pull request check
|
||||
|
||||
There are many options for configuring {% data variables.product.prodname_code_scanning %} as a pull request check, so the exact setup of each repository will vary and some will have more than one check. The check that contains the results of {% data variables.product.prodname_code_scanning %} is: **Code scanning results**.
|
||||
|
||||
If the repository uses the {% data variables.product.prodname_codeql_workflow %} a **{% data variables.product.prodname_codeql %} / Analyze (LANGUAGE)** check is run for each language before the results check runs. The analysis check may fail if there are configuration problems, or if the pull request breaks the build for a language that the analysis needs to compile (for example, C/C++, C#, or Java). As with other pull request checks, you can see full details of the check failure on the **Checks** tab. For more information about configuring and troubleshooting, see "[Configuring {% data variables.product.prodname_code_scanning %}](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning)" or "[Troubleshooting the {% data variables.product.prodname_codeql %} workflow](/github/finding-security-vulnerabilities-and-errors-in-your-code/troubleshooting-the-codeql-workflow)."
|
||||
|
||||
### Triaging an alert on your pull request
|
||||
## Triaging an alert on your pull request
|
||||
|
||||
When you look at the **Files changed** tab for a pull request, you see annotations for any lines of code that triggered the alert.
|
||||
|
||||
@@ -43,7 +43,7 @@ In the detailed view for an alert, some {% data variables.product.prodname_code_
|
||||
|
||||

|
||||
|
||||
### Resolving an alert on your pull request
|
||||
## Resolving an alert on your pull request
|
||||
|
||||
Anyone with push access to a pull request can fix a {% data variables.product.prodname_code_scanning %} alert that's identified on that pull request. If you commit changes to the pull request this triggers a new run of the pull request checks. If your changes fix the problem, the alert is closed and the annotation removed.
|
||||
|
||||
|
||||
@@ -15,11 +15,11 @@ redirect_from:
|
||||
{% data reusables.code-scanning.beta %}
|
||||
{% data reusables.code-scanning.not-available %}
|
||||
|
||||
### Producing detailed logs for debugging
|
||||
## Producing detailed logs for debugging
|
||||
|
||||
To produce more detailed logging output, you can enable step debug logging. For more information, see "[Enabling debug logging](/actions/managing-workflow-runs/enabling-debug-logging#enabling-step-debug-logging)."
|
||||
|
||||
### Automatic build for a compiled language fails
|
||||
## 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.
|
||||
|
||||
@@ -51,7 +51,7 @@ If an automatic build of code for a compiled language within your project fails,
|
||||
|
||||
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
|
||||
## 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 {% data variables.product.prodname_codeql %} was unable to monitor your code. Several reasons can explain such a failure:
|
||||
|
||||
@@ -89,23 +89,23 @@ For more information, see the workflow extract in "[Automatic build for a compil
|
||||
|
||||
For more information about specifying build steps, see "[Configuring the {% 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`
|
||||
## Portions of my repository were not analyzed using `autobuild`
|
||||
|
||||
The {% 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 {% 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)."
|
||||
|
||||
### The build takes too long
|
||||
## The build takes too long
|
||||
|
||||
If your build with {% 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
|
||||
### Increase the memory or cores
|
||||
|
||||
If you use self-hosted runners to run {% 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
|
||||
### Use matrix builds to parallelize the analysis
|
||||
|
||||
The default {% 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 the workflow extract in "[Automatic build for a compiled language fails](#automatic-build-for-a-compiled-language-fails)" above.
|
||||
|
||||
#### Reduce the amount of code being analyzed in a single workflow
|
||||
### 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.
|
||||
|
||||
@@ -115,19 +115,19 @@ For interpreted languages like Go, JavaScript, Python, and TypeScript, that {% d
|
||||
|
||||
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 {% 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
|
||||
### 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)."
|
||||
|
||||
### Error: "Server error"
|
||||
## Error: "Server error"
|
||||
|
||||
If the run of a workflow for {% data variables.product.prodname_code_scanning %} fails due to a server error, try running the workflow again. If the problem persists, contact {% data variables.contact.contact_support %}.
|
||||
|
||||
### Error: "Out of disk" or "Out of memory"
|
||||
## Error: "Out of disk" or "Out of memory"
|
||||
|
||||
On very large projects, {% data variables.product.prodname_codeql %} may run out of disk or memory on the runner. If you encounter this issue, try increasing the memory on the runner.
|
||||
|
||||
### Warning: "git checkout HEAD^2 is no longer necessary"
|
||||
## Warning: "git checkout HEAD^2 is no longer necessary"
|
||||
|
||||
If you're using an old {% data variables.product.prodname_codeql %} workflow you may get the following warning in the output from the "Initialize {% data variables.product.prodname_codeql %}" action:
|
||||
|
||||
|
||||
@@ -19,11 +19,11 @@ As an alternative to running {% data variables.product.prodname_code_scanning %}
|
||||
|
||||
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 {% 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)."
|
||||
|
||||
### Integrations with webhooks
|
||||
## Integrations with webhooks
|
||||
|
||||
You can use {% data variables.product.prodname_code_scanning %} webhooks to build or set up integrations, such as [{% data variables.product.prodname_github_app %}s](/apps/building-github-apps/) or [{% data variables.product.prodname_oauth_app %}s](/apps/building-oauth-apps/), that subscribe to {% data variables.product.prodname_code_scanning %} events in your repository. For example, you could build an integration that creates an issue on {% data variables.product.product_name %} or sends you a Slack notification when a new {% data variables.product.prodname_code_scanning %} alert is added in your repository. For more information, see "[Creating webhooks](/developers/webhooks-and-events/creating-webhooks)" and "[Webhook events and payloads](/developers/webhooks-and-events/webhook-events-and-payloads#code_scanning_alert)."
|
||||
|
||||
### Further reading
|
||||
## Further reading
|
||||
|
||||
* "[About {% data variables.product.prodname_code_scanning %}](/github/finding-security-vulnerabilities-and-errors-in-your-code/about-code-scanning)"
|
||||
* "[Using {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %} with your existing CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/using-codeql-code-scanning-with-your-existing-ci-system)"
|
||||
|
||||
@@ -14,7 +14,7 @@ redirect_from:
|
||||
|
||||
{% data reusables.code-scanning.beta %}
|
||||
|
||||
### About SARIF support
|
||||
## 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. {% data variables.product.prodname_code_scanning_capc %} supports a subset of the SARIF 2.1.0 JSON schema.
|
||||
|
||||
@@ -26,7 +26,7 @@ If you're using {% data variables.product.prodname_actions %} with the {% data v
|
||||
|
||||
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
|
||||
## 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, {% 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.
|
||||
|
||||
@@ -36,7 +36,7 @@ SARIF files created by the {% data variables.product.prodname_codeql_workflow %}
|
||||
|
||||
If you upload a SARIF file without fingerprint data using the `/code-scanning/sarifs` API endpoint, the {% data variables.product.prodname_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 an analysis as SARIF data](/rest/reference/code-scanning#upload-an-analysis-as-sarif-data)."
|
||||
|
||||
### Validating your SARIF file
|
||||
## Validating your SARIF file
|
||||
|
||||
<!--UI-LINK: When code scanning fails, the error banner shown in the Security > Code scanning alerts view links to this anchor.-->
|
||||
|
||||
@@ -44,13 +44,13 @@ You can check a SARIF file is compatible with {% data variables.product.prodname
|
||||
|
||||
{% data reusables.code-scanning.upload-sarif-alert-limit %}
|
||||
|
||||
### Supported SARIF output file properties
|
||||
## Supported SARIF output file properties
|
||||
|
||||
If you use a code analysis engine other than {% data variables.product.prodname_codeql %}, you can review the supported SARIF properties to optimize how your analysis results will appear on {% data variables.product.prodname_dotcom %}.
|
||||
|
||||
Any valid SARIF 2.1.0 output file can be uploaded, however, {% data variables.product.prodname_code_scanning %} will only use the following supported properties.
|
||||
|
||||
#### `sarifLog` object
|
||||
### `sarifLog` object
|
||||
|
||||
| Name | Description |
|
||||
|----|----|
|
||||
@@ -58,7 +58,7 @@ Any valid SARIF 2.1.0 output file can be uploaded, however, {% data variables.pr
|
||||
| `version` | **Required.** {% 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
|
||||
### `run` object
|
||||
|
||||
{% 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.
|
||||
|
||||
@@ -70,7 +70,7 @@ Any valid SARIF 2.1.0 output file can be uploaded, however, {% data variables.pr
|
||||
| `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. {% data variables.product.prodname_code_scanning_capc %} displays the results on {% data variables.product.prodname_dotcom %}. For more information, see the [`result` object](#result-object).
|
||||
|
||||
#### `reportingDescriptor` object
|
||||
### `reportingDescriptor` object
|
||||
|
||||
| Name | Description |
|
||||
|----|----|
|
||||
@@ -84,7 +84,7 @@ Any valid SARIF 2.1.0 output file can be uploaded, however, {% data variables.pr
|
||||
| `properties.tags[]` | **Optional.** An array of strings. {% data variables.product.prodname_code_scanning_capc %} uses `tags` to allow you to filter results on {% 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`. {% data variables.product.prodname_code_scanning_capc %} orders results by precision on {% 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
|
||||
### `result` object
|
||||
|
||||
{% data reusables.code-scanning.upload-sarif-alert-limit %}
|
||||
|
||||
@@ -100,7 +100,7 @@ Any valid SARIF 2.1.0 output file can be uploaded, however, {% data variables.pr
|
||||
| `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, {% data variables.product.prodname_code_scanning %} will expand code flows on {% 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. {% 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).
|
||||
|
||||
#### `location` object
|
||||
### `location` object
|
||||
|
||||
A location within a programming artifact, such as a file in the repository or a file that was generated during a build.
|
||||
|
||||
@@ -110,7 +110,7 @@ A location within a programming artifact, such as a file in the repository or a
|
||||
| `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
|
||||
### `physicalLocation` object
|
||||
|
||||
| Name | Description |
|
||||
|----|----|
|
||||
@@ -120,11 +120,11 @@ A location within a programming artifact, such as a file in the repository or a
|
||||
| `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
|
||||
## SARIF output file examples
|
||||
|
||||
These example SARIF output files show supported properties and example values.
|
||||
|
||||
#### Example with minimum required properties
|
||||
### Example with minimum required properties
|
||||
|
||||
This SARIF output file has example values to show the minimum required properties for {% 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 {% data variables.product.prodname_dotcom %}.
|
||||
|
||||
@@ -175,7 +175,7 @@ This SARIF output file has example values to show the minimum required propertie
|
||||
}
|
||||
```
|
||||
|
||||
#### Example showing all supported SARIF properties
|
||||
### Example showing all supported SARIF properties
|
||||
|
||||
This SARIF output file has example values to show all supported SARIF properties for {% data variables.product.prodname_code_scanning %}.
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ redirect_from:
|
||||
{% data reusables.code-scanning.beta %}
|
||||
{% data reusables.code-scanning.enterprise-enable-code-scanning %}
|
||||
|
||||
### About SARIF file uploads for {% data variables.product.prodname_code_scanning %}
|
||||
## About SARIF file uploads for {% data variables.product.prodname_code_scanning %}
|
||||
|
||||
{% data variables.product.prodname_dotcom %} creates {% 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 {% data variables.product.prodname_actions %}. For more information, see "[Managing {% data variables.product.prodname_code_scanning %} alerts for your repository](/github/finding-security-vulnerabilities-and-errors-in-your-code/managing-code-scanning-alerts-for-your-repository)."
|
||||
|
||||
@@ -31,7 +31,7 @@ You can upload the results using {% data variables.product.prodname_actions %} (
|
||||
|
||||
{% data reusables.code-scanning.not-available %}
|
||||
|
||||
### Uploading a {% data variables.product.prodname_code_scanning %} analysis with {% data variables.product.prodname_actions %}
|
||||
## Uploading a {% data variables.product.prodname_code_scanning %} analysis with {% data variables.product.prodname_actions %}
|
||||
|
||||
To use {% 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 {% data variables.product.prodname_actions %}](/actions/getting-started-with-github-actions/about-github-actions)" and "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."
|
||||
|
||||
@@ -43,7 +43,7 @@ If your SARIF file doesn't include `partialFingerprints`, the `upload-sarif` act
|
||||
|
||||
{% data reusables.code-scanning.upload-sarif-alert-limit %}
|
||||
|
||||
#### Example workflow for SARIF files generated outside of a repository
|
||||
### 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.
|
||||
|
||||
@@ -79,7 +79,7 @@ jobs:
|
||||
sarif_file: results.sarif
|
||||
```
|
||||
|
||||
#### Example workflow that runs the ESLint analysis tool
|
||||
### 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 {% data variables.product.prodname_actions %} template. For more information, see the "[{% data variables.product.prodname_actions %} quickstart](/actions/quickstart)."
|
||||
|
||||
@@ -117,7 +117,7 @@ jobs:
|
||||
sarif_file: results.sarif
|
||||
```
|
||||
|
||||
### Further reading
|
||||
## Further reading
|
||||
|
||||
- "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions)"
|
||||
- "[Viewing your workflow history](/actions/managing-workflow-runs/viewing-workflow-run-history)"
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Configuring CodeQL code scanning in your CI system
|
||||
shortTitle: Configuring in your CI
|
||||
intro: 'You can configure how the {% data variables.product.prodname_codeql_runner %} scans the code in your project and uploads the results to {% data variables.product.prodname_dotcom %}.'
|
||||
product: '{% data reusables.gated-features.code-scanning %}'
|
||||
miniTocMaxHeadingLevel: 4
|
||||
miniTocMaxHeadingLevel: 3
|
||||
versions:
|
||||
enterprise-server: '2.22'
|
||||
topics:
|
||||
@@ -17,7 +17,7 @@ redirect_from:
|
||||
{% data reusables.code-scanning.beta %}
|
||||
{% data reusables.code-scanning.enterprise-enable-code-scanning %}
|
||||
|
||||
### About configuring {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %} in your CI system
|
||||
## About configuring {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %} in your CI system
|
||||
|
||||
To integrate {% data variables.product.prodname_code_scanning %} into your CI system, you can use the {% data variables.product.prodname_codeql_runner %}. For more information, see "[Running {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %} in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/running-codeql-code-scanning-in-your-ci-system)."
|
||||
|
||||
@@ -32,7 +32,7 @@ There are three versions of the {% data variables.product.prodname_codeql_runner
|
||||
|
||||
To customize the way the {% 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.
|
||||
|
||||
### Scanning pull requests
|
||||
## Scanning pull requests
|
||||
|
||||
Scanning code whenever a pull request is created prevents developers from introducing new vulnerabilities and errors into the code.
|
||||
|
||||
@@ -48,7 +48,7 @@ $ /path/to-runner/codeql-runner-linux analyze --ref refs/pull/42/merge
|
||||
|
||||
{% endnote %}
|
||||
|
||||
### Overriding automatic language detection
|
||||
## Overriding automatic language detection
|
||||
|
||||
The {% data variables.product.prodname_codeql_runner %} automatically detects and scans code written in the supported languages.
|
||||
|
||||
@@ -62,7 +62,7 @@ To override automatic language detection, run the `init` command with the `--lan
|
||||
$ /path/to-runner/codeql-runner-linux init --languages cpp,java
|
||||
```
|
||||
|
||||
### Running additional queries
|
||||
## Running additional queries
|
||||
|
||||
{% data reusables.code-scanning.run-additional-queries %}
|
||||
|
||||
@@ -81,7 +81,7 @@ $ /path/to-runner/codeql-runner-linux init --config-file .github/codeql/codeql-c
|
||||
--queries +security-and-quality,octo-org/python-qlpack/show_ifs.ql@main
|
||||
```
|
||||
|
||||
### Using a custom configuration file
|
||||
## Using a custom configuration file
|
||||
|
||||
Instead of passing additional information to the {% data variables.product.prodname_codeql_runner %} commands, you can specify custom settings in a separate configuration file.
|
||||
|
||||
@@ -95,11 +95,11 @@ $ /path/to-runner/codeql-runner-linux init --config-file .github/codeql/codeql-c
|
||||
|
||||
{% data reusables.code-scanning.custom-configuration-file %}
|
||||
|
||||
#### Example configuration files
|
||||
### Example configuration files
|
||||
|
||||
{% data reusables.code-scanning.example-configuration-files %}
|
||||
|
||||
### Configuring {% data variables.product.prodname_code_scanning %} for compiled languages
|
||||
## Configuring {% data variables.product.prodname_code_scanning %} for compiled languages
|
||||
|
||||
For the compiled languages C/C++, C#, and Java, {% data variables.product.prodname_codeql %} builds the code before analyzing it. {% data reusables.code-scanning.analyze-go %}
|
||||
|
||||
@@ -113,7 +113,7 @@ $ /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 {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %} in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/running-codeql-code-scanning-in-your-ci-system#compiled-language-example)."
|
||||
|
||||
### Uploading {% data variables.product.prodname_code_scanning %} data to {% data variables.product.prodname_dotcom %}
|
||||
## Uploading {% data variables.product.prodname_code_scanning %} data to {% data variables.product.prodname_dotcom %}
|
||||
|
||||
By default, the {% data variables.product.prodname_codeql_runner %} uploads results from {% data variables.product.prodname_code_scanning %} when you run the `analyze` command. You can also upload SARIF files separately, by using the `upload` command.
|
||||
|
||||
@@ -121,11 +121,11 @@ Once you've uploaded the data, {% data variables.product.prodname_dotcom %} disp
|
||||
- If you uploaded to a pull request, for example `--ref refs/pull/42/merge` or `--ref refs/pull/42/head`, then the results appear as alerts in a pull request check. For more information, see "[Triaging code scanning alerts in pull requests](/github/finding-security-vulnerabilities-and-errors-in-your-code/triaging-code-scanning-alerts-in-pull-requests)."
|
||||
- If you uploaded to a branch, for example `--ref refs/heads/my-branch`, then the results appear in the **Security** tab for your repository. For more information, see "[Managing code scanning alerts for your repository](/github/finding-security-vulnerabilities-and-errors-in-your-code/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository)."
|
||||
|
||||
### {% data variables.product.prodname_codeql_runner %} command reference
|
||||
## {% data variables.product.prodname_codeql_runner %} command reference
|
||||
|
||||
The {% data variables.product.prodname_codeql_runner %} supports the following commands and flags.
|
||||
|
||||
#### `init`
|
||||
### `init`
|
||||
|
||||
Initializes the {% data variables.product.prodname_codeql_runner %} and creates a {% data variables.product.prodname_codeql %} database for each language to be analyzed.
|
||||
|
||||
@@ -144,7 +144,7 @@ Initializes the {% data variables.product.prodname_codeql_runner %} and creates
|
||||
| `--debug` | | None. Prints more verbose output. |
|
||||
| `-h`, `--help` | | None. Displays help for the command. |
|
||||
|
||||
#### `autobuild`
|
||||
### `autobuild`
|
||||
|
||||
Attempts to build the code for the compiled languages C/C++, C#, and Java. For those languages, {% data variables.product.prodname_codeql %} builds the code before analyzing it. Run `autobuild` between the `init` and `analyze` steps.
|
||||
|
||||
@@ -155,7 +155,7 @@ Attempts to build the code for the compiled languages C/C++, C#, and Java. For t
|
||||
| `--debug` | | None. Prints more verbose output. |
|
||||
| `-h`, `--help` | | None. Displays help for the command. |
|
||||
|
||||
#### `analyze`
|
||||
### `analyze`
|
||||
|
||||
Analyzes the code in the {% data variables.product.prodname_codeql %} databases and uploads results to {% data variables.product.product_name %}.
|
||||
|
||||
@@ -176,7 +176,7 @@ Analyzes the code in the {% data variables.product.prodname_codeql %} databases
|
||||
| `--debug` | | None. Prints more verbose output. |
|
||||
| `-h`, `--help` | | None. Displays help for the command. |
|
||||
|
||||
#### `upload`
|
||||
### `upload`
|
||||
|
||||
Uploads SARIF files to {% data variables.product.product_name %}.
|
||||
|
||||
|
||||
@@ -17,11 +17,11 @@ redirect_from:
|
||||
{% data reusables.code-scanning.beta %}
|
||||
{% data reusables.code-scanning.enterprise-enable-code-scanning %}
|
||||
|
||||
### Using {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %} with your existing CI system
|
||||
## Using {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %} with your existing CI system
|
||||
|
||||
If you use a continuous integration or continuous delivery/deployment (CI/CD) system other than {% data variables.product.prodname_actions %}, you can use your existing system to run {% data variables.product.prodname_dotcom %}'s {% data variables.product.prodname_codeql %} analysis and upload the results to {% data variables.product.prodname_dotcom %}. To do this, use the {% data variables.product.prodname_codeql_runner %}.
|
||||
|
||||
### About the {% data variables.product.prodname_codeql_runner %}
|
||||
## About the {% data variables.product.prodname_codeql_runner %}
|
||||
|
||||
{% data reusables.code-scanning.about-code-scanning %} For information, see "[About {% data variables.product.prodname_code_scanning %}](/github/finding-security-vulnerabilities-and-errors-in-your-code/about-code-scanning)."
|
||||
|
||||
@@ -36,7 +36,7 @@ The {% data variables.product.prodname_codeql_runner %} is a command-line tool t
|
||||
* The {% data variables.product.prodname_codeql_runner %} shouldn't be confused with the {% data variables.product.prodname_codeql %} CLI. The {% data variables.product.prodname_codeql %} CLI is an interactive command-line interface that lets you create {% data variables.product.prodname_codeql %} databases for security research and run {% data variables.product.prodname_codeql %} queries. For more information, see "[{% data variables.product.prodname_codeql %} CLI](https://codeql.github.com/docs/codeql-cli/)."
|
||||
{% endnote %}
|
||||
|
||||
### Downloading the {% data variables.product.prodname_codeql_runner %}
|
||||
## Downloading the {% data variables.product.prodname_codeql_runner %}
|
||||
|
||||
You can download the {% 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.
|
||||
|
||||
@@ -55,7 +55,7 @@ sudo xattr -d com.apple.quarantine codeql-runner-macos
|
||||
|
||||
On Windows, the `codeql-runner-win.exe` file usually requires no change to permissions.
|
||||
|
||||
### Adding the {% data variables.product.prodname_codeql_runner %} to your CI system
|
||||
## Adding the {% data variables.product.prodname_codeql_runner %} to your CI system
|
||||
|
||||
Once you download the {% data variables.product.prodname_codeql_runner %} and verify that it can be executed, you should make the runner available to each CI server that you intend to use for {% data variables.product.prodname_code_scanning %}. For example, you might configure each server to copy the runner from a central, internal location. Alternatively, you could use the REST API to get the runner directly from {% data variables.product.prodname_dotcom %}, for example:
|
||||
|
||||
@@ -75,7 +75,7 @@ The options for providing access to the {% data variables.product.prodname_codeq
|
||||
1. Mirror the `github/codeql-action` repository on {% data variables.product.product_name %}. Unless you specify the <nobr>`--codeql-path`</nobr> flag, the runner automatically checks for the bundle in this location and on {% data variables.product.prodname_dotcom_the_website %}.
|
||||
1. Manually download/extract the bundle, store it with other central resources, and use the <nobr>`--codeql-path`</nobr> flag to specify the location of the bundle in calls to initialize the {% data variables.product.prodname_codeql_runner %}.
|
||||
|
||||
### Calling the {% data variables.product.prodname_codeql_runner %}
|
||||
## Calling the {% data variables.product.prodname_codeql_runner %}
|
||||
|
||||
You should call the {% data variables.product.prodname_codeql_runner %} from the checkout location of the repository you want to analyze. The two main commands are:
|
||||
|
||||
@@ -90,7 +90,7 @@ To view the command-line reference for the runner, use the `-h` flag. For exampl
|
||||
|
||||
{% data reusables.code-scanning.upload-sarif-alert-limit %}
|
||||
|
||||
#### Basic example
|
||||
### Basic example
|
||||
|
||||
This example runs {% data variables.product.prodname_codeql %} analysis on a Linux CI server for the `octo-org/example-repo` repository hosted on `{% data variables.command_line.git_url_example %}`. The process is very simple because the repository contains only languages that can be analyzed by {% data variables.product.prodname_codeql %} directly, without being built (that is, Go, JavaScript, Python, and TypeScript).
|
||||
|
||||
@@ -110,7 +110,7 @@ In this example, the server has access to download the {% data variables.product
|
||||
|
||||
{% data reusables.code-scanning.codeql-runner-analyze-example %}
|
||||
|
||||
#### Compiled language example
|
||||
### 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 {% data variables.product.prodname_codeql %} database for these languages, the CLI needs to monitor 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.
|
||||
|
||||
@@ -145,7 +145,7 @@ This example is similar to the previous example, however this time the repositor
|
||||
|
||||
{% endnote %}
|
||||
|
||||
### Further reading
|
||||
## Further reading
|
||||
|
||||
- "[Configuring {% data variables.product.prodname_code_scanning %} in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-codeql-code-scanning-in-your-ci-system)"
|
||||
- "[Troubleshooting {% data variables.product.prodname_code_scanning %} in your CI system](/github/finding-security-vulnerabilities-and-errors-in-your-code/troubleshooting-codeql-code-scanning-in-your-ci-system)"
|
||||
|
||||
@@ -16,7 +16,7 @@ redirect_from:
|
||||
{% data reusables.code-scanning.beta %}
|
||||
{% data reusables.code-scanning.not-available %}
|
||||
|
||||
### The `init` command takes too long
|
||||
## The `init` command takes too long
|
||||
|
||||
Before the {% data variables.product.prodname_codeql_runner %} can build and analyze code, it needs access to the {% data variables.product.prodname_codeql %} bundle, which contains the {% data variables.product.prodname_codeql %} CLI and the {% data variables.product.prodname_codeql %} libraries.
|
||||
|
||||
@@ -25,7 +25,7 @@ The {% data variables.product.prodname_codeql %} bundle is cached between runs,
|
||||
|
||||
To avoid this automatic download, you can manually download the {% 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
|
||||
## No code found during the build
|
||||
|
||||
If the `analyze` command for the {% data variables.product.prodname_codeql_runner %} fails with an error `No source code was seen during the build`, this indicates that {% data variables.product.prodname_codeql %} was unable to monitor your code. Several reasons can explain such a failure.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user