Skip to content

Commit efa1115

Browse files
Apply suggestions from code review
Rearranging some things to be more efficient, and paring down some of the language where possible.
1 parent 5d3f38c commit efa1115

File tree

1 file changed

+6
-14
lines changed

1 file changed

+6
-14
lines changed

content/actions/reference/security/secure-use.md

Lines changed: 6 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -115,29 +115,21 @@ Review the [`pull_request_target` trigger documentation](/actions/writing-workfl
115115

116116
For additional explanation, examples, and guidance on the risks of untrusted code checkout, see [Keeping your {% data variables.product.prodname_actions %} and workflows secure: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) from {% data variables.product.prodname_security %} and the [Dangerous Workflow check documentation](https://github.com/ossf/scorecard/blob/main/docs/checks.md#dangerous-workflow) from OpenSSF Scorecard.
117117

118-
## Good practices for mitigating untrusted code checkout risks
118+
### Good practices
119119

120120
There are a number of different approaches available to help you mitigate the risk of untrusted code checkout in an action workflow:
121121

122-
### Avoid potentially dangerous workflow triggers
122+
* Avoid using the `pull_request_target` workflow trigger if not necessary. Prefer using `workflow_run` for privilege separation between workflows as described in [Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests). Only use these workflow triggers when the workflow actually needs the privileged context.
123123

124-
Avoid using the `pull_request_target` workflow trigger if not necessary. Prefer using `workflow_run` for privilege separation between workflows as described in [Keeping your {% data variables.product.prodname_actions %} and workflows secure: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests). Only use these workflow triggers when the workflow actually needs the privileged context.
124+
* Avoid using the `pull_request_target` and `workflow_run` workflow triggers with untrusted pull requests or code content. Workflows that use these triggers must not explicitly checkout untrusted code, including from pull request forks or from repositories that are not under your control. Workflows triggered on `workflow_run` should treat artifacts uploaded from other workflows with caution.
125125

126-
### Do not use the `pull_request_target` and `workflow_run` workflow triggers with untrusted content
126+
* [{% data variables.product.prodname_codeql %}](/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql) can scan and detect potentially vulnerable {% data variables.product.prodname_actions %} workflows. [AUTOTITLE](/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning) for the repository and ensure that {% data variables.product.prodname_actions %} scanning is enabled.
127127

128-
Avoid using the `pull_request_target` and `workflow_run` workflow triggers with untrusted pull requests or code content. Workflows that use these triggers must not explicitly checkout untrusted code, including from pull request forks or from repositories that are not under your control. Workflows triggered on `workflow_run` should treat artifacts uploaded from other workflows with caution (i.e. as untrusted).
129-
130-
### Use {% data variables.product.prodname_codeql %} to detect potentially vulnerable workflows
131-
132-
[{% data variables.product.prodname_codeql %}](/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql) can scan and detect potentially vulnerable {% data variables.product.prodname_actions %} workflows. [Configure the default setup for {% data variables.product.prodname_codeql %}](/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning) for the repository and ensure that {% data variables.product.prodname_actions %} scanning is enabled.
133-
134-
### Use OpenSSF Scorecards to detect potentially vulnerable workflows
135-
136-
[OpenSSF Scorecards](#use-openssf-scorecards-to-detect-potentially-vulnerable-workflows) can help you identify potentially vulnerable workflows, along with other security risks when using {% data variables.product.prodname_actions %}.
128+
* [OpenSSF Scorecards](#use-openssf-scorecards-to-detect-potentially-vulnerable-workflows) can help you identify potentially vulnerable workflows, along with other security risks when using {% data variables.product.prodname_actions %}.
137129

138130
## Managing permissions for {% data variables.product.prodname_actions %} settings in your organization
139131

140-
You can practice the principle of least privilege for your organization's CI/CD pipeline with {% data variables.product.prodname_actions %} by administering custom organization roles. A custom organization role is a way to grant an individual or team in your organization the ability to control certain subsets of settings without granting full administrative control of the organization and its repositories.
132+
You can grant an individual or team in your organization the ability to control certain subsets of settings without granting full administrative control of the organization and its repositories.
141133

142134
{% data reusables.actions.org-roles-for-gh-actions %}
143135

0 commit comments

Comments
 (0)