Secrets Management: Stop Hardcoding Credentials

Someone notices an API key sitting in a configuration file. They remove the line, write a commit message saying "removed hardcoded key", push it, and consider the problem handled.

It is not handled. The key is still in the repository's history, still in every clone anyone has ever taken, and still valid. The commit that removed it is a signpost pointing at exactly which earlier commit to look in.

This guide covers what actually counts as a secret, why hardcoding is worse than it appears, where credentials should live instead, the bootstrapping problem every vault has, what to do in what order when something leaks, and the residency and contractor questions Saudi organisations need to settle.

What Is Secrets Management and What Counts as a Secret?

Secrets management is the practice of storing, distributing, rotating and auditing credentials through a central system, so that applications retrieve them at run time rather than carrying them inside code or configuration.

A secret is anything that grants access to a system. Organisations consistently underestimate how many they have:

• Database passwords and connection strings
• API keys and access tokens for payment providers, messaging services, mapping platforms and internal APIs
• Cloud access keys and service account credentials
• SSH private keys and TLS certificate private keys
• Encryption keys protecting stored data
• Webhook signing secrets and inter-service authentication tokens
• Third-party integration credentials for ERP, CRM and accounting platforms

The count matters, because secrets management fails on the ones nobody inventoried. A production database password held in a vault is protected. The same password in a developer's local configuration file, a runbook, a backup script and a message thread is not.

The goal is not simply to encrypt secrets. It is to make them retrievable, revocable and auditable, so that a single action revokes access everywhere rather than triggering a search across systems.

Why Is Hardcoding Worse Than It Looks?

Hardcoding a credential creates copies in places most teams never consider, and each copy has a different lifetime.

Git history is permanent. Removing a secret in a later commit does not remove it from the repository. The original commit still contains it, and anyone with the repository can retrieve it. Rewriting history removes it from the main branch, but every existing clone, fork, mirror and backup still holds the original. Rewriting history is worth doing. It is never sufficient on its own.

Public exposure is exploited fast. Automated scanners monitor public code hosting continuously, and cloud credentials pushed to a public repository are commonly abused within minutes. The window between an accidental push and a compromised cloud account is not measured in days.

Container images preserve deleted files. An image is built in layers, and every layer is retained. A secret copied in during one build step and deleted in a later one remains recoverable from the earlier layer, and build arguments are visible in the image history. Deleting a file in a Dockerfile does not remove it from the image.

CI/CD pipelines echo variables. Build logs routinely print environment variables during debugging, and those logs are frequently more widely readable than the source repository they were generated from.

Configuration files travel. Files containing credentials get copied into backups, synced to shared drives, attached to support tickets and forwarded in messages. Each copy is outside every control the original was under.

Hardcoded secrets are never rotated. This is the compounding problem. Rotating a hardcoded credential requires a code change, a review, a build and a deployment, so it does not happen. A credential nobody can rotate cheaply is a credential that stays valid for years, including after the people who knew it left the organisation.

Where Should Secrets Actually Live?

The table below sets out the maturity ladder, from the practice to eliminate to the position worth aiming for.

Criterion	Hardcoded in code	Environment variables and config files	Centralised secrets manager	Workload identity
Where the secret lives	Source repository	Server environment or deployment config	Encrypted central store	Nowhere, the workload proves who it is
Who can see it	Anyone with repository access, now or historically	Anyone with server or pipeline access	Only identities granted access	No standing credential exists
Audit trail	None	None	Full, every retrieval logged	Full, through the identity provider
Rotation	Requires a code change and redeploy	Requires a config change and restart	Automated, often without redeployment	Automatic, tokens are short-lived
Blast radius if leaked	Total and indefinite	Broad, valid until someone notices	Limited, revocable immediately	Minimal, tokens expire in minutes
Effort to adopt	None, it is the default failure	Low	Medium	Medium to high, cloud dependent
Best suited for	Nothing	A transitional step only	Any organisation with production systems	Cloud and containerised workloads

Two capabilities are worth understanding before selecting a platform.

Dynamic secrets are credentials generated on demand with a short lifetime, then revoked automatically. Rather than holding a permanent database password, an application requests one when it starts and the vault creates a real database user valid for a defined period. A dynamic credential that leaks expires by itself, which changes the consequences of a leak from an incident into an inconvenience.

Key management services handle encryption keys differently from other secrets. Rather than releasing the key to the application, the service performs the encryption or decryption itself, so the key never leaves the protected module. Encryption keys protecting stored personal data belong here rather than in a general-purpose secret store.

What Is the Secret Zero Problem?

The secret zero problem is the question of how an application authenticates to the secrets manager in the first place. Moving every credential into a vault does not eliminate credentials, because the application still needs something to prove its identity to the vault, and that something is itself a secret.

Pretending this does not exist is how organisations end up with a vault token hardcoded in the application that used to hold a hardcoded database password. The exposure has been reduced to one credential, which is genuine progress, but it has not disappeared.

Three approaches resolve it properly:

Platform identity. In a cloud environment, the workload authenticates using an identity the platform vouches for, such as an instance role or a container service account. The platform issues a short-lived token the application exchanges for its secrets, and no static credential exists on disk. This is the cleanest answer and the reason workload identity sits at the top of the ladder.

Hardware-backed attestation. The machine proves its identity using a hardware security module or trusted platform module, so the credential is bound to physical hardware rather than a file that can be copied.

Short-lived bootstrap tokens. A single-use or briefly valid token is injected at deployment time and exchanged immediately for a longer-lived session. It reduces the window rather than closing it, and it suits environments where platform identity is unavailable.

For on-premise systems without platform identity, hardware-backed attestation or a tightly scoped bootstrap process is the realistic answer. What matters is that the remaining credential is short-lived, narrowly scoped, auditable and rotatable, rather than a permanent token sitting in a configuration file.

How Do You Find and Fix Leaked Secrets?

Finding secrets and responding to a leak are two different disciplines, and the response has an order most teams get backwards.

Detection works at three points:

• Pre-commit hooks on developer machines catch a secret before it ever enters history. This is by far the cheapest place to stop it, because nothing needs cleaning afterwards.
• Push protection and repository scanning at the code hosting platform catch what reaches the server, and can block the push outright.
• Historical scanning of existing repositories finds what is already there. Run this once across every repository, including archived ones, because the credentials in old projects are frequently still valid in production.

Scanning produces false positives, particularly on test fixtures and example values. Tune the patterns rather than disabling the scan, exactly as with any other detection control.

When a secret leaks, work in this order:

• Rotate the credential immediately. Issue a new one and update the systems that use it. This is first because it is the only step that actually ends the exposure.
• Revoke the old credential explicitly. Creating a replacement does not invalidate the original. Confirm the old one is dead.
• Check the access logs. Look for use of that credential from unexpected addresses or at unexpected times, covering the full period from when it was first exposed. Treat confirmed misuse as a data breach response matter.
• Then clean the history. Rewrite the repository and force the update, and ask anyone holding a clone to re-clone.
• Fix the root cause. Move the credential into the vault and add the detection control that would have caught it.

Cleaning history before rotating is the common mistake. It consumes hours while a live credential remains valid, and it creates an accurate impression that the problem was handled when it was not.

Rotation itself should be automated wherever possible. The pattern that avoids downtime uses two valid credentials in alternation: the second is created and put into service while the first still works, then the first is revoked. Rotating a single credential in place causes an outage between the change and the redeploy, which is precisely why manual rotation gets postponed indefinitely.

What Do Saudi Organisations Need to Consider?

Three factors apply specifically to organisations operating in the Kingdom.

Where the vault lives is a regulatory question. A secrets manager holds the credentials and encryption keys protecting your systems and, by extension, personal data. If that platform is a cloud service hosted outside Saudi Arabia, the material protecting Saudi personal data sits under another jurisdiction. Under the Personal Data Protection Law (PDPL) administered by the Saudi Data and Artificial Intelligence Authority, that belongs in the same conversation as any other cross-border arrangement. The National Cybersecurity Authority's Essential Cybersecurity Controls (ECC) address cryptography and identity and access management, and the NCA has issued separate Cloud Cybersecurity Controls covering cloud service use. Financial institutions carry the additional requirements of the SAMA Cybersecurity Framework. For regulated workloads, an in-Kingdom or self-hosted deployment is frequently the simpler compliance position.

Contractor credentials outlive contracts. Saudi IT delivery relies heavily on system integrators and specialist contractors, and project teams routinely receive administrative credentials to build and commission systems. Those credentials are rarely revoked at handover, because handover focuses on documentation and acceptance rather than access. Two years later the organisation has active administrator accounts belonging to a company it no longer works with, and nobody can say who still holds the password.

Build revocation into the contract and the handover checklist. Issue named individual credentials rather than shared accounts so revocation is possible at all, use time-bound access tied to the project period, and run an access review at practical completion rather than treating it as an annual exercise. This is the same discipline that applies to supply chain and third-party risk generally.

Credentials travel over messaging apps. Business communication in the Kingdom runs substantially through messaging platforms, and credentials get shared that way constantly, because it is the fastest route between two people who need to get something working. The message then persists on both devices, in cloud backups, and in the chat history of any group it was sent to, indefinitely.

The answer is a practical alternative rather than a policy nobody follows. Use a one-time secret link that expires after a single view or a short window, share through the vault's own delivery mechanism where one exists, and make that the normal route so people are not choosing between security and getting their work done. Reinforce it with security awareness training, because this is a habit rather than a technical gap.

Blue Edge, a technology distributor based in Dammam, Saudi Arabia, distributes NinjaOne endpoint and patch management and KnowBe4 security awareness training, which cover the device and human sides of credential hygiene.

What Are the Most Common Secrets Management Mistakes?

Six mistakes account for most credential exposures.

Deleting a secret without rotating it. The credential stays valid and stays in history, and the removal commit tells an attacker exactly where to look.

Treating environment variables as the destination. They leak into logs, crash dumps and process listings, and they still cannot be rotated without a deployment.

Baking secrets into container images. Image layers are preserved, so a secret added in one step and deleted in another remains recoverable from the earlier layer.

Leaving contractor credentials active after handover. Administrative accounts belonging to a company that finished the project two years ago are among the most common findings in an access review.

Sharing credentials over messaging apps. The message persists on every device and backup involved, with no expiry and no audit trail.

Never inventorying secrets. Protection covers the credentials someone listed. The breach comes through the one in a backup script that nobody remembered existed.

Rotate First, Then Clean Up

The single most useful habit in secrets management is knowing what to do in the first ten minutes after a credential is exposed. Rotate it, revoke the original, check the logs for use, and only then spend time on repository history. Teams that reverse that order spend an afternoon on Git while the live key keeps working.

The longer-term work is a ladder rather than a project. Inventory the secrets you have, including the ones in backup scripts and runbooks. Add pre-commit and pipeline scanning so nothing new enters. Move production credentials into a central manager with audit and automated rotation. Then, where the platform supports it, move to workload identity so there is no standing credential to protect.

Settle two questions early, because both are slow to fix later. Where the vault is hosted, given what it protects and which regulator asks. And how credentials issued to contractors are revoked when the project ends, which needs to sit in the contract rather than in someone's memory.

Frequently Asked Questions

• Does deleting a secret from Git actually remove it?

  No. Removing a secret in a later commit leaves the original commit intact, so anyone with the repository can still retrieve it, and the removal commit points at exactly where to look. Rewriting history removes it from the main branch but not from existing clones, forks, mirrors or backups. Always rotate the credential first, then clean the history, because rotation is the only step that ends the exposure.

• Are environment variables secure enough for production secrets?

  They are better than hardcoding and are not a solution. Environment variables leak into application logs, crash dumps and process listings, they are visible to anyone with server or pipeline access, and they still cannot be rotated without a configuration change and restart. Treat them as a transitional step toward a centralised secrets manager rather than as the destination.

• What are dynamic secrets?

  Dynamic secrets are credentials generated on demand with a short lifetime and revoked automatically when they expire. Instead of holding a permanent database password, an application requests one at start-up and the vault creates a real database user valid for a defined period. Because the credential expires by itself, a leak becomes a limited-duration problem rather than an open-ended one.

• What should you do first when a credential leaks?

  Rotate it immediately, then explicitly revoke the old credential, because issuing a replacement does not invalidate the original. Next, check access logs for use of the credential from unexpected sources across the full exposure period. Only then clean the repository history and ask anyone with a clone to re-clone. Finally, move the credential into a vault and add the detection that would have caught it.

• Where should a secrets vault be hosted for a Saudi organisation?

  That depends on what it protects and which regulator applies. A vault holds the credentials and encryption keys guarding your systems and any personal data behind them, so hosting it outside the Kingdom places that material under another jurisdiction and raises the same cross-border considerations as any other transfer under the Personal Data Protection Law. For regulated workloads, particularly in financial services and government, an in-Kingdom or self-hosted deployment is usually the simpler position.

---

Published 8 September 2026 • Last updated 3 October 2026 • This article is reviewed when standards, regulations or product guidance change.