| > Many platforms also have secrets scanning to ensure you don't accidentally do this too. The reason secrets scanning even became a thing is because of how often secrets get committed to git. Some of them even lead to intrusions. Uber (2016) – Attackers gained unrestricted access to Uber’s private Github repositories, found exposed secrets in the source code, and used them to access millions of records in Amazon S3 buckets. Scotiabank (2019) – Login credentials and access keys were left exposed in a public GitHub repo. Amazon (2020) – Credentials including AWS private keys were accidentally posted to a public GitHub repository by an AWS engineer. Symantec – Looking at hardcoded AWS keys in mobile apps, discovered they had a much wider permissions scope and led to a significant data leakage. GitHub – Over 100K public repositories on GitHub were found to contain access tokens. I've worked at companies with developers who didn't know that once committed, the secret remains in the history even if a subsequent commit removes it. It's not trivial, and involves rewriting the history[1]. There's also no way to fix clones of the repo, and there are a handful of other ways secrets can still leak. The most secure way to deal with secrets accidentally committed to git is to rotate the secret. 1 https://docs.github.com/en/authentication/keeping-your-accou... |
You can use this and crenedials rotation, amazing, I know...
https://docs.github.com/en/code-security/secret-scanning/abo...
https://docs.gitlab.com/ee/user/application_security/secret_...
https://circleci.com/blog/detect-hardcoded-secrets-with-gitg...
https://www.gitkraken.com/media/events/azure-spring-clean-20...
edit: used config/secrets management for as long as I can remember doing this cloud stuff (several years), so the excuses are very, very poor imho.