CircleCI's Security Incident — Rotate Your Secrets Now

Happy New Year — now go rotate all your secrets. That’s the gist of the urgent notice CircleCI published yesterday, January 4th, advising all customers to immediately rotate any and all secrets stored in CircleCI. That includes environment variables, project-level API keys, and anything referenced in your pipeline configurations.

When a CI/CD platform tells you to rotate everything with that kind of urgency, without yet providing details on scope or impact, it’s time to take it seriously. And it raises some uncomfortable questions about how much trust we place in our build infrastructure.

What We Know So Far

#

The details are sparse at this point. CircleCI’s advisory says they’re “currently investigating” a security incident and that out of “an abundance of caution” customers should rotate all secrets. They’ve also recommended reviewing internal logs for unauthorized access from December 21, 2022 through January 4, 2023.

That two-week window is concerning. It suggests that whatever happened may have given attackers access to customer data for an extended period. CircleCI is one of the most widely used CI/CD platforms in the industry — their customer base includes startups and enterprises alike. The potential blast radius is significant.

OAuth tokens are another area of concern. If you’ve connected CircleCI to GitHub, Bitbucket, or other services via OAuth, those tokens could potentially have been exposed. CircleCI has stated they’ve already rotated Project API tokens and are working on additional mitigations.

The CI/CD Trust Problem

#

This incident highlights something I’ve been thinking about for years: CI/CD systems are some of the most privileged components in our infrastructure, yet they often receive less security scrutiny than production systems.

Think about what your CI/CD platform has access to:

• Source code for every project in your organization
• Deployment credentials for production environments
• API keys for third-party services
• Package registry tokens for publishing
• Cloud provider credentials for infrastructure provisioning
• Database connection strings for migrations and testing

Your CI/CD platform is, in many ways, a skeleton key to your entire operation. If an attacker compromises it, they potentially have access to everything: your code, your infrastructure, your secrets, and your deployment pipeline. They could inject malicious code that gets deployed automatically through your trusted pipeline.

This isn’t a new concern. The SolarWinds attack demonstrated the devastating potential of compromised build systems in 2020. The Codecov bash uploader incident in 2021 showed how a single compromised CI component could exfiltrate secrets from thousands of organizations. And now CircleCI joins the list.

Practical Response Steps

#

If your team uses CircleCI, here’s a prioritized action plan:

Immediate (today):

1. Rotate all environment variables and secrets stored in CircleCI
2. Rotate any OAuth tokens connected to CircleCI
3. Review and rotate deployment credentials that CircleCI had access to
4. Audit your CircleCI pipeline configs for any hardcoded secrets (you shouldn’t have any, but check)

Short-term (this week):

1. Review access logs for all systems that CircleCI had credentials for, looking for unusual activity since December 21
2. Check for any unexpected deployments or package publications during that window
3. Review GitHub/Bitbucket audit logs for repository access patterns
4. Consider whether any secrets that were exposed need further downstream rotation (e.g., if a database password was in CircleCI, rotate it and check for unauthorized access to that database)

Medium-term:

1. Evaluate your secrets management strategy — are you using a dedicated vault (HashiCorp Vault, AWS Secrets Manager) with short-lived credentials, or are you storing long-lived secrets directly in CI?
2. Implement credential rotation automation so future incidents like this aren’t a manual fire drill
3. Review whether you can reduce the privileges your CI/CD platform holds

Rethinking CI/CD Security Architecture

#

This is a good moment to step back and think about how we architect CI/CD security. The traditional model — store secrets in the CI platform and reference them in pipeline configs — is convenient but creates exactly this kind of concentrated risk.

Better approaches exist:

Short-lived credentials: Instead of storing permanent AWS access keys in CircleCI, use OIDC federation to get temporary credentials for each build. The credentials expire automatically, so even if they’re exfiltrated, the window of exposure is minutes rather than months.

Secrets vaults with dynamic secrets: Tools like HashiCorp Vault can generate unique, short-lived credentials for each CI run. Even if an attacker captures them, they expire quickly and can be traced to specific builds.

Least privilege: Does your CI pipeline really need admin access to your AWS account? In many organizations, CI credentials are far more permissive than necessary. Tighten those IAM policies.

Build provenance and verification: SLSA (Supply-chain Levels for Software Artifacts) provides a framework for ensuring that software artifacts haven’t been tampered with during the build process. It’s still maturing, but the concepts are sound.

My Take

#

Every few months, we get another reminder that the software supply chain is a critical attack surface. SolarWinds, Codecov, the npm and PyPI package poisoning campaigns, and now CircleCI. The pattern is clear, and yet many organizations still treat CI/CD security as an afterthought.

I’m not going to tell anyone to stop using CircleCI — breaches can happen to any platform, and what matters more is how they respond and what systemic changes they make. But I am going to say this: if your organization’s response to this incident is simply “rotate secrets and move on,” you’re missing the larger lesson.

The question isn’t “is CircleCI secure?” It’s “how much damage can any single compromised component do to our systems?” If the answer is “a lot,” that’s an architecture problem, not a vendor problem. Start minimizing that blast radius now, before the next incident gives you another urgent reason to.