[stouset]

Let's assume that all the above is true.

Even then, secrets don't even belong in source control. They aren't tied to a specific version of your software -- they're tied to state in other systems: AWS, your MySQL database, a third-party API, etc. Those systems will change independently of any particular release of your code, and having it versioned in source control doesn't actually make sense.

[emmelaich]

They are tied to the overall state of a application though. Much like db versions, 3rd party apis etc.

You must track them somehow and a VCS is obviously the right thing to store them in.

Depending on the circumstances, I use git-encrypt, Ansible vault, vim -x (encrypt files) or even RCS (no chance of pushing to a repo when RCS doesn't have that feature).

This one of my criticisms of the 12 factor app. They say put the config in the environment. That doesn't address the question. How and why does it get into the environment and from where?

https://12factor.net/

[toomuchtodo]

Secrets belong wherever it makes the most sense for them to be, balancing operational needs, security, and compliance requirements.

Storing secrets in version control (with permissions to the repo tightly controlled), encrypted (with the decryption key only available on the compute needing secret access), and used for rendering into a discovery mechanism (or directly injected into instance env vars) is entirely legitimate (and I know of several orgs doing this).