A pipeline needs credentials (deploy keys, API tokens, database passwords) but the YAML file itself is usually checked into the same repository everyone with read access can see. CI platforms solve this with an encrypted secrets store, referenced by name in the workflow file but never exposed in it or in build logs:
- run: ./deploy.sh
env:
API_KEY: ${{ secrets.PRODUCTION_API_KEY }}
secrets.PRODUCTION_API_KEY is configured in the repository's (or organization's) settings, not the file — anyone can read the workflow, nobody can read the secret's actual value from it. Most platforms also actively scrub known secret values out of log output, replacing them with a masked placeholder if a step accidentally prints one, as a second line of defense against an accidental echo $API_KEY in a debug step.
A subtlety worth knowing for anything handling untrusted input: a workflow triggered by a pull request from a fork typically runs with a reduced permission set and without access to repository secrets by default on major platforms — specifically to prevent an attacker from opening a PR that adds a step to print secrets.PRODUCTION_API_KEY to the build log and reading it back out. Bypassing that protection (some platforms offer a separate, more privileged trigger for "PR target" workflows) needs real care about exactly what untrusted code that privileged workflow is allowed to execute.