Secrets management in a CI/CD pipeline is about keeping control of the passwords, tokens and keys that pipelines use to build and deploy software: where they live, who can reach them, how long they stay valid and how quickly they can be replaced. This article walks through it using a scenario that is explicitly illustrative.
Quick Overview
What you will learn:
- Which credential-handling mistakes OWASP describes for CI/CD environments
- How to replace static keys with short-lived tokens through OIDC
- How to set up a secrets manager, rotation and repository scanning
- Who on the team owns each piece
Who this article is for:
- DevOps engineers and platform teams
- Application security and DevSecOps specialists
- Development team leads
Reading time: 8 minutes
A Note Up Front: This Is an Illustrative Scenario
The company described below is fictional. It is a composite of common situations in a mid-size organization, not an account of a real rollout. There are no names, figures or results, because none of them come from measurement. Every step is grounded in the guidance and documentation listed in the sources.
Why Pipeline Secrets Are a Risk of Their Own
OWASP lists this problem as CICD-SEC-6, “Insufficient Credential Hygiene”, in its CI/CD security risks (owasp.org). Attackers go after the secrets and tokens scattered across pipelines, helped by weak access control around credentials, insecure storage and overly broad permissions. OWASP names the usual mistakes:
- credentials pushed to a repository, which stay in the commit history even after they are deleted from the branch;
- credentials used in builds and deployments with no control over which pipeline and which step can reach them;
- secrets left in container image layers, needed only while the image was being built;
- secrets printed to build logs;
- credentials nobody rotates, under an “if it isn’t broken, don’t fix it” mindset.
Where the Scenario Starts
The company has several development teams. Most use GitHub Actions, the data analytics department uses GitLab CI, and applications run in a public cloud. Pipelines sign in to the cloud with static keys stored as repository secrets. One broadly privileged key is shared by many pipelines, and the person who created it moved to another team long ago. Nobody knows exactly how many such keys exist. It ticks almost every box on the OWASP list.
Take Stock and Cut Privileges
OWASP’s first recommendations are organizational: keep mapping credentials across the whole engineering ecosystem, from code to deployment; give each credential exactly the permissions its consumer needs; and avoid sharing the same credentials across contexts. In the scenario, the platform team builds a register covering each secret, the repository and environment it sits in, what it unlocks and who owns it.
GitHub’s documentation on docs.github.com offers ways to narrow the blast radius straight away. Organization secrets can be limited to selected repositories, and access to environment secrets can require approval from designated reviewers. In GitLab, a CI/CD variable can be marked as protected, so it is only exposed to pipelines on protected branches and tags, and masked in job logs (docs.gitlab.com).
Short-Lived Credentials Instead of Static Keys
OWASP recommends temporary credentials over static ones, and in pipelines that means OpenID Connect (OIDC). According to GitHub’s documentation, once trust is configured with the cloud provider, the workflow requests a short-lived access token that is valid for a single job and then expires on its own. Cloud keys no longer need to be copied into GitHub as long-lived secrets. GitLab offers the same through ID tokens (JWTs) that a job declares with the id_tokens keyword. On Azure, the counterpart is workload identity federation in Microsoft Entra ID, which trusts tokens from an external identity provider such as GitHub (learn.microsoft.com).
In the scenario, the team starts with the production deployment pipelines, because their keys carry the widest permissions. Trust is scoped to a specific repository and branch, in line with OWASP’s advice to restrict credentials to predetermined conditions.
A Secrets Manager and Rotation
Not every secret can be swapped for a federated token. Database passwords and API keys for third-party services go into a secrets manager. GitLab supports external secrets providers including HashiCorp Vault, Google Cloud Secret Manager, Azure Key Vault and AWS Secrets Manager. Unlike CI/CD variables, which are always available to jobs, a secret from an external provider has to be requested explicitly by the job. Google Secret Manager keeps successive versions of a secret, so you can roll back after a bad change (cloud.google.com). AWS Secrets Manager rotates secrets automatically, on demand or on a schedule (aws.amazon.com).
Scan Repositories and Logs
OWASP (owasp.org) recommends catching secrets in three places: with an IDE plugin for local changes, with automatic scanning on every push, and with periodic scans of the repository and its history. GitHub’s push protection goes a step further: it blocks a push that contains a recognized secret before the secret ever reaches the repository, rather than raising an alert after the fact. Logs need separate attention. GitHub Actions automatically redacts secret values in workflow logs, but the documentation warns that redaction is not guaranteed, because a secret can be transformed and the runner only redacts secrets used in the current job. Artifacts need checking too: image layers, binaries and Helm charts.
Roles and the Bigger Picture
- Platform / DevOps team: configures OIDC, the secrets manager and pipeline templates.
- Cloud administrator: defines the trust relationships and least-privilege roles.
- Application security (DevSecOps): sets the rules, runs scanning and owns the leak response, including revoking and replacing a secret.
- Repository owners: keep the register of secrets for their projects up to date.
NIST SP 800-204D, published in February 2024 on csrc.nist.gov, provides the wider frame: strategies for building software supply chain security into CI/CD pipelines in a DevSecOps model. Secrets are one layer among several, alongside artifact provenance, attestations and SBOMs.
Read Also
- Building a CI/CD Pipeline From Scratch: how a pipeline is put together from the first commit
- GitHub Actions for Deployment Automation: deployments with GitHub Actions step by step
- Cloud Identity and Access Management (IAM): the roles and permissions pipelines rely on
Build Your Skills
Two trainings cover this topic: GitHub Actions and GitHub Advanced Security and CI/CD Implementation With GitLab CI. The first covers CI/CD workflows and secret scanning; the second covers configuring GitLab pipelines, variables and secrets included. Get in touch to tailor the scope to your team.
Frequently Asked Questions (FAQ)
Where Do You Start With a Secure CI/CD Rollout?
Start by taking stock of credentials and applying least privilege. Then replace static cloud keys with short-lived OIDC tokens, move the remaining secrets into a secrets manager and switch on repository scanning. That order deals with the most far-reaching secrets first.
What Is DevSecOps?
DevSecOps is a way of building software in which security is part of the development and operations teams’ work from the start rather than a separate stage at the end. NIST SP 800-204D describes it as a flexible, agile development paradigm built around CI/CD pipelines and shows how to bring software supply chain security into them.
How Should You Store Secrets in GitHub Actions and GitLab CI?
In GitHub Actions, secrets live at the organization, repository or environment level, with access limited to selected repositories and approval required for environment secrets. In GitLab CI, variables can be protected and masked, and sensitive values can be pulled from an external secrets manager. Wherever you can, an OIDC token beats a stored key.
How Do You Monitor CI/CD Pipelines for Security?
Track which pipelines can reach which secrets, scan repositories and their history, review build logs for leaks and inspect artifacts, container image layers included. OWASP also recommends regularly detecting stale credentials and rotating every static one.