Secrets don't leak because engineers are careless — they leak because secrets management is a workflow problem disguised as a storage problem. GitGuardian's 2024 report found 12.8 million secrets exposed on public GitHub in a single year, a 28% increase over the year before, and internal repositories fare no better since most scanning programs only cover public-facing code. A hardcoded AWS key in a .env file committed at 2 a.m., a Slack webhook pasted into a Jira ticket, a database password reused across staging and production — these are routine, not exotic. Toyota, Uber, and Slack have all disclosed secrets-related exposures in the last five years, each traced back to a credential sitting somewhere it shouldn't have been, unrotated, for months. This post covers what secrets management actually means in practice, which tools handle which part of the problem, and the concrete steps that separate teams who catch a leaked key in minutes from teams who find out from a threat actor.
What Is Secrets Management, Exactly?
Secrets management is the practice of generating, storing, distributing, rotating, and revoking credentials — API keys, database passwords, TLS certificates, SSH keys, OAuth tokens — without ever putting the plaintext value in source code, config files, or chat logs. A "secret" is anything that grants access on its own, no second factor required. The discipline breaks into four operational pieces: a centralized vault (HashiCorp Vault, AWS Secrets Manager, Doppler) that stores the value; an access-control layer that decides which service or person can retrieve it; a rotation policy that expires and replaces it on a schedule; and a detection layer that scans code, logs, and container images for secrets that escaped the vault entirely. Most breaches trace back to that fourth piece failing — the secret was managed correctly right up until someone pasted it into a commit, and nothing caught it for 90+ days, which IBM's Cost of a Data Breach report has consistently cited as the average dwell time for credential-based breaches.
Which Secrets Management Tools Should Security Teams Actually Use?
The right toolset combines a vault for runtime secrets with a scanner for leaked ones, because no vault prevents a developer from pasting a value into code. HashiCorp Vault remains the default for teams needing dynamic secrets (short-lived database credentials generated per-request) and fine-grained policy control via HCL, but it requires dedicated operational overhead — Vault clusters need their own HA setup, unseal key management, and audit log pipeline. AWS Secrets Manager and Azure Key Vault trade flexibility for near-zero setup if you're already committed to one cloud, charging around $0.40 per secret per month plus API call costs at scale. Doppler and Infisical have gained traction with smaller teams for their developer experience — a single CLI command syncs secrets to local .env files without anyone touching the actual values. On the detection side, GitGuardian, Gitleaks (open source, regex- and entropy-based), and TruffleHog scan git history, commits, and even container layers for exposed credentials; GitHub's own secret scanning now covers over 200 token formats and pushes to protect against publishing credentials to public repos by default since 2022. No single tool covers both storage and detection well — plan for at least one of each.
How Often Should Secrets Be Rotated?
Rotation frequency should match the blast radius of the credential, not a fixed calendar — high-privilege cloud keys need 90-day-or-less rotation, while narrowly-scoped API tokens can run longer if access is monitored. NIST SP 800-63B dropped the old blanket "rotate every 90 days" password guidance in 2017 for human accounts, but that guidance was about passwords with MFA behind them, not machine credentials with standing access to production data — those are a different risk class. AWS's own guidance recommends rotating IAM access keys at minimum every 90 days, and Secrets Manager supports automatic rotation via Lambda for RDS, Redshift, and DocumentDB natively. The harder problem is the credentials rotation policies miss entirely: a Datadog State of Cloud Security report found that over 50% of organizations had at least one long-lived cloud credential with no rotation history at all, often service accounts set up years earlier and forgotten. Automated rotation only works if there's an inventory forcing every credential through the policy — manual rotation programs fail because nobody remembers the key that a contractor generated for a one-off migration script in 2022.
What's the Real Cost of a Leaked Secret?
The real cost is measured in dwell time and blast radius, not just the value of the single credential — a leaked AWS key with broad IAM permissions can be used for cryptomining, data exfiltration, or lateral movement within minutes of being scraped by automated bots that continuously crawl GitHub. Security researchers have repeatedly demonstrated that public commits get scanned by malicious actors within seconds to minutes of being pushed; Uber's 2022 breach began with an attacker buying an employee's corporate credentials, then finding a hardcoded admin password in a PowerShell script on an internal network share that granted access to privileged access management itself. Toyota disclosed in 2022 that an access key had been publicly exposed on GitHub for nearly five years, exposing customer data for roughly 296,000 people. The financial cost compounds: IBM's 2024 Cost of a Data Breach report put the average cost of a breach involving stolen or compromised credentials at $4.81 million, and breaches with a lifecycle over 200 days cost organizations $1.2 million more on average than those contained inside 200 days. The fix isn't just finding the leak — it's cutting the time between exposure and revocation to minutes, not months.
Do Secret Scanners Actually Stop Leaks, or Just Find Them After the Fact?
Scanners stop leaks only when they run pre-commit or pre-push, not just on a schedule against the already-public repository. A scanner that runs nightly against main tells you a secret was exposed yesterday; a pre-commit hook with Gitleaks or a pre-receive server-side hook blocks the commit before it ever reaches a shared branch, which is the only version of "detection" that prevents exposure rather than just shortening it. GitHub's push protection, enabled by default for public repositories since 2023 and extendable to private repos on GitHub Enterprise, blocks a push in real time if it matches a known token format from over 100 service providers. The gap most teams miss is coverage of non-git surfaces — Slack messages, Jira tickets, CI/CD logs, and container image layers — where a 2023 study by Aqua Security found exposed secrets in roughly 1 in 4 CI/CD pipeline logs it scanned across mid-size organizations. A scanning program that only covers git push is covering the smallest part of the actual leak surface.
How Safeguard Helps
Safeguard closes the gap between "we found a leaked secret" and "we know it matters" by running reachability analysis on top of detection — instead of flagging every credential-shaped string in every repo, it traces whether a discovered secret maps to a live, exploitable path in code that's actually deployed, so security teams triage the handful of real exposures instead of chasing thousands of false positives. Griffin, Safeguard's AI assistant, correlates a leaked secret against SBOM data generated or ingested from your existing build pipeline to show exactly which services, containers, and dependencies would be affected if that credential were used maliciously. When a real leak is confirmed, Safeguard can open an auto-fix PR that removes the hardcoded value, points the code at the appropriate vault reference, and flags the credential for rotation — cutting remediation from a multi-day ticket queue to a same-day merge. For teams already juggling Vault, Secrets Manager, and a patchwork of scanners, Safeguard sits on top as the layer that tells you which alerts are urgent and ships the fix.