Did you know that Amazon crawls public repositories on Github looking for secret keys? Neither did I. Neither did the ex-contractor that pushed my client’s code base into his public repo to boost his Github profile. There is nothing like a security breach email from Amazon that helps you sell a proper release process to your client. During the prototype, or MVP, things move very quickly. You get the app up and running, start adding features, and start bringing in external resources to help build your product. It’s pretty easy to skip some basic security principles.
Keep private data in the environment, not the config file
If you keep API tokens and AWS access keys hardcoded in a config file, then you are distributing those keys to every person who requires access to your code base. Instead, load that config data from the application environment. This not only keeps your data secure, but it makes it easier to setup a Production/Staging/Development release system.
Create Separate Repositories
So much easier said than done, I know. But do the frontend designers need to have access to your backend code? Is the new contractor working on a feature that could be decoupled from your primary application? This is not just a security measure. If your application is properly decoupled, then you have an easier time making changes without breaking the system.
So product managers beware! Proper devops may seem like an expense to push off until later. But really, making sure your application is easy to deploy will increase security, reduce ramp up time for new developers, and help stabilize your application.