Working in an agile environment we need to consider what we do and how important it is that we do it. We want efficiency, but not at the expense of quality. So when we think about secure code reviews we shouldn't assume they always need to be done.

We should also consider how much code should be involved in a secure code review, too much and it gets too complicated for our tiny human minds, too little and we'll fail to see how it might fit into the application.

A story that would typically be taken into a sprint is usually a good sized piece of work to perform a code review on. If it has been taken into a sprint then it should be possible to finish it within that sprint and the secure code review should also be performed before the sprint ends.

Before we even take a story into the sprint it's useful to look at the story with your 'security hat' on and consider whether or not a secure code review will be necessary for it. To help decide this we should look at whether or not the story will increase or change the surface area of the software in some way. If we're perhaps adding new fields, endpoints, libraries or storage then the story might stand out as requiring a secure code review, but with our agile mind set, we should try to ensure we only spend that time where and when it's needed. For example, some minor UI changes shouldn't need a review.