1. How - choose your own adventure. Do you have the funding for a full-time security engineer? If yes, you make that hire your de facto Director of Security and have them own the security ramping up process for your company. This includes doing penetration tests and assessments on your entire infrastructure, instituting policies for everything from audits to incident response, being the security arm of your software architecture going forward, and educating the rest of the development team about how to find the most common issues in their own code. This person will also facilitate the reviews of everyone's code before it hits production, recruiting a team of security engineers if/when you're big enough, and so on.
If you're not able to hire that person yet, you have to do it yourself. This involves hiring an outside consultancy and a responsible disclosure program. It also means you'll have to get training for your development team to learn basic security for their own software until you can afford a full-time security engineer. Outside consultancies are more expensive in the long run, and not as comprehensive as in-house unless you can afford to have them go at everything on retainer (most companies will only pay for them to audit big feature releases, and ignore technical debt and small/medium pushes to production).
Let's say you have to do this yourself and don't quite have the money for a consultancy or a security engineer yet. You'll want to get acquainted with all the common security errors in web and mobile applications. Read The Web Application Hacker's Handbook. It should be the only book you need, unless you want to specialize in infosec. As a developer, this will help you find almost all the problems you're likely to commit in modern web development.
Next, make a responsible disclosure program. Don't offer money just yet, because you aren't necessarily expert enough to assess real security reports from invalid ones that are just looking for easy money.
2. When - as often as your software development life cycle allows you to. You implement regular, consistent, rigorous methodologies like peer-reviewing source code and ensure that every piece of code is checked before being pushed to production. Likewise, every feature release is checked before being pushed to production. Every time code is scheduled to hit production, you do a security audit.
You also do thorough audits of your technical debt, i.e. everything that was released >6 months ago and is still maintained in your infrastructure. This is to be done monthly, if you have an internal team, less frequently if not.
Again, if you don't have full-time staff to focus exclusively on security, you'll be paying someone else to do it, and you'll want to prioritize feature releases.
I'm on the AppSec team at Accuvant LABS. If you have any more detailed questions, feel free to reach out. I'm always glad to point people in the right direction.
1. How - choose your own adventure. Do you have the funding for a full-time security engineer? If yes, you make that hire your de facto Director of Security and have them own the security ramping up process for your company. This includes doing penetration tests and assessments on your entire infrastructure, instituting policies for everything from audits to incident response, being the security arm of your software architecture going forward, and educating the rest of the development team about how to find the most common issues in their own code. This person will also facilitate the reviews of everyone's code before it hits production, recruiting a team of security engineers if/when you're big enough, and so on.
If you're not able to hire that person yet, you have to do it yourself. This involves hiring an outside consultancy and a responsible disclosure program. It also means you'll have to get training for your development team to learn basic security for their own software until you can afford a full-time security engineer. Outside consultancies are more expensive in the long run, and not as comprehensive as in-house unless you can afford to have them go at everything on retainer (most companies will only pay for them to audit big feature releases, and ignore technical debt and small/medium pushes to production).
Let's say you have to do this yourself and don't quite have the money for a consultancy or a security engineer yet. You'll want to get acquainted with all the common security errors in web and mobile applications. Read The Web Application Hacker's Handbook. It should be the only book you need, unless you want to specialize in infosec. As a developer, this will help you find almost all the problems you're likely to commit in modern web development.
Next, make a responsible disclosure program. Don't offer money just yet, because you aren't necessarily expert enough to assess real security reports from invalid ones that are just looking for easy money.
2. When - as often as your software development life cycle allows you to. You implement regular, consistent, rigorous methodologies like peer-reviewing source code and ensure that every piece of code is checked before being pushed to production. Likewise, every feature release is checked before being pushed to production. Every time code is scheduled to hit production, you do a security audit.
You also do thorough audits of your technical debt, i.e. everything that was released >6 months ago and is still maintained in your infrastructure. This is to be done monthly, if you have an internal team, less frequently if not.
Again, if you don't have full-time staff to focus exclusively on security, you'll be paying someone else to do it, and you'll want to prioritize feature releases.
I'm on the AppSec team at Accuvant LABS. If you have any more detailed questions, feel free to reach out. I'm always glad to point people in the right direction.