Security for QA Testers: The Importance

Quality Assurance (QA) testing is a critical role for any application that is being developed. The purpose: to identify flaws within the application that effect how the application runs and the users that use it. Typically this has focused on the goal of identifying flaws that prohibited the application functions from performing as expected. When I say expected, I mean that the end user is not able to complete his identified task.

Over the past decade there has been a growing focus on the missing QA testing focus: security flaws. What makes a security flaw different than the other flaws generally identified? Most security flaws, at least exploitable ones, focus on the ability to make the application do something it was not intended to do. If the application is supposed to allow me to view my bank account and I can make it show me someone else’s bank account it indicates a security flaw. The assumption here is that I shouldn’t be able to view another user’s account.

Typically in QA, the test would ensure that I could see my account and the data returned was in fact my information when I requested it. It does not check things like authorization issues to see what happens when I attempt to view another user’s account.

This is the time for QA to add this type of testing to their current test cases. Recently released reports attempt to show that the security field is suffering by a huge shortage. While we do have may different types of entities that will test our applications for security flaws, the best one is our own QA teams. Here are a few key indicators for why QA is so important in security testing.

Proximity
With the exception of the actual developers, no one is closer to the development phase than the QA team. You may have heard that a bug found in production costs a lot more to fix than one found in QA or development. There are multiple reasons for this, which we will cover in a different article. The key here is that we are getting almost a pseudo immediate feedback process for bugs found to send back to development. Not only does this mean we don’t lose the time of the application going through multiple other phases of the lifecycle only to be sent back, but the developers will adopt better secure coding techniques much quicker.

Application Knowledge
Many security flaws are based on the idea that we are able to make the application do something it was not intended to do. While some flaws like injection flaws don’t require any knowledge of the application functionality, authorization/authentication/logic flaws do require an understanding of the application. QA should have intimate knowledge of how an application should and shouldn’t work. Having this understanding makes it more efficient to understand what is a flaw and what is correct functionality.

Bug Tracking
Most likely, QA already has some sort of bug tracking system. Lets be clear, a bug is a bug is a bug. It doesn’t matter that it is a security bug, a simple logic flaw, or a typo in the UI, these bugs go through the same process. They get identified, logged, reported, analyzed, ranked/prioritized, and handled. It doesn’t make sense to have a separate system for managing bugs based on classification. Place an indicator if needed to indicate it is a security issue so that a report could be created to give to the infosec team for audit or review purposes.

We have an opportunity, as QA, to step up and take responsibility and ownership of enhancing our testing of applications. Is it different than your current tests? Probably. Can we do it? You bet. Lets start working on getting security built into our process instead of relying on a number of 3rd parties to do it for us. As we have seen, that doesn’t work so well.