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 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... )