Commit 5361e31a authored by Tim Poffenbarger's avatar Tim Poffenbarger Committed by Nick Gaskill

Include verbiage around supply chain attacks

parent ab1e5eb4
...@@ -603,11 +603,18 @@ to enable the `restrict_user_defined_variables` setting. The setting is `disable ...@@ -603,11 +603,18 @@ to enable the `restrict_user_defined_variables` setting. The setting is `disable
## Limit the environment scope of a CI/CD variable ## Limit the environment scope of a CI/CD variable
You can limit the environment scope of a variable by By default, all CI/CD variables are available to any job in a pipeline. Therefore, if a project uses a
[defining which environments](../environments/index.md) it can be available for. compromised tool in a test job, it could expose all CI/CD variables that a deployment job used. This is
a common scenario in supply chain attacks. GitLab helps mitigate supply chain attacks by limiting
the environment scope of a variable. GitLab does this by
[defining which environments and corresponding jobs](../environments/index.md)
the variable can be available for.
To learn more about scoping environments, see [Scoping environments with specs](../environments/index.md#scoping-environments-with-specs). To learn more about scoping environments, see [Scoping environments with specs](../environments/index.md#scoping-environments-with-specs).
To learn more about ensuring CI/CD variables are only exposed in pipelines running from protected
branches or tags, see [Protect a CI/CD Variable](#protect-a-cicd-variable).
## Deployment variables ## Deployment variables
Integrations that are responsible for deployment configuration can define their own Integrations that are responsible for deployment configuration can define their own
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment