At GitGuardian, we're all about secrets.

Managing your secrets well is imperative in software development. It's not just about avoiding hardcoding secrets into your code, your CI/CD configurations, and more. It's about implementing tools and practices that make good secrets management almost second nature. 

A quick overview of secrets management

What is a secret? It's any bit of code, text, or binary data that provides access to a resource or data that should have restricted access. Almost every software development process involves secrets: credentials for your developers to access your version control system (VCS) like GitHub, credentials for a microservice to access a database, credentials for your CI/CD system to push new artifacts to production.

There are three main elements to secrets management:

1. How you're making them available to the people/resources that need them.
2. How you're managing the lifecycle/rotation of your secrets.
3. How you're scanning to ensure that the secrets are not being accidentally exposed.

We'll look at elements one and two in terms of the secrets managers in this article. For element three, well, we're biased toward GitGuardian because we make it. Accidentally exposed secrets don't necessarily get a hacker into the full treasure trove, but even if they help a hacker get a foot in the door, it's more risk than you want. That's why secrets scanning should be a part of a healthy secrets management strategy.

What to look for in a secrets management tool

In the Secrets Management Maturity Model, hardcoding secrets into code in plaintext and then maybe running a manual scan for them is at the very bottom. Manually managing unencrypted secrets, whether hardcoded or in a .env file, is considered immature. To get to an intermediate level, you need to store them outside your code, encrypted, and preferably well-scoped and automatically rotated.

It's important to differentiate between a key management system and a secret management system. Key management systems are meant to generate and manage cryptographic keys. Secrets managers will take keys, passwords, connection strings, cryptographic salts, and more, encrypt and store them, then provide access to them for personnel and infrastructure in a secure manner. For example, AWS Key Management Service (KMS) and AWS Secrets Manager (discussed below) are related, but distinct brand names for Amazon.

Besides providing a secure way to store and provide access to secrets, a solid solution will offer:

• Encryption in transit and at rest: the secrets are never stored or transmitted unencrypted.
• Automated secrets rotation: the tool can request changes to secrets and update them in its files in an automated manner on a set schedule.
• Single source of truth: the latest version of any secret your developers/resources need will be found there and it is updated in real time as keys are rotated.
• Role/Identity scoped access: different systems or users are granted access to only the secrets they need under a principle of least privilege. That means a microservice that accesses a MongoDb instance only gets credentials to access that specific instance and can't pull the admin credentials for your container registry.
• Integrations and SDKs: the service has APIs with officially blessed software to connect common resources like CI/CD systems or implement access in your team's programming language/framework of choice.
• Logging & Auditing: you need to not only check your systems periodically for anomalous results as a standard practice, if you get hacked, the audit trail can help you track how and when each secret was accessed.
• Budget and scope appropriate: If you're bootstrapping with 5 developers, your needs will differ from a 2,000-developer company with federal contracts. Being able to pay for what you need at the level you need it is an important business consideration.

Open Source Secret Management Tools: Community-Driven Security Solutions

The landscape of open source secret management tools has evolved significantly, offering organizations cost-effective alternatives to proprietary solutions. These community-driven platforms provide transparency, customization capabilities, and freedom from vendor lock-in while maintaining enterprise-grade security standards.

Leading open source solutions like Infisical and HashiCorp Vault (under BSL license) offer comprehensive feature sets including encryption at rest and in transit, role-based access controls, and extensive integration capabilities. Organizations benefit from the ability to audit source code, customize implementations to specific requirements, and avoid licensing costs associated with proprietary alternatives.

However, open source implementations require careful consideration of operational overhead. Teams must account for deployment complexity, ongoing maintenance responsibilities, and the need for internal expertise to manage updates and security patches. The trade-off between cost savings and operational burden varies significantly based on organizational size and technical capabilities.

When evaluating open source options, prioritize solutions with active community support, comprehensive documentation, and proven security track records. Consider factors like deployment flexibility, integration ecosystem maturity, and long-term sustainability of the project's development roadmap.

The Secrets Manager List

Cyberark Conjur Secrets Manager Enterprise

Conjur was founded in 2011 and was acquired by Cyberark in 2017. It's grown to be one of the premiere secrets management solutions thanks to its robust feature set and large number of SDKs and integrations.

With Role Based Access Controls (RBAC) and multiple authentication mechanisms, it makes it easy to get up and running using existing integrations for top developer tools like Ansible, AWS CloudFormation, Jenkins, GitHub Actions, Azure DevOps, and more.

You can scope secrets access to the developers and systems that need the secrets. For example, a Developer role that accesses Conjur for a database secret might get a connection string for a test database when they're testing their app locally, while the application running in production gets the production database credentials.

The Cyberark site boasts an extensive documentation set and robust REST API documentation to help you get up to speed, while their SDKs and integrations smooth out a lot of the speed bumps.

In addition, GitGuardian and CyberArk have partnered to create a bridge to integrate CyberArk Conjur and GitGuardian's Has My Secrets Leaked. This is now available as an open-source project on GitHub, providing a unique solution for security teams to detect leaks and manage secrets seamlessly. 

Learn more about this CyberArk & GitGuardian integration.

Google Cloud Secret Manager

When it comes to choosing Amazon Web Services (AWS), Google Cloud Platform (GCP), or Microsoft Azure (Azure), it's usually going to come down to where you're already investing your time and money.

In a multi-cloud architecture, you might have resources spread across the three, but if you're automatically rotating secrets and trying to create consistency for your services, you'll likely settle on one secrets manager as a single source of truth for third party secrets, rather than spreading secrets across multiple services.

While Google is behind Amazon and Microsoft in market share, it sports the features you expect from a service competing for that market, including:

• Encryption at rest and in transit for your secrets
• CLI and SDK access to secrets
• Logging and audit trails
• Permissioning via IAM
• CI/CD integrations with Github Actions, Hashicorp Terraform, and more.
• Client libraries for eight popular programming languages.

Again, whether to choose it is more about where you're investing your time and money rather than a killer function in most cases.

If this interests you, we've got some tips on using Google Cloud Secret Manager.

AWS Secrets Manager

Everyone with an AWS certification, whether developer or architect, has heard of or used AWS Secrets Manager. It's easy to get it mixed up with AWS Key Management System (KMS), but the Secrets Manager is simpler. KMS creates, stores, and manages cryptographic keys. Secrets Manager lets you put stuff in a vault and retrieve it when needed.

A nice feature of AWS Secrets Manager is that it can connect with a CI/CD tool like GitHub actions through OpenID Connect (OIDC) and you can create different IAM roles with tightly scoped permissions, assigning them not only to individual repositories, but specific branches.

AWS Secrets Manager can store and retrieve non AWS secrets as well as use the roles to provide access to AWS services to a CI/CD tool like GitHub Actions. Using AWS Lambda, key rotation can be automated, which is probably the most efficient way as the key is updated in the secrets manager milliseconds after it's changed, producing the minimum amount of disruption.

As with any AWS solution, it's a good idea to create multi-region or multi-availability-zone replicas of your secrets, so if your secrets are destroyed by a fire or taken offline by an absent-minded backhoe operator, you can fail-over to a secondary source automatically. At $0.40 per secret per month, it's not a huge cost for added resiliency.

If this interests you, we've got some tips on using AWS Secrets Manager.

Azure Key Vault

Azure is the #2 player in the cloud space after AWS. Their promotional literature touts their compatibility with FIPS 140-2 standards and Hardware Security Modules (HSMs), showing they have a focus on customers who are either government agencies or have business with government agencies. This is not to say that their competitors are not suitable for government or government-adjacent solutions, but that Microsoft pushes that out of the gate as a key feature.

Identity-managed access, auditability, differentiated vaults, and encryption at rest and in transit are all features they share with competitors.

As with most Microsoft products, it tries to be very Microsoft and will more than likely appeal more to .Net developers who use Microsoft tools and services already. While it does offer a REST API, the selection of officially blessed client libraries (Java, .Net, Spring, Python, and JavaScript) is thinner than you'll find with AWS or GCP.

As noted in the AWS and GCP entries, a big factor in your decision will be which cloud provider is getting your dominant investment of time and money. And if you're using Azure because you're a Microsoft shop with a strong investment in .Net, then the choice will be obvious.

If this interests you, we've got some tips on using Azure Key Vault.

Doppler

While CyberArk's Conjur (discussed above) started as a solo product that was acquired and integrated into a larger suite, Doppler currently remains a standalone key vault solution. That might be attractive for some because it's cloud-provider agnostic, coding language agnostic, and has to compete on its merits instead of being the default secrets manager for a larger package of services. 

It offers logging, auditing, encryption at rest and in transit, and a list of integrations as long as your arm. Besides selling its abilities, it sells its SOC compliance and remediation functionalities on the front page. When you dig deeper, there's a list of integrations as long as your arm testifying to its usefulness for integrating with a wide variety of services within modern security frameworks, and its list of SDKs is more robust than Azure's.

It seems to rely strongly on injecting environment variables, which can make a lot of your coding easier at the cost of the environment variables potentially ending up in run logs or crash dumps. Understanding how the systems with which you're using it treat environment variables, scope them, and the best ways to implement it with them will be part of the learning curve in adopting it.

Infisical

Like Doppler, Infisical uses environment variable injection. Similar to the Dotenv package for Node, when used in Node, it injects them at run time into the process object of the running app so they're not readable by any other processes or users. They can still be revealed by a crash dump or logging, so that is a caveat to consider in your code and build scripts.

Infisical offers other features besides a secrets vault, such as configuration sharing for developer teams and secrets scanning for your codebase, git history, and as a pre-commit hook. You might ask why someone writing for GitGuardian would mention a product with a competing feature. Book a demo with GitGuardian and we'll show you why we believe we're better.

Aside from the scanning, their secrets and configuration vault/sharing model offers virtual secrets, over 20 cloud integrations, nine CI/CD integrations, over a dozen framework integrations, and SDKs for four programming languages. Their software is mostly open source and there is a free tier, but features like audit logs, RBAC, and secrets rotation are only available to paid subscribers.

Akeyless

AKeyless goes all out features, providing a wide variety of authentication and authorization methods for how the keys and secrets it manages can be accessed. It supports standards like RBAC and OIDC as well as 3rd party services like AWS IAM and Microsoft Active Directory.

It keeps up with the the competition in providing encryption at rest and in transit, real-time access to secrets, short-lived secrets and keys, automated rotation, and auditing. It also provides features like just-in-time zero trust access, a password manager for browser-based access control as well as password sharing with short-lived, auto-expiring passwords for third parties that can be tracked and audited.

In addition to 14 different authentication options, it offers seven different SDKs and dozens of integrations for platforms ranging from Azure to MongoDB to Remote Desktop Protocol.

They offer a reasonable free tier that includes 3-days of log retention (as opposed to other platforms where it's a paid feature only). 

1Password

You might be asking "isn't that just a password manager for my browser?" If you think that's all they offer, think again. They offer consumer, developer, and enterprise solutions, and what we're going to look at is in their developer-focused offering.

Aside from zero-trust models, access control models, integrations, and even secret scanning, one of their claims that stands out on the developer page is "go ahead – commit your .env files with confidence." This stands out because .env files committed to source control are a serious source of secret sprawl. So how are they making that safe?

You're not putting secrets into your .env files. Instead, you're putting references to your secrets that allow them to be loaded from 1Password using their services and access controls. This is somewhat ingenious as it combines a format a lot of developers know well with 1Password's access controls. It's not plug-and-play and requires a bit of a learning curve, but familiarity doesn't always breed contempt. Sometimes it breeds confidence.

While it has a limited number of integrations, it covers some of the biggest Kubernetes and CI/CD options. On top of that, it has dozens and dozens of "shell plugins" that help you secure local CLI access without having to store plaintext credentials in ~/.aws or another "hidden" directory.

And yes, we mentioned they offer secrets scanning as part of their offering. Again, you might ask why someone writing for GitGuardian would mention a product with a competing feature. Book a demo with GitGuardian and we'll show you why we believe we're better.

HashiCorp Vault

HashiCorp Vault offers secrets management, key management, and more. It's a big solution with a lot of features and a lot of options. Besides encryption, role/identity based secrets access, dynamic secrets, and secrets rotation, it offers data encryption and tokenization to protect data outside the vault.

It can act as an OIDC provider for back-end connections as well as sporting a whopping seventy-five integrations in its catalog for the biggest cloud and identity providers. It's also one of the few to offer its own training and certification path if you want to add being Hashi Corp Vault certified to your resume.

It has a free tier for up to 25 secrets and limited features. Once you get past that, it can get pricey, with monthly fees of $1,100 or more to rent a cloud server at an hourly rate.

Kubernetes Secret Management Tools: Container-Native Security

Modern containerized environments demand specialized approaches to secrets management that align with kubernetes secret management tools and cloud-native architectures. Traditional secrets management solutions often struggle with the dynamic, ephemeral nature of container workloads and the complex networking requirements of orchestrated environments.

Kubernetes-native solutions like External Secrets Operator, Sealed Secrets, and integrated cloud provider offerings (AWS Secrets Store CSI Driver, Azure Key Vault Provider) address these challenges through container-aware designs. These tools understand pod lifecycles, namespace isolation, and service mesh communication patterns, enabling seamless integration with existing Kubernetes workflows.

Key considerations for container environments include secret injection methods (environment variables vs. mounted volumes), rotation strategies that don't disrupt running workloads, and integration with service discovery mechanisms. Solutions must handle the scale and velocity of modern container deployments while maintaining security boundaries between namespaces and workloads.

Effective kubernetes secret management requires understanding the interplay between cluster-level security policies, network policies, and secrets access patterns. Organizations should evaluate tools based on their ability to integrate with existing CI/CD pipelines, support for GitOps workflows, and compatibility with security scanning and compliance requirements.

Enterprise Secrets Management: Scaling Security Across Organizations

Enterprise-scale secrets management tools must address complex organizational requirements that extend beyond basic credential storage and retrieval. Large organizations face unique challenges including multi-cloud deployments, regulatory compliance requirements, complex approval workflows, and the need to support thousands of developers across diverse technology stacks.

Enterprise solutions require sophisticated governance capabilities including hierarchical access controls, delegation models, and integration with existing identity providers like Active Directory or LDAP. Audit trails must support compliance frameworks such as SOX, HIPAA, or PCI-DSS, providing detailed logging of all secret access and modification activities.

Scalability considerations encompass both technical and operational dimensions. Solutions must handle high-throughput secret retrieval operations while maintaining low latency, support geographic distribution for global teams, and provide disaster recovery capabilities. Operational scalability includes self-service capabilities for development teams, automated onboarding processes, and integration with existing ticketing and approval systems.

Cost optimization becomes critical at enterprise scale, requiring careful evaluation of pricing models, feature tiers, and total cost of ownership including operational overhead. Organizations should assess vendor support quality, professional services availability, and the solution's roadmap alignment with long-term strategic objectives.

In summary

Whether it's one of the solutions we recommended or another solution that meets our recommendations of what to look for above, we strongly, strongly, strongly recommend integrating a secret management tool into your development processes. If you still need more convincing, we'll leave you with this video, featuring our own Mackenzie Jackson.