Secrets and environments

A secret rarely leaks because of an attack. It leaks because a developer in a hurry added echo $API_KEY to check that the variable was being passed correctly, the run log sat in a public repository for six months, and nobody remembered it. It also leaks because a token was passed as a command-line argument — and is therefore visible in the runner's process list — or because a curl command in verbose mode copied the authorization header into its output.

GitHub automatically masks secrets in logs by replacing their exact value with asterisks. This protection is real but fragile by design: it works by string comparison. If the secret is encoded, split up, or printed one character at a time, the masking no longer recognizes anything and the value appears in plain text. Understanding where this protection stops is more useful than treating it as a safety net.

Secrets or variables: the right distinction

GitHub offers two kinds of storage, in the repository settings.

Variables (vars) are readable in plain text in the interface and displayed in logs. They are meant for configuration rather than access rights: an API URL, a region name, a project identifier, a logging level.