A developer commits a configuration file containing a cloud API key to a public code repository. The security team discovers it two days later. What is the best remediation?

Hardcoded secrets are credentials, keys or tokens embedded directly in source code or configuration files. When code is pushed to a public repository, the secret becomes available to anyone, and automated tools continuously search public repositories for such keys. The only reliable response is to treat the secret as compromised: revoke it, issue a new one and review usage logs for abuse. Preventing a repeat requires removing secrets from code entirely, retrieving them at runtime from a secrets vault or managed secret store, and adding secrets scanning to commits and pipelines. Deleting the file in a new commit leaves the key in the repository history and in any clones or forks already made, so keeping the same key leaves it exposed. Making the repository private limits future viewers but does nothing about copies taken during the two days it was public. Encoding the key in Base64 is obfuscation, not encryption; it is trivially reversible, and scanners routinely decode it. Exam caveat: public repositories are listed separately as an attack surface, because exposure there is global and immediate. Operational check: confirm the old key is disabled, review the cloud provider's access logs for its use since the commit, and verify the scanner blocks a test commit containing a dummy secret.