Remove Secrets from Source Code
To remove secrets from source code, delete the plain text keys and rewrite git history. Next, revoke the old keys and load new values from an external store. Teams often start by moving database passwords into local files or build variables. Yet broad role permissions still let a leaked key read or change every table. How to remove secrets from source code and git history Deleting a password in a new commit does not erase it from git history. Anyone who clones the repo can still read old comm
Secret Detection in Code (TruffleHog, GitLeaks) + K8s Secrets Management: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To remove secrets from source code, delete the plain text keys and rewrite git history. Next, revoke the old keys and load new values from an external store. Teams often start by moving database passwords into local files or build variables. Yet broad role permissions still let a leaked key read or change every table.
How to remove secrets from source code and git history
Deleting a password in a new commit does not erase it from git history. Anyone who clones the repo can still read old commits and find the key. You must use a history rewrite tool to scrub the file from every past branch. Force push the clean history to your remote host and ask your team to re-clone. Before you clean the history, rotate the exposed password or API key right away. Assume bots or attackers read the key the moment it hit the remote repo. Once the old secret is dead, set up your app to read from secret stores. Build pipelines and cloud hosts can pass secrets to the app at start time. You should also add pre-commit scanners to your local git workflow. These scanners check every file before a commit and block patterns that look like keys.
Why external secret stores still leave runtime gaps
Moving passwords out of code stops leaks in git repos and chat logs. It also lets ops teams rotate keys without asking devs to push new code. Still, secret stores only decide how an app or engineer gets the login key. Once a user or service logs in, the secret store does nothing else. The database or server trusts that session to run any command the role allows. Engineers who debug live issues still pull these keys onto their own laptops. A stolen laptop token or a bad query can still drop a table. Static roles also let one valid query dump thousands of customer emails or card numbers. Secret stores do not check individual SQL statements or shell commands in flight. They cannot mask phone numbers or national IDs in query results either.
How to reduce risk during live engineer sessions
Teams should separate how apps log in from how humans run live checks. Apps need scoped service roles that only touch the specific tables they use. Humans should not pull shared database passwords from a vault onto their local machines. Instead, link human sessions to your central identity provider with multi-factor checks. Grant write rights only for the short window needed to fix a bug. Log every query and command with the user identity attached for clear audits. Rewrite sensitive fields like emails and card numbers in query output by default. This keeps raw customer data off local disks even when an engineer runs a broad select.
Secret Detection in Code (TruffleHog, GitLeaks) + K8s Secrets Management: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Is deleting a file in a new commit enough to hide a leaked key?
No, git saves every past version of a file in the commit log. You must rotate the key and use a history cleaner to purge old commits.
What should I do first when I find a database password in git?
Revoke and replace the password in the database first to stop active misuse. Update your running apps with the new secret, and then scrub the git history.
Do secret managers stop an engineer from running a bad query?
No, a secret manager only hands out the password or login token. Once logged in, the user can run any query that the database role allows.