An .envrc file with https://pypi.org/project/keyring/#using-keyring also provides a nice solution for keeping secrets out of git for local development. Requires no central server, only your local key storage (eg: keychain for macOS).
Don't bother. If you push a secret: Do not pass go. Do not collect $200. Just rotate your secrets and move on. If you push your repo you should treat the contents as public information.
Not sure how valid this point is. If the attacker has access to a production server, he had also access to all needed production keys. Encrypted or not.
And the encryption secret for this is stored...how?
Those are manageable in some cases but if you’re safe from the beginning you never have to spend time on it later or wonder whether you’ve made a mistake in your calculations.
So if the attacker has already broken into our corporate networks and can access the internal applications directly, what's to stop them from just examining the environment variables directly to get the secrets from there?
I don't understand the added value of Vault. We have secrets committed to internal GitLab where you need an LDAP account to even view/clone the repo. The secrets are used for internal applications that make calls to external APIs (like a weather service). If the attacker can gain access to the GitLab source, surely it's equally trivial to just examine the environment variables of the internal application itself since the secrets will be in plain text.
And if the secrets are not in plain text (i.e. you are passing the secret encrypted), then surely the attacker need only examine the source code (which we've established he has access to) to see how to decrypt the secret from the environment variable.
Seems like an impossible chicken and egg problem.