Developer secrets management that keeps delivery moving

In March 2025, attackers compromised a GitHub Action used in the development pipelines of more than 23,000 repositories. The malicious code exposed API keys, cloud credentials, SSH keys, and other tokens in workflow logs. Affected teams were advised to review their workflow runs and rotate any credentials the logs exposed.

Affected organizations had to determine which credentials had been exposed, what those credentials could reach, and how to replace every one of them without halting development. Many could not confidently answer the first question alone.

The incident illustrates the problem those responsible for a team's credentials face today: the credentials that carry the most risk are often the ones nobody is tracking.

Security tools cannot govern credentials they never see

Unmanaged credentials are simply a byproduct of the modern software development environment, where developers are under pressure to constantly ship code. A developer standing up an application needs a database password or an API key immediately, and the fastest way to supply one is a .env file on the local machine, an SSH key in a home directory, or a token pasted into a pipeline variable. Each choice keeps work moving, and each one creates a working credential that exists outside any approved system, where no one responsible for keeping projects, credentials, and access safe can rotate, revoke, or audit it.

Traditional secrets management can leave this gap open because it starts on the wrong side of it. Conventional tools provide a secure destination but depend on developers to bring credentials to it, so governance begins only after migration. When a security process adds friction, teams find workarounds. 1Password’s research found that 43% of developers don’t use a dedicated secrets manager or vault at all, managing secrets through a mix of secure and unsecure means instead. As a result, credentials remain outside the controls, reporting, and rotation processes intended to protect them.

These are longstanding problems, but what has changed is the pace at which those credentials are created. GitGuardian counted 28.65 million new secrets exposed in public GitHub commits in 2025, up 34% from the prior year, and 1Password's research found that 86% of technical employees report credential-related issues with non-human identities. The problem exists in small teams and large organizations. What changes is who owns the work and what the organization needs to prove. On a small team, one person may create the credential, use it, and manage its access. As the organization grows, more people, workflows, and environments depend on those credentials, so the work expands to include establishing an inventory, governing access, assigning remediation, and producing evidence. The goal remains the same: the administrator needs to secure the credentials the team already uses without breaking the workflows that keep development moving.

A complete program to discover, secure, govern, and audit credentials

In a poorly implemented secrets management program, four problems compound one another:

1. Credentials sit exposed where nobody can see them
2. Moving them risks breaking whatever depends on them
3. Any secure path that adds friction gets routed around
4. When an incident or audit occurs, administrators cannot show what exists or what was fixed

Breaking that cycle requires four capabilities operating continuously.

Discover: Establish an actionable inventory

Discovery starts with getting a complete picture of exposure. Administrators need a way to find credentials on local devices, including .env files, SSH key directories, and other local files, without relying on developers to self-report. The output must be twofold: a prioritized view of exposed credentials that administrators can track over time, and findings specific enough (this key, in this project, on this machine) that a developer can be asked to act on each one immediately.

Secure: Move credentials into managed control

Securing a discovered credential means moving it directly into managed control without breaking what depends on it. Telling a developer to delete a file is not a remediation path; the credential is still needed for the application to run. The path from finding to fix should be short: a developer imports an exposed credential into a managed environment and uses it through environment variables supplied at runtime, with no plaintext copy persisting on disk. The developer keeps the familiar way of working, while the person responsible changes how the credential is governed, shared, and remediated.

Govern: Give credential access without exposure

Governance determines who or what can access a credential, which project or environment it belongs to, and what happens when that access changes. Developers should receive only the credentials they need for their work. CI/CD systems should use scoped service accounts, while AI agents should be treated as nonhuman identities with narrowly defined, reviewable permissions. Access should have an owner, be limited by role or environment, and be revocable when a person, workflow, or project changes. The governing path must still be usable, or teams will route around it.

Audit: Give administrators evidence to act

Administrators need evidence of what was found, what changed, and what still requires action. Reporting should help teams review findings by user and device, track remediation, and identify credentials that still require rotation. That record lets administrators demonstrate what was exposed, what was remediated, what still requires attention, and how risk is changing across teams and environments during access reviews, incident response, and security reporting.

Secure secrets management simplifies the developer workflow

A well-run secrets management program makes life simpler for everyone involved. Developers do not need to trade speed for security. They have a supported path to retrieve credentials inside familiar workflows, while administrators can identify exposure, assign remediation, and review progress.

Every credential access, human or agent, is documented and traceable. When a credential is compromised, the blast radius is known and the response is contained: what the credential touched is on record, and rotation happens from one place. When a security leader or an auditor asks for evidence of control, the organization can show its findings, actions, and progress rather than reconstructing an outdated or incomplete inventory during an incident or audit.

The full lifecycle: secure developer secrets with 1Password

1Password’s developer security capabilities help organizations discover credentials developers already use, including supported credentials stored in plaintext on local devices, and connect discovery to remediation, delivery, and oversight. Developer Watchtower finds exposed credentials like SSH keys and .env files on endpoints. 1Password Environments gives developers a managed place for the secrets behind their apps, automations, and AI workflows, without disrupting how they work. Reporting and remediation workflows give administrators a clearer view of credential risk and a practical way to act on it. Discover, Secure, Govern, and Audit work together, so organizations can improve control without asking developers to abandon the workflows they depend on.

Learn more about securing developer secrets with 1Password.

null

Read the blog