The main thing is to stay on top of it as best you can. You can hire teams to do security audits, but that can be a costly investment, especially early on. There are also automated tools that you can integrate into your test suite that will look for some of the most common mistakes. For Rails, there’s Brakeman which can also be run using Code Climate. I’d look for similar tools for your platform and add them to your test suite.
One of the best ways to improve security is to create a bug bounty program and official security page for responsible disclosure. Here’s an example security page that I created for Sifter. Once you’ve created a page, you can submit to various places that catalog companies that offer bug bounties, and the reports will come in. The good news is that you don’t have to pay cash for bug bounties. Just offering to give people credit on your security page is often enough.
Unfortunately, this is a double-edged sword, and it can be time-consuming to sift through the reports because the vast majority of them will be garbage. While there are a lot of really helpful people that will professionally inform you of vulnerabilities and work with you to put the right fix in place, much more are unprofessional, and some even make vague threats demanding that you acknowledge them even if their report is useless or incomplete. So make sure that you launch the security program on a week where you have set aside time to sort through the first wave of reports.
One other thing that will inevitably happen is that many people will run automated scanners and tools against your site regularly. While the first pass of these tools is likely to uncover some minor issues, they generally can cause a variety of problems from performance to rapid-fire exceptions in your app. In our guidelines, I explicitly stated that any vulnerabilities discovered with the use of automated tools used without advanced coordination with us were not eligible for acknowledgment.
To that end, it’s helpful to create a very specific set of guidelines about what is and isn’t valid as well. By explicitly stating that things like subdomain sites hosted by 3rd parties are not eligible, you can reduce some of the noise in the reports. This does a couple of things. It helps filter out the lazy people, but it also helps make it clear when you’re communicating with people whether they’re making an effort. With Sifter, 80% of our reports were from people who never even tried to create an account and login to test the application. They just copied and pasted our marketing site URL into their scanner and hoped to find something.
The best first line of defense is automation in your test suite. A responsible disclosure program is great as well, and simply a good practice, but you’ll want to make sure you’re ready for that first wave. Then, hiring outside professionals to do a security audit on a regular basis would be the next component as soon as you can afford it.
Probably some referrals should work.