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: Credentials sit exposed where nobody can see them Moving them risks breaking whatever depends on them Any secure path that adds friction gets routed around 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 defi

Extras afișat conform termenilor RSS ai publicației · 100 cuvinte · textul integral și figurile sunt pe site-ul publicației