Thankfully, the author realizes later what it they really did wrong here:

> What could be done to prevent this?

> Always test new version control GUIs before using them in the wild. There could be a bug that could expose your data.

> Encrypt access keys in config files instead of just leaving them exposed in the config file.

> Better yet, move access keys to a seperate config file, and exclude this from Git deploys with a .gitignore.

The fact this supposedly security experienced and conscious developer thought it was okay to have any kind of access credentials stored in a git repository is glaring.

You should consider all data in any repository public for security reasons. Publishing to github publicly made it quite obvious - but he could have been just as screwed over by people he gave access to the private repositories and people who have broken into github and can directly access the repositories.

Sure the numbers on both those groups are lower than the numbers of people apparently scanning public github for access keys - but the severity of the risk of keeping access keys and other secrets in your revision control are the same.

He could also separate code and configuration as per the docs but I suspect the hubris excludes bothering to read them...:

http://docs.aws.amazon.com/AWSSdkDocsNET/latest/V3/Developer...

> Encrypt access keys in config files instead of just leaving them exposed in the config file.

How do decrypt them when you app re-launches? How do you decrypt them automatically on every instance?

I've moved to using environment variables. I realise they have their own security challenges but at least I'm not accidentally going to git push the keys.

But you probably want to store the descriptions of the instances and what runs on them in a git repository. It doesn't matter whether you use env variables or something else. At some point you will have a git repository which stores the CM for your whole infrastructure.

I took it less as hubris and more of a way to imply to readers that no matter their experience they are not immune to the mistake he is going to tell you about.

I think it's definitely some hubris, because the mistake he made wasn't publishing to github publicly by accident. It was thinking a git repository was a good place to store secrets.

Why? It sounded like he is very security conscious. Thought he was creating a private repo in VS, immediately after he was notified deleted and recreated his keys. A pretty spot on course of action I think.

1. He stored credentials in source control rather than using configuration profiles as specified in the AWS SDK documentation.

2. He pushed code to a new repository without verifying the security configuration of the created repository (granted the tool made it easy to do this but you should create a repo, verify it, then push code).

3. He used his master AWS account key/secret in the code which gave global access to everything.

4. He didn't use IAM credentials with a restrictive policy set to just access the resources required.

No, clearly not security concious.

I'm a solution architect in the financial services industry and have been for 16 years. Never do I assume I know what the hell I'm doing.

Because anyone who ever says "I didn't think it was possible that I could be the victim of a data breach" is dangerously delusional, and in case I'm not being clear - wrong.

Also putting keys in (even a private) cloud-hosted repos is at least a step under what I'd describe as "very security conscious" for someone who self describes as working in the financial industry.

Right? Who spends 12 years in the software industry and doesn't actually test their work after doing shit?

Do you test the functionality of your git client or code editor? I personally generally expect them to work, as do most people.

On first use, i guess i have checked these parts one way or another. To assume things work the way you expect them might be the reason the bug was present in VS (if it ever actually was).