How to Build Security Into the QA Cycle

These days, many companies are developing software with fairly rapid release cycles of every week or even every few days. Thus, testing software security no longer looks like it used to. Spending several days or more analyzing the code for bugs is not viable. Security teams need a better way.

First, a primer on how to secure web apps in development. Broadly speaking, there are three stages to security quality assurance: code review, static application security testing, and dynamic application security testing.

1. Code review. Everyone should do security code review near the end of the development process. A checklist and established process enable teams to adhere to basic coding security practices. Since most teams do some form of code review already, reusing this existing process to add security assurance tends to be an easy win.
2. Static application security testing (SAST) has become the conventional first step of automated quality assurance. It is critical to review the finished software for defects or vulnerabilities that humans cannot find.
3. Dynamic application security testing (DAST) of the completed software is the third level of maturity. This can be automated or can involve human intervention. DAST helps focus code review and SAST on vulnerabilities that are exploitable in the real world and can detect logic errors and design flaws that are difficult to spot by looking at code.

The problem with using just these three traditional assurance techniques to ensure your completed apps are secure is that they are designed for a traditional software model of releasing or updating software in big quarterly or annual releases. At that cadence, there are plenty of days or weeks to run this assurance, find defects, and fix them.

For modern Agile technology development, it is simply too much effort to invest two weeks of preparation and setup to test software you are releasing and/or updating every week or two (or every day).

In addition, while these tests are important, none of them is a magic-bullet solution that reveals all the problems with the software or enables you to find and remediate them. SAST can report thousands of results of which only a small percentage are valid and need to be fixed, which means that you need to find the needle in the haystack. DAST is not guaranteed to provide insight and pen testing is expensive and not comprehensive. These tools are all part of a complete solution, but none of them is complete in and of itself.

RASP

Faced with these challenges, runtime application self-protection (RASP) can make a real difference. RASP protects your software from the inside all the time. It can protect apps while you are working on security QA, steps two and three. This technology enables you to run testing in the background after you’ve already released the app because you know it is protected in the interim. It can find vulnerabilities, notify you, and tell you where the problem is so you can fix it. In the event of a vulnerability in web apps that you’ve already sent out to the market, RASP brings your risk close to zero by preventing vulnerabilities from being exploited. You can release apps as fast as your developers can ship code, and be confident that a minor mistake won’t lead to all your sensitive data winding up on Pastebin.