Usually you don't check your own code for security vulnerabilities. It's kind of like reviewing your own writing for grammatical errors, which can be difficult. It can be done but if you don't have experience to know what you are looking for, you might have a lot of trouble. Most people hire third parties to review their code.

With that said, when building software you should be building security in the entire time. This comes from good programming practice, structuring your code well, using internal code reviews, and writing your code in a way that the engineers working on it reduce the number of mistakes.

"Checking" your code for security vulnerabilities is not trivial and requires domain expertise in a lot of different areas which makes actually trying to answer this question kind of ridiculous.

When to check for security? Before I type a line of code, and right after I insert the semi colon for each line. If your code/logic is tight (and you weren't half asleep during programming), there normally shouldn't be any application-level security vulnerabilities so you should be thinking about security every single line...

For more detailed checks, Generally, everything I build is modular, so I do a sec overview after each module is complete. If you wait till the end, it can get really messy. After the app is ready to publish, I check the entire system - I attack it myself and try to plug in all the holes.

This is very dependent on the project size, team size, team knowledge, but ...

I would turn it into a habit, maybe a mini habit because you're busy. A mini habit is something "too small to fail" that you do every day/week or every time you commit.

* Read through all the changes you're going to commit. It's amazing how much you can spot by yourself when looking at it again. For every change ask yourself, could any of the variables/parameters be in some way malicious (nil, empty, something malicious only in this context). That's not the only thing to check, you'll have to know other types of vulnerabilities, too. But it's a start.

* If you're in a team, you could do the same by asking coworkers for reviews and use pull-request cycles.

The advantage of these small steps are that you won't need to reserve a _huge_ block of time for an audit just before release. And if you do reviews in a team, you'll also get somewhat of an outside view on the code. That doesn't mean of course there won't be any vulnerabilities anymore, but it can greatly increase code quality. A professional audit will still spot more problems, but I've seen teams getting better and better every time they had an audit.

Sometimes security vulnerabilities aren't directly visible in the code because they might only exist because of 2+ other features. For example: Many web applications allow you to change the password, but it requires to enter the old password. Now somebody adds a feature to change the email address of the user. That sounds like a normal feature. It’s secure by itself, because only the user can change her own email. So what if someone gained access to the account (a stolen session/cookie)? That means that someone could take over the entire account by changing the email address. And from there she could use the “Forgotten password” feature to create a new password which will be sent to the new email address.

* So in terms of habits, use some time every week on the same day and think about the bigger picture, the general security policy. And limit the time you spend on this. Otherwise you won’t want to do it next week, because it took too long last time.

(I wrote an article about habits and Rails security here, but it's applicable to all languages: http://bauland42.com/articles/a-week-with-a-rails-security-s... )

This is very dependent on context.

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.