The Fateful Pull request
Your colleague has created the following code change and requested you review and approve it.
Would you have looked a bit harder if you knew this change would in part contribute to a security vulnerability which led to about 1.5 million web pages being defaced, and possibly damage reputation of a piece of software that has built trust over many years?
If you are interested in the vulnerability, Sucuri's blog details how they found the vulnerability, and goes into a fair bit of detail. The counterintuitive part I find is this -- introducing an (int) cast to sanitize the input inconsistently actually formed part of the bug. It makes for food for thought the next time I do a code review.
However, this blog post is not about criticising the good people at Wordpress, but it is about secure code review practices. It only takes one unlocked door for a whole house to be robbed.
I hope you have a look at the Sucuri write-up, but don't stop there. Bring this up at your next team meeting. Discuss it. It doesn't really matter that this is PHP. A similar problem could occur with NodeJS due to the way parseInt works. If nothing else, it keeps security at the top of mind.
Software touches everything we do today - from boarding the bus; to visiting your doctor; to donating blood. Through regular postmortems, we can raise our collective intelligence and build the secure software that we all deserve.