A database password, a payment API key, a webhook secret: in almost every online shop, dozens of such credentials sit in configuration files, environment variables and deployment scripts -- and many of them have been valid, unchanged, for years. That is a software state that quietly goes stale. Around 29 million (GitGuardian State of Secrets Sprawl 2026) new hardcoded secrets surfaced in public repositories in 2025 alone, a rise of 34 percent (GitGuardian State of Secrets Sprawl 2026) year on year. Even more telling: 64 percent (GitGuardian State of Secrets Sprawl 2026) of the credentials already leaked back in 2022 were still not revoked at the start of 2026. Anyone who enters a key once and then forgets it accumulates a growing risk. This guide shows how to rotate, monitor and cleanly keep secrets out of the code -- as a fixed building block of ongoing shop maintenance.
Key takeaways
- Secrets age like software: around 29 million (GitGuardian State of Secrets Sprawl 2026) new hardcoded credentials were added in 2025, 34 percent (GitGuardian State of Secrets Sprawl 2026) more than the year before.
- Deleting is not rotating: a leaked key stays valid until it is actively revoked and replaced. 64 percent (GitGuardian State of Secrets Sprawl 2026) of the secrets leaked in 2022 still worked at the start of 2026.
- Stolen credentials are a frequent entry point: they were the initial attack vector in 22 percent (Verizon DBIR 2025) of the incidents studied, and in 88 percent (Verizon DBIR 2025) of attacks on web applications.
- A rotation plan assigns every secret an interval and a trigger -- database password, payment API, SMTP access, webhook signature, storage keys and OAuth tokens all belong in it.
- Rotation belongs in the same maintenance rhythm as updates, backups and monitoring -- with staging, a dual-key handover and documentation, so no rotation step ever causes an outage.
Why API Keys Become a Creeping Risk
A secret is like a key to a room: as long as it is valid, anyone who holds it can get in. Unlike a physical key, however, an API key can be copied any number of times -- it ends up in the config file, the deployment script, the CI/CD pipeline, a backup and often enough in the Git history, where it remains readable even after being deleted from the current version. The industry calls this spread secrets sprawl, and it is growing fast. It has become especially visible with the rise of AI-assisted development tools: 1,275,105 (GitGuardian State of Secrets Sprawl 2026) leaked credentials tied to AI services were detected in 2025, an increase of 81 percent (GitGuardian State of Secrets Sprawl 2026) over the previous year. Each of these keys stays an open door until someone actively closes it.
The economic stakes are real. Security incidents that begin with compromised credentials cost an average of 4.67 million US dollars (IBM Cost of a Data Breach 2025) per case according to IBM -- and they stay hidden for a long time: on average, 246 days (IBM Cost of a Data Breach 2025) pass before such an incident is identified and contained. A valid key in the wrong hands looks like legitimate access to the system, which is why classic protective mechanisms often do not trigger. That is exactly why we treat credentials as a maintenance object with a fixed renewal date -- interlocked with hardening the server and application, which ensures that a single leaked key does not immediately open the whole system.
What this article means by secret
Which Secrets Live in a Shop
Before secrets can be rotated, they have to be known. The first step of any clean rotation is therefore an inventory: a list of which credentials the shop actually uses, where they are stored and what they authorise. In a typical online shop, six groups can be distinguished. Each has its own triggers for a renewal and its own technical integration -- the payment API, for instance, is closely tied to the maintenance of payment interfaces and their webhooks.
Database access
Username and password for the shop database. A highly sensitive secret, because it opens direct access to order, customer and payment data.
Payment API keys
Live and test keys of the payment provider. Kept separate and narrowly scoped, so a leak does not lead to unauthorised transactions.
Mail and SMTP access
Credentials for sending order and system emails. Abused, they threaten spam sent through your domain and damage to deliverability.
Webhook signing secrets
Secrets used to sign and verify incoming webhooks from payment and shipping services. Without a valid signature, events could be forged.
Storage and cloud keys
Access keys for object storage, CDN or backup targets. Tightly scoped rights prevent a single key from exposing the entire store.
OAuth and app tokens
Tokens for connected services such as ERP, newsletter or marketplaces. They often go stale unnoticed and are rarely reviewed.
Why Rotation Is the Decisive Building Block
Rotation means regularly replacing a secret with a new one and invalidating the old one. The benefit lies in the time window: a key that is renewed after 90 days is usable to an attacker for at most 90 days -- after that it opens nothing. Without rotation, by contrast, a secret that has leaked once stays usable practically indefinitely. The numbers make this drastically clear: more than 90 percent (GitGuardian State of Secrets Sprawl 2026) of leaked secrets are still valid five days after the leak, and 64 percent (GitGuardian State of Secrets Sprawl 2026) of the credentials exposed in 2022 still worked at the start of 2026. Deleting alone is not enough.
On top of that, the response in practice is slow. The average time until a leaked secret is actually remediated is 27 days (GitGuardian State of Secrets Sprawl 2026) -- almost four weeks in which the door stays open. Whoever plans rotation as a fixed cadence does not have to invent a process in an emergency but pulls forward a routine that is already practised. It is the same idea as with planned security updates: what runs as a routine happens faster and with fewer errors when it really matters.
Deleting is not rotating
Rotation Plan: Setting Intervals and Triggers
Not every secret needs the same cadence. A rotation plan assigns each group a regular interval and additionally defines event-driven triggers that prompt immediate rotation -- for example the departure of a service provider, a suspected leak or a change of payment provider. This creates a plannable rhythm instead of frantic one-off actions. The overview below shows sensible starting values that are adjusted to risk and operational reality in each case.
| Secret type | Typical interval | Rotate immediately when |
|---|---|---|
| Database access | every 3 to 6 months | there is a suspicion of compromise |
| Payment API keys | every 6 to 12 months | the payment provider or contract changes |
| SMTP and mail access | every 6 months | unusual mail sending is noticed |
| Webhook signing secret | every 3 to 6 months | an interface is newly connected |
| Storage and cloud keys | every 3 months | a service provider ends the collaboration |
| OAuth and app tokens | as required by the service | a connected account changes owner |
- A complete inventory of all secrets with storage location and scope of rights
- A regular interval per secret type, documented and with a reminder
- Event-driven triggers for an immediate rotation defined
- A responsible person named per secret, with a stand-in
- Every rotation logged with date, reason and the person performing it
- Old keys demonstrably revoked after the transition phase
Leak Monitoring: Spotting Leaked Keys Early
Rotation on a plan lowers the baseline risk but does not replace observation. A secret can leak unplanned at any time -- through a repository made public, a misconfigured config file or a compromised developer device. New attack surfaces keep appearing: in configuration files for AI-assisted tools alone, GitGuardian found 24,008 (GitGuardian State of Secrets Sprawl 2026) individual secrets in public repositories, of which 2,117 (GitGuardian State of Secrets Sprawl 2026) were verified as valid. Leak monitoring automatically searches repositories, history data and public sources for patterns of real credentials and flags a hit before an attacker finds it. The same vigilance applies to backend access, as described in securing admin access with multi-factor authentication.
- Automated scanning of repositories and their history for secret patterns
- Checking configuration and environment files before every deployment
- Comparison with public leak sources and provider warning notices
- A clear escalation chain: who is informed how quickly on a hit?
- Immediate rotation and revocation as the defined response to every finding
- A follow-up check that the old secret has truly been removed everywhere
Rotation Without Downtime: The Technical Procedure
The biggest concern with rotation is operations: a wrongly swapped key can bring down the checkout, mail sending or an interface. That is why a clean rotation runs through a handover with two keys valid in parallel, not through a hard cut. The new key is issued and deployed while the old one stays active; only once the new one demonstrably works is the old one revoked. Every rotation is first rehearsed in a staging environment before it touches the live system. This creates a repeatable procedure that manages without lost revenue.
- Generate the new secret at the issuing service, with tightly scoped permissions.
- Store the new secret in the staging environment first and test the connection.
- Deploy it to the live system while the old secret remains valid during transition.
- Check the function of all affected flows: checkout, mail sending, webhooks, storage.
- Revoke the old secret at the service and remove it from all stores and the history.
- Document the rotation with date, reason and source in the maintenance report.
# The config file does not belong in the repository
# echo ".env" >> .gitignore
# Values are injected at runtime from a secret store
# or the deployment pipeline -- never stored in plain text
DB_PASSWORD=${SECRET_DB_PASSWORD}
PAYMENT_API_KEY_LIVE=${SECRET_PAYMENT_LIVE}
PAYMENT_API_KEY_TEST=${SECRET_PAYMENT_TEST}
WEBHOOK_SIGNING_SECRET=${SECRET_WEBHOOK}
MAIL_SMTP_PASSWORD=${SECRET_SMTP}
# Dual-key handover: new value active, old one still valid
# until the connection is verified -- then revoke the old key
PAYMENT_API_KEY_LIVE_NEXT=${SECRET_PAYMENT_LIVE_NEXT}The dual-key handover
Keeping Secrets Out of the Code and Git History
Even the best rotation helps little if keys keep ending up in the code anew. That is why ongoing upkeep includes keeping secrets out of the source code on principle: in environment variables, a secret store or the deployment pipeline that injects the values only at runtime. A check before every commit catches accidentally inserted keys before they reach the history. This is no fringe issue: compromised end devices are a real spread path -- in infostealer logs, company credentials were found on 46 percent (Verizon DBIR 2025) of unmanaged and 30 percent (Verizon DBIR 2025) of managed devices. And 54 percent (Verizon DBIR 2025) of ransomware victims already had exposed credentials in such logs before the attack. Whoever does not spread keys widely in the first place removes the basis for this pattern.
Rotation as a Building Block of Ongoing Maintenance
Secret rotation is not a one-off project but a recurring procedure -- and so it belongs in the same maintenance contract as updates, backups and monitoring. The pressure is measurable: ransomware was involved in 44 percent (Verizon DBIR 2025) of all incidents studied in 2024, and phishing triggered 16 percent (IBM Cost of a Data Breach 2025) of incidents as the most common entry point -- both paths often end at a valid key that stayed valid too long. An SLA maintenance contract defines the cadence of rotation and how fast a leak finding must be acted on. The right scope is covered by our maintenance packages -- rotation and leak monitoring as building blocks alongside protection against card-testing attacks in the checkout and protection from overload at peak.
A key that nobody renews any more is not an access point but an open window. Rotation means closing every window on a fixed cadence before someone finds it from outside.
It starts with an inventory: which secrets does the shop use, where are they stored, when were they last renewed, and where might they still sit in the code or the history? From this analysis comes the rotation plan that moves the keys into a safe cadence step by step and interlocks it with applying security updates. This inventory can be requested without obligation -- as the first step towards credentials that are renewed on a plan rather than left untouched for years.