Security testing, also known as white hat hacking, is a special art of testing. In this talk I will share my experiences as being a white hat hacker and how it differs from being a software tester in a development team.

Whereas a software tester is usually involved in the development process, a security tester may see the piece of software for the first time when the audit is about to begin. The information you get beforehand varies from an exhausting documentation overload to complete zero. Sometimes there's even hostility involved - the expectation is that the less you tell, the less security bugs will be found.

Another example is requirements. Testing usually involves a set requirements to compare to. Security testing on the other hand, may have no original requirements at all (security is an afterthought). There are frameworks to refer to, but you might have to make up your own requirements case by case. Sometimes very weird customer expectations and fears from the developers are sort of additional requirements.

What goes to similarities, in any testing activity your best reward is the feeling of having filed a critical bug and then verifying the fix. Although I must confess there's this special something when you get that first alert(XSS) popup.

Key takeaways from this talk:

  • What kind of security related testing you can do with your software without being a pentester or without having any information security background.
  • What to take into account and how to succeed when hiring external security consultants to do security audits or penetration testing.
  • What can you achieve with automation in security testing.