Why you should care about secrets in CI CD

If you like waking up to support tickets and emergency rotates then by all means skip this guide. If you prefer not to leak API keys into logs and wallpaper your repo with compromised tokens then keep reading. GitHub Actions secrets are the basic tool for secrets management in GitHub based CI CD pipelines. They let your workflows use sensitive values without plastering them into your code or job logs.

Where to add a secret and what the UI does for you

For most teams the web UI is the easiest option. Open repository settings or organization settings and add a secret using the Secrets panel. The web UI encrypts the value so the raw secret never sits in plain text on GitHub. This is the safe and boring route and it works for the majority of use cases.

When you need the API or automation

If you automate secret provisioning with scripts or use a tool like Terraform you will use the REST API or the GitHub CLI. The GitHub REST API expects an already encrypted blob when you create or update a secret. That means you must fetch the repository or organization public key and encrypt the value before sending it to the API. The API endpoints include the public key resources for repos and orgs so automation can do this in a reproducible way.

How to encrypt for the API in plain language

• Fetch the target public key for the repo or org with the public key endpoint.
• Use a libsodium sealed box implementation to encrypt the clear text using that public key. The result becomes an encrypted value you base64 encode and send to the API.
• If you do not want to write that code use the official GitHub CLI. It handles encryption and the API call for you in one command.

In short automation needs to respect the public key step. The UI hides that for you. The CLI makes it painless.

Commands you will actually use

Want to avoid writing crypto code and still automate things Use the GitHub CLI for most tasks. It wraps the encryption and the API request so you do not have to wrestle with libsodium directly.

# create or update a repo secret with the GH CLI
gh secret set MY_SECRET --body 'super secret value'

How to reference secrets in a workflow

Inside a workflow use the secrets context like this

steps:
  - name: Use secret
    run: echo "Placeholder not the real secret"
    env:
      MY_API_KEY: $

Pass secrets into environment variables or to commands carefully. Use clear environment variable names so it is obvious what must never be printed. Avoid echoing secrets or writing them to files that will be archived in artifacts.

Testing without turning the logs into a crime scene

Run a dry job that sets placeholder values to confirm the secret name, path, and permissions are correct. Replace the placeholder with the real secret only after the job flow is validated. If a step might print something use masked outputs or conditional logic to suppress the value. GitHub Actions can mask values but it is not a magic bullet. Masking will hide matches in logs but it will not prevent a script from intentionally or accidentally posting the secret elsewhere.

Repository secrets versus organization secrets

Use repository level secrets for project specific keys and organization level secrets for credentials shared across many repos. Organization secrets let you restrict access by repository so you keep some control. Your choice will depend on least privilege and your DevOps workflows.

Practical security tips that do not require sainthood

• Prefer the official GitHub CLI for automation. It reduces the chance of getting the encryption step wrong.
• Rotate keys regularly and treat secrets as disposable. Rotation is boring but effective.
• Avoid embedding secrets in container images or build artifacts.
• Use environment variable names that make accidental logging obvious.
• Grant the minimum repository or environment access needed for the job to run.

Wrap up

GitHub Actions secrets give you a solid way to keep CI CD credentials out of source code and logs. Use the UI when you can and the GitHub CLI when you need automation. If you must use the API remember to fetch the public key and encrypt with a libsodium sealed box before you send anything. Test with placeholders and mask any output that might reveal a value. Follow these steps and you will reduce the chance of waking up to a support incident that starts with the words sorry we leaked your token.