Secrets Management for Developers: Safeguarding Passwords, SSH Keys, and Database Credentials

This is the final post in a series about shadow IT. In this series, we’ve detailed how and why teams use unapproved apps and devices, and cybersecurity approaches for securely managing it. For a complete overview of the topics discussed in this series, download Managing the unmanageable: How shadow IT exists across every team – and how to wrangle it.

We all use passwords and other secrets to access things at work. It’s the IT team’s responsibility to secure those secrets. For most departments, secrets management needs are simple: They sign in to apps and websites with passwords, or passkeys, or sometimes with multi-factor authentication.

But developers have unique workflows and secrets management needs.

The types of secrets developers manage every day include SSH keys, database and API keys, server credentials, and other encryption keys. These keys power authentication methods developers use every day to access systems, integrate applications, securely transfer files, and more. To complicate matters, developer secrets often live outside IT’s purview.

That means developers are often left to manage secrets themselves, but that scenario can create serious risks for companies. A 2023 GitGuardian study revealed that in just one popular open-source repository used by developers, nearly 4,000 unique secrets were exposed across all projects. Of those unique secrets, they found 768 were still in active use. Separately, in the first two months of 2024, GitHub reported it found more than one million leaked secrets on public repositories, which translates to a rate of about 12 secrets leaked per minute during that time. That’s a lot of leaks!

Secrets management, in other words, is a growing problem. To make matters worse, the typical shadow IT concerns that plague non-developer teams apply to developers, too. That is, the passwords and credentials they use to sign in to apps and websites may not be secure – and IT may not even know about it.

The challenge, should IT and security teams choose to accept it: Secure encryption keys and other developer secrets no matter which apps and tools are being used – and do it without adding friction to already complex workflows.

Breaking down developers’ unique secrets management needs

Due to the nature of their roles, developers building software products have direct access to key systems and sensitive data. In addition, they need to work with secrets directly in their terminal, code editor, and deployment pipelines. Engineering teams may also need to share secrets for different applications, or when configuring their development environments.

To streamline this process, developers sometimes store secrets somewhere convenient in plaintext, or hardcode them into the source code while working. Either of these scenarios – not exactly secrets management best practices – can lead to data breaches or compromised systems.

A brief introduction to secret sprawl

The growing number of different tools and cloud environments developers use to do their work has made secrets management more difficult. A 1Password report revealed that 50% of individual contributors in IT or DevOps roles admit they’re storing secrets in more locations than they can count. 25% of companies said their secrets are stored in 10 or more locations.

And while the IT team has traditionally been responsible for managing passwords, IT teams often lack visibility and control over developer secrets like SSH keys and API tokens. This seems to be the norm: approximately 80% of companies surveyed by 1Password said they didn’t manage their secrets well, and 60% have experienced secret leaks. In fact, 75% of developers admitted they had access to sensitive information like a former employers’ infrastructure secrets(!).

Lack of developer-specific toolsets compounds the problem

Why is it so hard for developers to secure secrets like SSH keys and database credentials? Security and productivity are often in tension. One survey found that 73% of developers agree that the work or tools their security team typically requires them to use interfere with their productivity and innovation.

Each cloud provider, application, server, database, or other tool a developer uses typically requires separate authentication – and might require learning specialized tooling for that environment. Authenticating for multiple tools can interrupt workflows, slowing developers down – which can be unacceptable for teams trying to deliver projects on tight deadlines.

As a workaround, sometimes developers store credentials insecurely or take shortcuts to enable faster access. Lacking a secure, productivity-friendly alternative, this is how you end up with hard-coded credentials.

In addition to taking shortcuts, lack of education around proper secrets management has allowed insecure habits to form, including:

Reusing secrets across projects.
Using the same secrets in both production and testing/staging.
Storing secrets in shared or unsecured spreadsheets.
Sending secrets over email, chat, and text.
Former employees maintaining access to secrets.

When developers share secrets using unencrypted email messaging apps, manually set up system configurations on their local device to run a program, or manually copy sensitive values to connect to another machine, those secrets are not secure.

Securing shadow IT with secrets management solutions for developers

As we detailed in the last post in this series, a first step to wrangling shadow IT across all of your company’s departments is understanding employees’ responsibilities and workflows. This helps IT and security teams identify not only where employees may be using shadow IT to help them in their jobs, but why they’re using it.

Employees often use shadow IT to improve their productivity – to work around something that’s holding them back from doing their best work, on schedule. This is especially important to understand for the engineering team.

The question is how to secure developer workflows while simultaneously streamlining them. Secure credential management for developers can be trickier than it is among non-developers, because the workflows are more technical, so the fix requires a more bespoke solution. Implementing single sign-on (SSO) as part of an identity and access management (IAM) framework can go a long way to securing non-development workflows, but they don’t typically address developer needs.

The good news is there is arguably more opportunity within developer workflows to secure credentials and reduce friction than with other teams. It’s not particularly convenient for developers to generate SSH keys manually every time, or to store SSH keys on their local drive, or to store plaintext secrets in code. These (insecure) methods are just the way things have always been done – but they’re certainly not without friction.

However, it can be difficult for IT and security admins to know where to start, because they’re less familiar with developer workflows. That being the case, a good first step is to try to understand developers’ unique secrets management use cases. For example, it may be helpful to understand that each developer starts their day with a ‘git pull’, or why they have to google the ssh-keygen command every time they need it (because it’s so complicated).

To find points of friction, pinpoint where developers may be taking shortcuts with secrets management, and where shadow IT may be lurking, it can help to ask questions like:

How are you storing and sharing secrets?
Are you running programs/queries on your local device (instead of a secure server?)
Are you copying and pasting sensitive values to connect to another machine?
Are you using additional tools or services to increase your productivity or do your job better?
Are there security policies or processes you feel are slowing down your work?

Once you gather this information, then what? It’s not realistic to try and monitor all the ways developers may be sharing secrets or prevent employees from using shadow IT (you’ll be engaging in an unwinnable game of whac-a-mole). The only practical way forward is to put effective secrets management tools in place so developers can use the platforms they want, but in a secure way.

How do you do that? For starters, look for tools that use automation to eliminate the possibility of human error. That should make it easier to get buy-in too: Developers will never object to removing friction from their workflows, especially when you can automate tedious tasks in the software development lifecycle and lessen their workload.

For developers using SSH keys, for example, you can implement an enterprise password manager (EPM) like 1Password that supports secure secrets management for credentials like SSH keys in a way that fits seamlessly into developer workflows. In addition, an EPM with secrets management features can help developers securely work with API tokens, application keys, and other credentials where they need them – in their terminal and code editor. That means both stronger security and increased productivity.

Learn more about shadow IT

To learn more about shadow IT and how IT teams can adapt to evolving workplace challenges in a hybrid environment, catch up with three previous posts in this series:

For a complete overview of the topics discussed in this series, download the eBook, Managing the unmanageable: How shadow IT exists across every team – and how to wrangle it.