How CDQ Unblocked the Secrets Bottleneck That Slowed Down 30 Developers

CDQ is a master data management company that helps enterprise organizations build and maintain trusted business partner data. Its engineering team worked across 350 GitHub repositories. Its secrets management setup technically worked, but required the infrastructure team to manually touch almost every change.

The stack combined a password manager, a self-hosted secrets engine, and a cloud key management service, with a file-based encryption tool handling encryption for secrets stored in GitHub. That setup solved encryption, but created a visibility problem: when a developer opened a pull request touching a secrets file, reviewers saw hashes, not values. There was no way to know what was changing without decrypting locally, which added manual work to every single PR review.

Access to the decryption keys was restricted to the infrastructure team. So every time a developer needed to update a secret in Kubernetes, they created a Jira ticket, waited for the infra team to read the secret from the middleware, update the secrets YAML, re-encrypt it, and open a pull request. With 30 developers and 350 repositories, the two-person infra team handled secrets update requests one ticket at a time.

"It was problematic," said Marek Sierociński, Tech Lead on CDQ's infrastructure team. "Developers needed it right now in production and they didn't want to wait for us to do everything manually."

The infra team spent its time answering tickets instead of on higher-priority infrastructure work, and the load only grew with every new developer, workflow, or repo. Those inefficiencies prompted the search for a centralized secrets manager.

The team evaluated native GitHub Secrets, but GitHub environments (the mechanism that lets you have different secret values per environment) can't be created globally. They're scoped per repository. With 350 repositories, provisioning environments and secrets through Terraform would've meant running applies across all 350 repos.

GitHub's REST API also doesn't expose secret values. When Terraform fetches a secret to compare against its desired state, it gets nothing back. The provider assumes the secret has changed and recreates it. In practice, using GitHub Secrets would've made Terraform recreate all environments and all secrets across every repository. A single repo could take 10 minutes to process.

"With GitHub Secrets you'd end up recreating all environments and secrets every time you tried to change anything," Marek said. "One repository could take 10 minutes because our file-based encryption is so slow."

The team also ruled out HashiCorp Vault and AWS Secrets Manager. Vault is a building-block tool: extending it to cover approval workflows, a developer-friendly organizational model, and self-service access would have required significant custom engineering on top, plus ongoing Vault expertise to operate. AWS Secrets Manager only supported single-cloud infrastructure. CDQ needed a portable secrets management solution with workflows built in.

Marek spent significant time on evaluation and built a formal comparison across four shortlisted providers. Infisical won on a combination of factors, but its organizational model stood out the most. The folder-and-environment structure, where secrets can be organized across folders and environments simultaneously, mattered because whatever they chose would have to serve hundreds of repos across environments.

As a European company, the team also required EU-hosted servers, 99.9% uptime, and support for both read-only and read-write Terraform providers. Infisical met all of these requirements.

"I feel Infisical is made by developers for developers," Marek said. "This unique two-dimensional structure, folders and environments at the same time, there's no other product that has it right now. I think that is gold."

The granular role-based access control (RBAC) and approval workflows were equally important. CDQ has tech leads embedded in each engineering team. Marek configured those tech leads as reviewers for specific folders in Infisical, so secret updates within a team's scope could be approved without involving the infrastructure team. The approval view shows the key, the value, the comment, and who is requesting, so a reviewer can decide without any manual work.

Secret references also addressed the operational problem of secrets being duplicated across services. Infisical's reference model meant a shared credential could be defined once and linked wherever it's needed, without copies drifting out of sync.

CDQ simplified how secrets are managed across its infrastructure.

CDQ's GitHub Actions migration is complete. Today, the only native GitHub Secret stored in any repository is the Infisical client ID and client secret. Everything else flows through Infisical.

That paid off when a code-analysis tool update introduced a new security rule for GitHub workflows, requiring a change to CI configuration across the organization. Because CDQ had already migrated to Infisical, they didn't have to enumerate every secret used by every workflow in every repository, work that would previously have taken weeks of auditing.

Marek fixed it in a single large pull request. Because only the Infisical client ID and client secret needed to be declared explicitly, one change that was identical in every repository did the trick.

"I could not imagine the impact if we were still using native GitHub Secrets," Marek said. "I don't know how many hours of work that would have been, finding out who is using which secret in which repository, which component. It would have been a nightmare."

Terraform is where CDQ gained the most day-to-day efficiency. The infrastructure team configured a machine identity for Atlantis (a Terraform pull request automation tool) and set up an Infisical Terraform data source. Developers who need secrets in their Terraform configurations get a single snippet they paste into their stack, which replaces the old encryption workflow, key setup, and Jira tickets.

"A developer came to me and said I want to have these secrets in my Terraform," Marek said. "Instead of explaining that he needed to encrypt it himself, then do this and then that, I just sent him the snippet. He pasted it. Done. It works. He has all the secrets he needs."

CDQ has also moved Kubernetes repositories over to Infisical with a standardized pattern the infrastructure team built with Infisical's Kubernetes operator. Custom Helm charts expose a single flag (infisical-enable: true) that handles all the wiring: creating the necessary Infisical secret objects, linking them to the service, and pulling values into the pod.

If a developer needs access to a service like Elasticsearch, they reference the service name in the chart. The Helm chart resolves the rest without forcing the infra team to manually create secret objects, which could create configuration drift.

"For developers, it's super convenient," Marek said. "For us as infra, it's also very convenient. We have less management to do, it's much more granular, and there are fewer duplicated secrets."

Feedback from the broader engineering team has been positive, particularly for Terraform and GitHub Actions. The infrastructure team also built internal wrappers around Infisical's official GitHub Actions. A developer who needs secrets for a specific service, a package manager for instance, gives the wrapper the service name and it resolves the project, folder path, and environment automatically.

Marek's manager experienced this firsthand when he needed to add secrets to a workflow. "I just showed him: go here, add a folder, done," Marek said. "He was very happy with how easy it is."