All private repos here, but we once had some inadvertently commit a development '.env' file with credentials in it to our remote Git repo (they did it before we added '.env*' to our .gitignore file). We might start peppering our .env files with honeypot keys just to track if they have somehow been compromised outside the company.
AWS is not fond of finding AWS keys laying around (limited permissions or otherwise). I once committed a key to a GitHub repo and AWS called me within 15 minutes. I've seen cases where they will then lock your account (preventing it from creating new EC2 resources) until the key is deleted.
Seriously, don't do this.
EDIT: as others have mentioned, private repos would be fine (and a good idea).
On servers in a text file in ~/.aws/credentials (where a lot of tooling saves AWS credentials)
On your developer laptop in the same locations
In application or systemd environment variable configuration files
In files named ’credentials’ or in application configuration files in private, sensitive Github repos
I used to use it to find out how other people use different library functions in the wild and it helped me to find good code examples many times in the past (especially when there were no documentation on the API). I wonder if there is any other code searching service with comparable coverage and quality.
I see value in the other examples, though, because they are dead simple tripwires, and, unless AWS is scanning your instances, they should never see this and it shouldn't be a problem.
* Login credentials: feed in response to detected phishing emails
* SSH keys: have SSH trigger an alert if certain keys log in
* Database entries: filter out the special ones in legitimate queries
The pain, at least for a small organization, is in managing: reacting appropriately to alerts, ensuring honeytokens are properly rotated.
well that sounds clever.