From 8df155a7e6a8c07e1010e175d20bdab18929adc5 Mon Sep 17 00:00:00 2001 From: Sarita Iyer Date: Wed, 29 Sep 2021 16:22:20 -0400 Subject: [PATCH 1/5] Added info on improvements to push trigger and comparisons --- .../configuring-code-scanning.md | 12 ++++++++---- .../setting-up-code-scanning-for-a-repository.md | 3 +++ ...triaging-code-scanning-alerts-in-pull-requests.md | 3 +++ 3 files changed, 14 insertions(+), 4 deletions(-) diff --git a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md index 8a9e0a2ee9..1716ff0bfc 100644 --- a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md +++ b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md @@ -69,11 +69,11 @@ By default, the {% data variables.product.prodname_codeql_workflow %} uses the ` If you scan on push, then the results appear in the **Security** tab for your repository. For more information, see "[Managing code scanning alerts for your repository](/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository)." -{% note %} +{% ifversion fpt or ghes > 3.2 or ghae-issue-5093 %} +Additionally, when an `on:push` scan returns results that can be mapped to an open pull request, these alerts will automatically appear on the pull request in the same places as other pull request alerts. The alerts are identified by comparing the existing analysis of the head of the branch to the analysis for the target branch. For more information on code scanning alerts in pull requests, see "[Triaging code scanning alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests)." -**Note**: If you want {% data variables.product.prodname_code_scanning %} alerts to appear as pull request checks, you must use the `pull_request` event, described below. - -{% endnote %} +Note that alerts identified using a pull request's merge commit, as done with the `pull_request` trigger, are more accurate than those identified using the head of the branch. While it is also less efficient to trigger a code scan on each push, rather than on each pull request, if you use a CI/CD system that can only be configured to trigger when code is pushed, you will still be able to see alerts on your pull requests. +{% endif %} ### Scanning pull requests @@ -83,6 +83,10 @@ For more information about the `pull_request` event, see "[Workflow syntax for { If you scan pull requests, then the results appear as alerts in a pull request check. For more information, see "[Triaging code scanning alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests)." +{% ifversion fpt or ghes > 3.2 or ghae-issue-5093 %} +It can be more efficient to use the `pull_request` trigger instead of scanning code on each push, and also produces the most accurate results, since alerts are identified by comparing the results for the pull request merge commit against the target branch baseline. However, if you use a CI/CD system that cannot be configured to trigger on pull requests, you can still use the `on:push` trigger and {% data variables.product.prodname_code_scanning %} will map the results to open pull requests on the branch and add the alerts as annotations on the pull request. For more information, see "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)." +{% endif %} + {% ifversion fpt or ghes > 3.1 or ghae-next %} ### Defining the severities causing pull request check failure diff --git a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository.md b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository.md index 0dcd2a9774..219c12e1ad 100644 --- a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository.md +++ b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository.md @@ -56,6 +56,9 @@ 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. +{% ifversion fpt or ghes > 3.2 or ghae-issue-5093 %} +The `on:pull_request` and `on:push` triggers are each useful for different purposes. Code scanning on the `pull_request` trigger is more efficient than scanning on each push, and results are more accurate because they reflect the future state of the code by comparing the merge commit to the target branch baseline. But `push` scans will also flag alerts on any open pull requests for the branch, and if your third-party CI/CD system can only be configured to trigger on push, you will still be able to see alerts on pull requests. For more information, see "[Scanning on pull requests](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-pull-requests)" and "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)." +{% endif %} ## 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. If you'd like to use a script to raise pull requests that add a {% data variables.product.prodname_actions %} workflow to multiple repositories, see the [`jhutchings1/Create-ActionsPRs`](https://github.com/jhutchings1/Create-ActionsPRs) repository for an example using Powershell, or [`nickliffen/ghas-enablement`](https://github.com/NickLiffen/ghas-enablement) for teams who do not have Powershell and instead would like to use NodeJS. diff --git a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/triaging-code-scanning-alerts-in-pull-requests.md b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/triaging-code-scanning-alerts-in-pull-requests.md index e7123a427e..aa2d6ea585 100644 --- a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/triaging-code-scanning-alerts-in-pull-requests.md +++ b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/triaging-code-scanning-alerts-in-pull-requests.md @@ -27,6 +27,9 @@ topics: ## 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](/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository)." +{% ifversion fpt or ghes > 3.2 or ghae-issue-5093 %} +In repositories where {% data variables.product.prodname_code_scanning %} is configured to scan each time code is pushed, {% data variables.product.prodname_code_scanning %} will also map the results to any open pull requests and add the alerts as annotations in the same places as other pull request checks. For more information, see "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)." +{% endif %} If your pull request targets a protected branch that uses {% data variables.product.prodname_code_scanning %}, and the repository owner has configured required status checks, then the "{% data variables.product.prodname_code_scanning_capc %} results" check must pass before you can merge the pull request. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-status-checks-before-merging)." From 61ac1464410db35243a248c446e2b93e784e61ec Mon Sep 17 00:00:00 2001 From: Sarita Iyer <66540150+saritai@users.noreply.github.com> Date: Wed, 6 Oct 2021 11:33:17 -0400 Subject: [PATCH 2/5] Apply initial suggestions from code review Co-authored-by: Ethan Palm <56270045+ethanpalm@users.noreply.github.com> --- .../configuring-code-scanning.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md index 1716ff0bfc..ae93e9e19b 100644 --- a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md +++ b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md @@ -70,9 +70,9 @@ By default, the {% data variables.product.prodname_codeql_workflow %} uses the ` If you scan on push, then the results appear in the **Security** tab for your repository. For more information, see "[Managing code scanning alerts for your repository](/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository)." {% ifversion fpt or ghes > 3.2 or ghae-issue-5093 %} -Additionally, when an `on:push` scan returns results that can be mapped to an open pull request, these alerts will automatically appear on the pull request in the same places as other pull request alerts. The alerts are identified by comparing the existing analysis of the head of the branch to the analysis for the target branch. For more information on code scanning alerts in pull requests, see "[Triaging code scanning alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests)." +Additionally, when an `on:push` scan returns results that can be mapped to an open pull request, these alerts will automatically appear on the pull request in the same places as other pull request alerts. The alerts are identified by comparing the existing analysis of the head of the branch to the analysis for the target branch. For more information on {% data variables.product.prodname_code_scanning %} alerts in pull requests, see "[Triaging {% data variables.product.prodname_code_scanning %} alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests)." -Note that alerts identified using a pull request's merge commit, as done with the `pull_request` trigger, are more accurate than those identified using the head of the branch. While it is also less efficient to trigger a code scan on each push, rather than on each pull request, if you use a CI/CD system that can only be configured to trigger when code is pushed, you will still be able to see alerts on your pull requests. +Note that alerts identified using a pull request's merge commit, as done with the `pull_request` trigger, are more accurate and efficient than alerts identified using the head of the branch. If you use a CI/CD system that can only be configured to trigger when code is pushed, you can use `on:push` scans to detect alerts on your pull requests. {% endif %} ### Scanning pull requests @@ -84,7 +84,7 @@ For more information about the `pull_request` event, see "[Workflow syntax for { If you scan pull requests, then the results appear as alerts in a pull request check. For more information, see "[Triaging code scanning alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests)." {% ifversion fpt or ghes > 3.2 or ghae-issue-5093 %} -It can be more efficient to use the `pull_request` trigger instead of scanning code on each push, and also produces the most accurate results, since alerts are identified by comparing the results for the pull request merge commit against the target branch baseline. However, if you use a CI/CD system that cannot be configured to trigger on pull requests, you can still use the `on:push` trigger and {% data variables.product.prodname_code_scanning %} will map the results to open pull requests on the branch and add the alerts as annotations on the pull request. For more information, see "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)." +It can be more efficient and accurate to use the `pull_request` trigger instead of scanning code on each push, since alerts are identified by comparing the results for the pull request merge commit against the target branch baseline. However, if you use a CI/CD system that cannot be configured to trigger on pull requests, you can still use the `on:push` trigger and {% data variables.product.prodname_code_scanning %} will map the results to open pull requests on the branch and add the alerts as annotations on the pull request. For more information, see "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)." {% endif %} {% ifversion fpt or ghes > 3.1 or ghae-next %} From 199af2fd6ed5cc175fa06f9884bb732d4e0af4a9 Mon Sep 17 00:00:00 2001 From: Sarita Iyer Date: Wed, 6 Oct 2021 15:13:35 -0400 Subject: [PATCH 3/5] additional changes from review feedback --- .../configuring-code-scanning.md | 4 +--- .../setting-up-code-scanning-for-a-repository.md | 4 +--- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md index ae93e9e19b..a14383ade4 100644 --- a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md +++ b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md @@ -71,8 +71,6 @@ If you scan on push, then the results appear in the **Security** tab for your re {% ifversion fpt or ghes > 3.2 or ghae-issue-5093 %} Additionally, when an `on:push` scan returns results that can be mapped to an open pull request, these alerts will automatically appear on the pull request in the same places as other pull request alerts. The alerts are identified by comparing the existing analysis of the head of the branch to the analysis for the target branch. For more information on {% data variables.product.prodname_code_scanning %} alerts in pull requests, see "[Triaging {% data variables.product.prodname_code_scanning %} alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests)." - -Note that alerts identified using a pull request's merge commit, as done with the `pull_request` trigger, are more accurate and efficient than alerts identified using the head of the branch. If you use a CI/CD system that can only be configured to trigger when code is pushed, you can use `on:push` scans to detect alerts on your pull requests. {% endif %} ### Scanning pull requests @@ -84,7 +82,7 @@ For more information about the `pull_request` event, see "[Workflow syntax for { If you scan pull requests, then the results appear as alerts in a pull request check. For more information, see "[Triaging code scanning alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests)." {% ifversion fpt or ghes > 3.2 or ghae-issue-5093 %} -It can be more efficient and accurate to use the `pull_request` trigger instead of scanning code on each push, since alerts are identified by comparing the results for the pull request merge commit against the target branch baseline. However, if you use a CI/CD system that cannot be configured to trigger on pull requests, you can still use the `on:push` trigger and {% data variables.product.prodname_code_scanning %} will map the results to open pull requests on the branch and add the alerts as annotations on the pull request. For more information, see "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)." + Using the `pull_request` trigger, as long as it is configured to scan the pull request's merge commit instead of the head commit, will produce more efficient and accurate results than scanning code on each push. However, if you use a CI/CD system that cannot be configured to trigger on pull requests, you can still use the `on:push` trigger and {% data variables.product.prodname_code_scanning %} will map the results to open pull requests on the branch and add the alerts as annotations on the pull request. For more information, see "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)." {% endif %} {% ifversion fpt or ghes > 3.1 or ghae-next %} diff --git a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository.md b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository.md index 219c12e1ad..33e77eb37c 100644 --- a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository.md +++ b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository.md @@ -56,9 +56,7 @@ 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. -{% ifversion fpt or ghes > 3.2 or ghae-issue-5093 %} -The `on:pull_request` and `on:push` triggers are each useful for different purposes. Code scanning on the `pull_request` trigger is more efficient than scanning on each push, and results are more accurate because they reflect the future state of the code by comparing the merge commit to the target branch baseline. But `push` scans will also flag alerts on any open pull requests for the branch, and if your third-party CI/CD system can only be configured to trigger on push, you will still be able to see alerts on pull requests. For more information, see "[Scanning on pull requests](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-pull-requests)" and "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)." -{% endif %} +The `on:pull_request` and `on:push` triggers are each useful for different purposes. For more information, see "[Scanning on pull requests](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-pull-requests)" and "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)." ## 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. If you'd like to use a script to raise pull requests that add a {% data variables.product.prodname_actions %} workflow to multiple repositories, see the [`jhutchings1/Create-ActionsPRs`](https://github.com/jhutchings1/Create-ActionsPRs) repository for an example using Powershell, or [`nickliffen/ghas-enablement`](https://github.com/NickLiffen/ghas-enablement) for teams who do not have Powershell and instead would like to use NodeJS. From f3ccd6d8438ae49571dbec633be9292b6cbb3c3d Mon Sep 17 00:00:00 2001 From: Sarita Iyer Date: Wed, 6 Oct 2021 15:57:36 -0400 Subject: [PATCH 4/5] fix some wording --- .../configuring-code-scanning.md | 2 +- .../setting-up-code-scanning-for-a-repository.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md index 76f89d2544..b5e447575d 100644 --- a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md +++ b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md @@ -82,7 +82,7 @@ For more information about the `pull_request` event, see "[Workflow syntax for { If you scan pull requests, then the results appear as alerts in a pull request check. For more information, see "[Triaging code scanning alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests)." {% ifversion fpt or ghes > 3.2 or ghae-issue-5093 %} - Using the `pull_request` trigger, as long as it is configured to scan the pull request's merge commit instead of the head commit, will produce more efficient and accurate results than scanning code on each push. However, if you use a CI/CD system that cannot be configured to trigger on pull requests, you can still use the `on:push` trigger and {% data variables.product.prodname_code_scanning %} will map the results to open pull requests on the branch and add the alerts as annotations on the pull request. For more information, see "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)." + Using the `pull_request` trigger, configured to scan the pull request's merge commit instead of the head commit, will produce more efficient and accurate results than scanning the head of the branch on each push. However, if you use a CI/CD system that cannot be configured to trigger on pull requests, you can still use the `on:push` trigger and {% data variables.product.prodname_code_scanning %} will map the results to open pull requests on the branch and add the alerts as annotations on the pull request. For more information, see "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)." {% endif %} {% ifversion fpt or ghes > 3.1 or ghae-next %} diff --git a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository.md b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository.md index 2cc3481458..6dcf0becc9 100644 --- a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository.md +++ b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository.md @@ -56,7 +56,7 @@ 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. -The `on:pull_request` and `on:push` triggers are each useful for different purposes. For more information, see "[Scanning on pull requests](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-pull-requests)" and "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)." +The `on:pull_request` and `on:push` triggers for code scanning are each useful for different purposes. For more information, see "[Scanning pull requests](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-pull-requests)" and "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)." ## 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. If you'd like to use a script to raise pull requests that add a {% data variables.product.prodname_actions %} workflow to multiple repositories, see the [`jhutchings1/Create-ActionsPRs`](https://github.com/jhutchings1/Create-ActionsPRs) repository for an example using Powershell, or [`nickliffen/ghas-enablement`](https://github.com/NickLiffen/ghas-enablement) for teams who do not have Powershell and instead would like to use NodeJS. From 6d11b996ef7847ba6840651a9ce72676abddc881 Mon Sep 17 00:00:00 2001 From: Sarita Iyer Date: Wed, 6 Oct 2021 16:34:04 -0400 Subject: [PATCH 5/5] small wording change --- .../configuring-code-scanning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md index b5e447575d..ec1c571db9 100644 --- a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md +++ b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md @@ -82,7 +82,7 @@ For more information about the `pull_request` event, see "[Workflow syntax for { If you scan pull requests, then the results appear as alerts in a pull request check. For more information, see "[Triaging code scanning alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests)." {% ifversion fpt or ghes > 3.2 or ghae-issue-5093 %} - Using the `pull_request` trigger, configured to scan the pull request's merge commit instead of the head commit, will produce more efficient and accurate results than scanning the head of the branch on each push. However, if you use a CI/CD system that cannot be configured to trigger on pull requests, you can still use the `on:push` trigger and {% data variables.product.prodname_code_scanning %} will map the results to open pull requests on the branch and add the alerts as annotations on the pull request. For more information, see "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)." + Using the `pull_request` trigger, configured to scan the pull request's merge commit rather than the head commit, will produce more efficient and accurate results than scanning the head of the branch on each push. However, if you use a CI/CD system that cannot be configured to trigger on pull requests, you can still use the `on:push` trigger and {% data variables.product.prodname_code_scanning %} will map the results to open pull requests on the branch and add the alerts as annotations on the pull request. For more information, see "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)." {% endif %} {% ifversion fpt or ghes > 3.1 or ghae-next %}