Blog

A secure web application development process should always apply security QA testing checkpoints and techniques during the early stages of development and throughout the entire software development lifecycle. Special attention should particularly be given to the coding phase of development. Security QA testing mechanisms that should be used include during this phase include threat modelling, threat analysis, secure code review, and penetration testing.

Introduction to Security QA Testing

Web security QA testing should always be included as part of the existing QA process during the development of any new web application to ensure that an organization develops and releases only secure web applications. Unless security QA testing is performed to identify security vulnerabilities, web developers will continue developing vulnerable web applications for the clients – compromising the time and money of both parties, in addition to the web application itself.

Most web application development organizations have a QA (quality assurance) team that regularly tests the web applications during the development phase to ensure that the product and/or service works as it should, without bugs. Some of larger web app development organizations may invest very significant sums of money into the automation of some QA testing procedures to ensure the web application testing is consistent and of high quality. This begs the question – why is it that we still hear about data breaches in the news every day? The truth is, when it comes to security – QA testing often misses the mark.

What About Security?

Often, it comes as a surprise to the clients of web developers when vulnerabilities are discovered in their shiny new application – after all, web development is no small expense. Truthfully, all it takes is one small vulnerability, left un-remediated, that when exploited, could put the client’s data and, ultimately, their business at risk if not identified through security QA testing services.

While many web developers have staff or even dedicated departments for the identification of functionality issues, most of them do not have any form of security QA testing procedures in place. Actually, when a developer adds a new tab or link to a web interface, there are often documented procedures that are followed by the QA department to test the functionality of the button, however, more often than not, there are no procedures to test the security underneath the tab/button to ensure that it cannot be exploited.

The reason for this common discrepancy is that many web developers still differentiate functionality QA and security QA testing, or depending on experience, the they may simply unaware of the ramifications of an exploited vulnerability and the effects is may have on the customers’ business operations – however, a lack of integrity may also be a very real reason. It is important to recognize that security QA testing tends to initially add additional work and costs for a web development team. That said, the peace of mind that it brings for both the web developer and their clients make it a very worthwhile process.

Software Development Life Cycle and Security QA Testing

In information systems and web development, the systems development life cycle (SDLC) is a process for planning, creating, testing, and deployment of a web application. There are usually six stages in this cycle: requirement gathering and analysis, design, implementation or coding, QA testing, deployment, and maintenance. Security QA testing of web applications should be included in the software development life-cycle (SDLC) along with the regular QA testing.

If a security vulnerability is found after deployment, by a customer, or a threat actor, it will cost the client their livelihood, regularly fees, reputation and their bottom-line and; as a result, the web developer their reputation, cost of remediation, insurance premiums and any litigation fees. That said, while web developers are expected to do functionality testing when they write new code, it should be expected that they also engage with penetration testers, for security QA testing (Penetration Testing and Source Code review), to confirm that the new code is secure and cannot be manipulated or exploited by a malicious third party.

To be clear, even if a web developer insists they follow good security coding practises, by their own metrics, or insist they have no need for specific tool to perform security QA testing, penetration testing prior to deployment is the bare minimum security standard that should be engaged to ensure there are no web application vulnerabilities.

Quality & Security

Security QA testing issues in any form should also be considered a general QA issue. One could make the argument that web applications with ‘quality’ defects that impact functionality are more likely to have security vulnerabilities as well. In short, poor code leads to unpredictable behavior. From a user’s perspective, that often manifests itself as poor functionality. For resourceful threat actors, it provides an opportunity to stress the web application in unexpected ways.

By now, it should be clear that there are more than enough benefits to including security QA testing alongside functionality testing. It is unwise to assume that functionality testing is enough to give the ‘OK’ to a web application for deployment. They are completely separate undertakings and just as you can never assume that a new link or tab functions properly, you can never assume a website or new functionality is secure. That said, web application vulnerabilities that affect functionality may very well affect security, and vice versa.

At Packetlabs, we have had the pleasure to work with many security conscious web developers as well as their clients. Data breaches are happening on a daily basis as a direct result of poorly coded applications that lack the quality and security vital to mitigating poor functionality and vulnerabilities. At Packetlabs, we offer several security QA testing services that will help keep your organization out of the news. None of our clients have ever been breached by we didn’t catch – we take that very seriously.

If you would like to learn more about Packetlabs services, please contact us for more information.