If that is true, that is seriously silly on behalf of Vine.
Multiple major security flaws:
1. Company source code should only be published to private docker images.
2. You should never store API keys or passwords inside the source code. A better approach is to use environment variables and have the container read those.
Be careful with environment variables. I've often seen that on some crashes all environment variables are dumped. While this should not happen in production configurations, it sometimes does. Furthermore, errors, along with the helpful debug parameters, are often sent by email and get into the hands of the wrong people (e.g. into the issue tracker where everybody has access to, including junior developers and interns who should never see production AWS keys).
A better way is to store it into a config file and store them into global variables at the start of the server (while globals are normally bad, it is ok to use them for thinks like configs if you don't plan to change them after initizalization. Environment vars are globals after all).
I'm not sure that's sufficient reason to say that config files are preferable to environment variables. Presumably the config file would be kept separately from the project code, so it doesn't reduce deployment complexity. Furthermore, environment variables work with basically every programming language and tool you're liable to use without modification.
I don't think using config files is a bad solution, it just isn't categorically better because some programs have been written to dump env vars on a crash.
There's no concept of "private" docker images in this case since they weren't using Docker Hub -- they were running their own registry (and didn't secure it).
I completely disagree with #2. It's incredibly valuable and helpful to be able to use source control to track API key updates. Unlike environment variables, this forces accountability whenever a change to your configuration is made. If you're worried about security, you can always encrypt the individual keys.
Sure it's OK if you have a small team and you can trust everyone on that team. But if you are in a big company with thousands of employees, you don't want a 'rogue' employee (or contractor ...ala Snowden) to start accessing and messing with your services without company approval - The fewer employees know the company access keys and passwords, the better.
Multiple major security flaws:
1. Company source code should only be published to private docker images.
2. You should never store API keys or passwords inside the source code. A better approach is to use environment variables and have the container read those.