Why Deleting Sensitive Information from GitHub Doesn't Save You

>> "API keys [...] need to be in your committed code"

> No they don't.

A better approach is what the rest of the comments here are suggesting:

(1) store your secrets (API keys, certs, credentials, whatever) in a highly-secure system, with both strong encryption and immutable audit logging around their access and modification;

(2) expose those secrets at run/compile-time via variables, such that the secret is never stored on-disk anywhere other than in the highly-secure system from (1) and in transient storage while in use;

(3) wrap an authz layer around variable access, so that only authorized services/users/hosts (those that have authenticated properly and who are allowed access via the authz policy established here) can read/write/mutate the secrets

It's (basically) the "privileged identity management" space; the challenge is that the commercial software in that market hasn't kept up with the combination of automated ops infrastructure and cloud-hosted dev tools. There are some ideas around how to do 1-3 better, with a devops/cloud-native design built in. (Full disclosure: I'm part of the founding team at a company doing this.)

Thinking of actually working on this. Seems like an interesting and useful little project. Can email users or create an issue on the repo.

That's a fantastic way to TELL attackers what filename to search for on a filesystem if they have access to your source code. Randomizing filenames and forcing an attacker to have to write a custom utility to find the path to files keeps you from getting hit by a number of drive-by hackings. And every single incorrect use of a credential must be recorded off-system and monitored. Avoid using defaults in general for any third party software and you can do things like generating random paths to S3 buckets that contain certificates and environment variables in your own software. S3 buckets are incredibly secure if you tack on CloudHSM plus use host certificates effectively with IAM policies.

Otherwise, I'd try to use keystore systems available on your respective OS or language platform toolchain (CSP on .NET, JCE for Java, I dunno wtf else you'd use for anything else because the only people I've heard of that want to go this far are all F500 enterprises basically with software in exactly those two languages only).

The PIM software I've seen in enterprise (stuff even older than what Cyber-Ark has) has barely even kept up with software from the early 2000s let alone modern automated operations infrastructure. APIs that are written for XML-RPC and even XDR for crying out loud (that implies that even TCP was a tough sell for them). Automating them has been an exercise in incredible pain for few rewards.

Even AWS CloudHSM is not revolutionary conceptually as much as from a compliance and paperwork standpoint. I think there really needs to be emphasis on a (4) - all secrets must be rotated and revokable on-demand and on semi-random schedule. The goal is to make any credential only valid for a period of time less than what an attacker that is already present on your systems would need to further increase presence or to compromise any of 1-4. Who cares if an instance is owned if it's up for maybe 10 minutes and can literally only communicate on a specific port to a specific server with a specific protocol?

Unfortunately, this is all only reasonable in a highly automated architecture and is basically impossible with almost every single company I've ever seen that's ever uttered the mere word ITIL because those companies tend to be people-driven cultures for everything, not process-driven (most companies try to add policies that are so ineffectual and meaningless that everyone reverts back to tribalism similar to how everyone defaults to e-mail when collaboration tooling is ineffective) that you have to figure out to be effective in cloud environments.

I do devops and security automation as well, and there's nothing self-serving about your points if you ask me.