Key points
- A long-lived cloud key stored as a CI secret gives anyone who can read that secret the same standing access the pipeline has. In three widely reported incidents (Codecov in 2021, CircleCI in 2022 to 2023, and the tj-actions/changed-files GitHub Action in 2025) the asset that left the pipeline was the secrets inside it, not the application code.
- OpenID Connect (OIDC) workload identity federation replaces the stored key with a token issued per job that a cloud role trusts only for a named repository and environment. GitHub Actions, Azure Pipelines, AWS, Azure and Google Cloud support it today.
- The June 2023 CISA and NSA guidance on defending CI/CD environments says to minimize long-term credentials, secure secrets, require two-person review and keep audit logs. The mapping below turns each recommendation into a specific pipeline change and names who owns it.
- Sequence the work: inventory and pin in the first week, move one production service to OIDC with a named release approval in the first month, and retire every stored cloud key while bringing infrastructure code under plan-per-pull-request review in the first quarter.
Why the stored cloud key is the most valuable secret in your pipeline
Most software teams at organizations of 50 to 1,000 employees inherited their delivery pipeline. It grew one workflow at a time, and somewhere in the repository or project settings there is an AWS access key pair, an Azure service principal secret or a Google service account file that was pasted in the day the first deploy was wired up. It works, so nobody touches it.
That key is a long-lived credential. It authenticates whoever presents it, from any network, until a person rotates it. It usually carries broad permissions, because scoping it down meant breaking a deploy at the wrong moment. The CISA and NSA Cybersecurity Information Sheet Defending Continuous Integration/Continuous Delivery (CI/CD) Environments, released June 28, 2023, lists exposure of secrets as one of the pipeline's attack surfaces and defines it as "security key compromise and insecure secrets management within the pipeline, such as hardcoding access keys or passwords into infrastructure as code (IaC) templates."
The decision this article supports belongs to the engineering leader who owns the release pipeline: a CTO, VP of Engineering or platform lead, working with whoever owns security review and the cloud accounts. The question is whether to remove long-lived cloud credentials from CI now, and what the release path should look like once they are gone. The sections below give the evidence, a decision table, a control mapping against the CISA and NSA guidance, and a sequence a platform lead can run.
Three incidents where the CI secret was the payload
None of these incidents started by attacking a victim's cloud account. Each one reached cloud and third-party credentials through the pipeline that was holding them.
| Incident | What happened | What left the pipeline | What defenders had to do |
|---|---|---|---|
| Codecov Bash Uploader January 31 to April 1, 2021 |
A third party gained access to the credential that could modify Codecov's Bash Uploader through an error in a Docker image build, then periodically altered the script so that it ran env in customers' CI jobs and sent the output to an outside server. A customer caught it by comparing the script's checksum against the published value. |
Any credentials, tokens or keys present as environment variables in the CI runner when the script executed. | Codecov told affected users to re-roll every credential held in CI environment variables and audit how those credentials had been used (Codecov security update, April 15, 2021). |
| CircleCI December 16, 2022 to January 4, 2023 |
Malware on an engineer's laptop stole a valid, 2FA-backed single sign-on session. Because that engineer could generate production access tokens, the attacker reached a subset of production stores, exfiltrated data on December 22, 2022, and extracted encryption keys from a running process. | Customer environment variables, tokens and keys for third-party systems. | CircleCI told every customer to rotate all secrets stored on the platform and to investigate their own systems for the period from December 16, 2022 until rotation was complete (CircleCI incident report). |
| tj-actions/changed-files March 14 to 15, 2025 (CVE-2025-30066) |
Attackers retroactively repointed the GitHub Action's version tags to a malicious commit. The injected code read the runner worker's memory and printed its secrets into workflow logs. The advisory counts more than 23,000 repositories using the action. | Whatever the job held in memory. CISA's catalog entry names AWS access keys, GitHub personal access tokens, npm tokens and private RSA keys as examples. | Rotate exposed secrets, pin the action to a commit rather than a tag, and review logs for the window (GitHub advisory GHSA-mrrh-fwg8-r2c3). CISA added the CVE to its Known Exploited Vulnerabilities catalog on March 18, 2025, with an April 8, 2025 remediation date for federal agencies. |
Dates and scope are taken from each vendor's own disclosure, the GitHub advisory and the CISA catalog, all accessed November 8, 2026. ITECS had no part in investigating these incidents; the summaries are drawn from the public record.
What the three have in common
In each case the pipeline was not the prize. It was the place where long-lived keys to other systems were kept, and reading it was enough. A credential that expired when the job ended would have been worth minutes to the attacker rather than months. That is the ITECS reading of these incidents, and it is why the credential model is the first thing to change.
Stored long-lived keys versus OIDC workload identity federation
With OIDC federation, a CI job does not present a stored secret. It requests a signed token from the CI platform's identity provider, and the cloud validates that token's claims (which repository, branch or environment issued it, and for which audience) against a trust policy before issuing credentials that live only for that job. GitHub's documentation describes the result as no cloud secrets to duplicate into the CI system, with a short-lived access token that is valid for a single job and then expires. Microsoft's guidance for Azure Pipelines recommends workload identity federation for Azure Resource Manager service connections because it "eliminates the need for secrets and secret management." On AWS, the pipeline's identity provider is registered in IAM and a role's trust policy decides which workflows may assume it; AWS recommends evaluating the subject claim in that trust policy so that only the intended repository, branch or environment can use the role.
| Criterion | Stored long-lived key | OIDC workload identity federation |
|---|---|---|
| Lifetime | Valid until a person rotates it, which in practice is rarely. | Issued per job and expires automatically when the job ends. |
| Blast radius if a log, runner or CI database leaks | Standing access to the cloud account from anywhere, with whatever permissions the key carries, until discovery and rotation. | A token that is already expired or minutes from expiring, usable only for the role and conditions in the trust policy. |
| Rotation effort | Manual, coordinated across every place the key is stored, and usually deferred. | None for the pipeline; the cloud issues fresh credentials every run. |
| Scoping | One key is often shared across repositories and across staging and production. | Trust conditions on the subject claim bind a role to one repository, branch or environment; production can have its own role. |
| Audit trail | Every caller using the key looks the same in cloud logs. | Each cloud session carries the workflow identity in its claims, so a deploy traces back to a run, repository and environment. |
| Setup effort | Paste a secret. | Register the identity provider in each cloud, create a role per repository and environment with trust conditions, grant the job permission to request a token, and swap the login step in each workflow. |
| Where it does not fit | Everywhere it is still used by default. | Targets without an OIDC-aware identity layer, some third-party SaaS APIs, and bootstrap credentials. The CISA and NSA sheet notes that long-term credentials sometimes must be used, and that their private keys must then be carefully managed and protected. |
Comparison method: criteria are the ones that decide blast radius and operating cost for a mid-market platform team, as assessed by ITECS. Vendor capabilities are from the GitHub, Microsoft Learn and AWS documentation accessed November 8, 2026. ITECS builds pipelines on these platforms; it has no commercial relationship with them to disclose beyond ordinary customer use.
Two current details matter when you write trust policies. GitHub repositories created after July 15, 2026 use an immutable subject-claim format that includes owner and repository IDs, so a trust policy must match the format the repository actually emits. And Azure DevOps is retiring its own token issuer for workload identity federation on July 1, 2027 in favor of the Microsoft Entra issuer; existing service connections flagged as deprecated should be converted rather than recreated. Both are documented on the pages linked above.
Mapping the CISA and NSA guidance to pipeline changes
The information sheet groups its mitigations into authentication and access, development environment, and development process. The table takes the items that bear on the credential question and turns each into a change a platform lead can schedule. The ownership column is ITECS's suggestion for a team with an engineering lead, a platform engineer and a security owner; adjust it to your organization.
| CISA and NSA mitigation | What the sheet says | Pipeline change | Who owns it |
|---|---|---|---|
| Minimize the use of long-term credentials | For software-to-software authentication, avoid software-based long-term credentials as much as possible; in cloud environments, use the cloud's temporary and ephemeral credentials. | OIDC federation for every job that touches a cloud account; delete the stored cloud keys once each service has cut over. | Platform lead builds; cloud account owner approves each trust policy. |
| Secure secrets | Never pass secrets in plaintext anywhere in the pipeline; use the CI tool's secrets management and indirect references; keep keys out of IaC templates. | Secrets that cannot be federated (some third-party APIs) move to environment-scoped secrets released only after protection rules pass; scan repositories and infrastructure code for embedded keys. | Platform lead implements; security owner sets the policy and reviews findings. |
| Utilize two-person rules for all code updates | Separate the person who writes a change from the person who approves it. | Required pull-request review on protected branches, and a named approver on the production environment who is not the person who triggered the run. | Engineering lead decides who can approve production. |
| Implement least-privilege policies for CI/CD access | Role-based access control following least privilege, with separation of duties. | One cloud role per repository and environment, holding only the permissions that deploy needs; staging and production never share a role. | Cloud account owner. |
| Add signature to CI/CD configuration and verify it; restrict untrusted libraries and tools | Treat pipeline configuration and the tools it pulls in as code whose integrity must be verified. | Pin every third-party action or task to a commit SHA rather than a tag, allow-list which actions may run, and review changes to pipeline definitions like any other code. | Platform lead. |
| Keep audit logs | A log should show who committed, reviewed and deployed what, when and where, so an incident can be reconstructed. | A release record per deploy (commit, artifact, approver, time) kept with the run, and cloud sessions whose claims identify the workflow that opened them. | Platform lead produces; security owner consumes in monitoring. |
| Keep CI/CD tools and operating systems up to date | Update the CI/CD tools on a regular schedule and maintain the software underneath them. | A patch cadence for self-hosted runners and agents, or a move to ephemeral hosted runners so there is nothing long-lived to patch. | Platform lead, or the managed DevOps provider. |
| Implement network segmentation and traffic filtering | Segment networks and functions so a compromise in one place does not reach another. | Runners that deploy to production live in their own network or project; build runners have no path to production data. | Network and cloud owner. |
The sheet also covers endpoint detection on developer machines, software bills of materials, composition analysis and code scanning. Those matter, and the CircleCI incident shows why endpoint controls belong in the plan, but they do not change the credential model and are left for a separate piece of work.
What a release path you can trust looks like
Removing stored keys is one half of the change. The other half is making sure a release can only reach production through a path where a person has approved it and a rollback has been rehearsed. In the CI/CD pipelines ITECS builds and runs for software teams, each change is built once, tested and checked in staging, approved by a named person before production, and can roll back; jobs sign in to the cloud with a short-lived OIDC token that a role trusts only for a named repository and environment, and third-party actions run pinned to a commit. The sequence below is that release path with the controls called out.
1Build once
One build per change produces the artifact that every later stage deploys. Tests and scans the team has marked as required gate the merge. If the build or a required check fails, nothing moves.
2Deploy to staging and rehearse the rollback
The same artifact deploys to staging with a short-lived token for the staging role. Smoke tests run there, and so does the rollback, so that redeploying the last good build is a tested step rather than a theory.
3Wait for a named approver
Production waits until a person the organization has named approves the release, and the approval is recorded with the run. In GitHub Actions this is a required-reviewers rule on the production environment, with the option to prevent self-review. In Azure Pipelines it is an approval or check on the environment or service connection; because checks are configured by the resource owner outside the YAML, someone editing the pipeline file cannot remove them.
4Deploy the approved artifact to production
The artifact that passed staging deploys with a token for the production role. The release record notes what changed and who approved it.
5Watch, and let a person decide to roll back
Error rates and latency are checked after the release. The pipeline can redeploy the last good build, and a named person, the release approver or the on-call engineer, decides when.
A budget note on GitHub plans
GitHub's documentation states that environments, environment secrets and deployment branches in private or internal repositories require GitHub Pro, Team or Enterprise, and that on Free, Pro and Team plans the other deployment protection rules, including required reviewers and wait timers, are available only for public repositories. If your production repositories are private and you are not on Enterprise, the approval gate has to be funded or implemented elsewhere before the release path above is real.
The same discipline applies to the infrastructure the pipeline deploys onto. Hardcoded keys in infrastructure templates are exactly the exposure the CISA and NSA sheet names, and a plan posted on every pull request makes any new credential visible to a reviewer before it is applied. In the infrastructure as code work ITECS does, remote state is locked from the first day, a Terraform or OpenTofu plan appears beside every pull request, a named person approves each apply, console write access narrows to a few named people, and a scheduled drift check tells a named owner when the account and the code disagree.
A sequencing plan a platform lead can run
The order below is ITECS's recommendation for a team that has to keep shipping while it changes the pipeline. Each phase has a validation and a stop condition, so the work can pause without leaving the pipeline half-migrated.
1First week: inventory and pin
List every stored cloud credential in CI: repository and organization secrets, variable groups, service connections and anything in a self-hosted runner's environment. For each, record who created it, what it can do and which workflows use it. Run a job that prints its environment variable names to see what a compromised step would see. Pin every third-party action or task to a commit SHA. Decide, in writing, which checks block a merge and who approves production. Stop condition: if the inventory finds a key with administrative rights shared across repositories, rotate it that day rather than waiting for the migration. If cloud logs show that key used from outside your pipelines, treat it as an incident and follow your breach response process.
2First month: one production service, end to end
Register the CI platform's identity provider in the cloud account, create one deploy role bound to that service's repository and production environment, grant the workflow permission to request a token, and swap the login step. Add the staging stage, the required approver and the rollback rehearsal. Validation: a run from another repository or branch must fail to assume the role; the rollback must be exercised in staging; two production releases must complete through the new path. Then delete that service's stored key. Stop condition: any job that still needs the old key gets a ticket and a plan, not a standing exception.
3First quarter: everything else
Migrate the remaining services with the same pattern. Convert Azure DevOps service connections to workload identity federation on the Microsoft Entra issuer. Revoke, not just delete, every stored cloud key. Bring the cloud account under Terraform or OpenTofu with a plan on every pull request and a scheduled drift check, and narrow console write access to named people. Validation: a monthly report with three numbers: stored cloud keys remaining (target zero), production releases with a recorded approver (target all), and rollback rehearsals performed. Stop condition: if a service cannot federate because its target has no OIDC-aware identity layer, document the exception, scope the remaining key as narrowly as the platform allows, and put a rotation date on it.
Ownership through all three phases is simple to state. The engineering lead decides which checks block a merge and who approves production. The platform lead builds and runs the pipeline. The security owner reviews trust policies, sets secrets policy and consumes the audit trail. The cloud account owner approves roles. None of those decisions should be made by the person who happens to be editing the workflow file.
Where ITECS fits
Teams that do not have a platform engineer to run this plan can have ITECS do it inside their own repositories and cloud accounts. ITECS's DevOps and platform engineering practice works for software teams in Dallas-Fort Worth and across the United States. Pipeline changes land as pull requests the team's engineers review, and the team keeps every account, repository, role and runbook. Work starts with a DevOps assessment that reviews pipelines, platform, infrastructure code, cloud spend, on-call and release practice, and ends in a written plan that sets the order of work; scope and quote come from that plan, not from a rate card. After the build, ITECS can keep running the pipelines, clusters, infrastructure code and on-call under managed DevOps, with its 24/7 network operations center covering the nights and weekends a team cannot staff, while a person the client names still approves every production release.
For organizations that want the controls around the pipeline reviewed as well, the ITECS cybersecurity assessment is the broader starting point.
Start with the DevOps assessment
A review of your pipelines, platform, infrastructure code, cloud spend, on-call and release practice, with the people who run them, ending in a written plan that puts the stored-key migration in order with everything else.
Request a DevOps assessmentSources and methodology
- CISA — CISA and NSA Release Joint Guidance on Defending Continuous Integration/Continuous Delivery (CI/CD) Environments — primary; release date and summary; accessed November 8, 2026.
- NSA and CISA — Defending Continuous Integration/Continuous Delivery (CI/CD) Environments, Cybersecurity Information Sheet, June 2023 — primary; attack-surface definition and mitigation wording; accessed November 8, 2026.
- Codecov — Bash Uploader Security Update (April 15, 2021, with later updates) — primary; timeline, mechanism and customer guidance; accessed November 8, 2026.
- CircleCI — Incident report for January 4, 2023 security incident — primary; timeline, entry path and customer guidance; accessed November 8, 2026.
- GitHub Advisory Database — GHSA-mrrh-fwg8-r2c3 / CVE-2025-30066, tj-actions/changed-files — primary; window, mechanism, repository count and remediation; accessed November 8, 2026.
- CISA — Known Exploited Vulnerabilities Catalog, entry for CVE-2025-30066 — primary; date added, due date and example secret types; accessed November 8, 2026.
- GitHub Docs — About security hardening with OpenID Connect — primary; token lifetime, benefits and subject-claim format change; accessed November 8, 2026.
- GitHub Docs — Configuring OpenID Connect in Amazon Web Services — primary; AWS trust-policy conditions; accessed November 8, 2026.
- GitHub Docs — Managing environments for deployment — primary; required reviewers, self-review prevention and plan availability; accessed November 8, 2026.
- AWS — Create an OpenID Connect (OIDC) identity provider in IAM — primary; identity provider and role model; accessed November 8, 2026.
- Microsoft Learn — Connect to Microsoft Azure with an ARM service connection — primary; workload identity federation recommendation and issuer retirement; accessed November 8, 2026.
- Microsoft Learn — Define approvals and checks (Azure Pipelines) — primary; checks configured outside YAML by resource owners; accessed November 8, 2026.
Methodology: incident facts and vendor capabilities are taken from the primary sources above. Sections labeled as ITECS analysis, including the common-factor reading of the incidents, the decision criteria, the ownership column and the sequencing plan, are ITECS interpretation. Descriptions of ITECS services reflect the itecs.ai DevOps pages as of November 8, 2026. No client incident is described. This article should be revised if GitHub, Microsoft or AWS change their OIDC claim formats or plan entitlements, or if CISA and NSA revise the information sheet.
continue reading
More ITECS blog articles
About ITECS Team
The ITECS team consists of experienced IT professionals dedicated to delivering enterprise-grade technology solutions and insights to businesses in Dallas and beyond.
View full profile and articles