Testing Hats Can Be White

Rajni Hatti, Ethical Hacking for Testers

Testers should not feel excluded from exploring security concerns just because specialists are available or tooling (such as the ZAP scanner) is running in continuous integration. 

Why? Rajni gave three reasons at CAST 2021:

• Testers tend to have a big-picture perspective and so perhaps ideas about where there might be vulnerabilities outside of standard attack vectors. 
• Testers are more likely to be involved in the design of features and so able to ask security questions or influence the priority of security in development backlogs.
• Security is a process not a product, and so regular review throughout the cycle is desirable versus throwing a build over the wall to some other team.

Naturally, there is opportunity cost associated with additional security testing, so the choice about what to do and how much time to spend on it should be determined by context. Similarly, any risk assessment should be a living document and oracles should be appropriate for the application under test at the time of testing for the purposes of the testing.

Rajni talked us through a project where she based a risk assessment on the OWASP Top Ten, looked at static code analysis tools for vulnerability scanning, at dynamic tools for fuzzing, and at design review to identify sensitive data obscured by naming convention.

Her experience was that even with a team of white hats at the company, the testing hat can still add value. And when security professionals are available, testers should be looking to collaborate with and learn from them to improve their own work.