There is a belief in the IT world that software security tests are very expensive. Such a statement causes many managers to give up on security tests claiming that the cost outweighs the potential benefits or long-term savings. This can be true… but only if you are not following best practices and running security tests with discipline and a well-defined system.
I would like to show you how the costs of development and testing application security can be reduced without creating a gap. We should take care of a few aspects of the software development process, keeping the aim and cost of our testing in mind.
The most effective way to reduce the cost of security tests is to consider this topic at every stage of the software development process. All team members should be driven by the security of the solutions they create and the topic should be mandatory during: defining requirements, architecture design, development, and testing. It’s probably only a few minutes more spent on any particular step but it gives us a better understanding of the security aspects in the team. Having discussions about sec topics on a daily basis allows the Quality Engineer (QE) to better understand the implemented solution and frameworks used, as well as flagging up security bottlenecks in the system. This allows us to avoid numerous security issues during testing and, just as importantly, makes testing faster and easier.
Security tests become very expensive when you need to hire an external company or an external specialist to carry them out. It becomes much easier and cheaper when a QE who is experienced in security testing works within the team. A Quality Engineer is needed instead of a tester and takes a more active role from the start, being involved in the project every day and at all stages. If you replace a single Quality Engineer with a traditional tester and a security consultant, it takes a lot of time for an external specialist to get to know the domain, requirements, detect sensitive data, and find vulnerable places in the application, architecture, and so on. An internal QE knows these things from having deeper familiarity with the project and is also experienced in security testing.
In addition, rather than a typical tester getting involved at the last moment, it is always easier and faster to perform security tests on a regular basis than once at the end of the project. Fixing possible bugs is also much cheaper as it requires ongoing tweaks rather than an entire system overhaul.
Technical aspects of security tests
We can also reduce the costs of testing in a number of ways:
- Reduce the scope by selecting important security areas. OWASP prepared over 100 test cases dedicated to web applications. Most of them are time-consuming and require preparation of the environment, test data, and tools. Deep knowledge about app architecture is also needed. Those test cases are designed for an application implemented in different technologies and languages, with architecture solutions, for different domains etc. A QE who is experienced in security testing can easily reduce the scope of security tests simply through knowledge of the application and the domain
- Select tools and use dedicated security labs. Security testing tools can be expensive and difficult to use. QEs often have to learn a tool and buy the license just to test one insignificant test case. We try to avoid such situations wherever possible. It is necessary to adjust the size and complexity of the tool to the scale of tests we want to run. For QEs experienced in security testing, it is worth investing some time in preparing his or her own testing lab with familiar and effective tools. In 90% of cases, using free or very cheap tools is completely enough. Keep in mind that such an environment should be maintained and upgraded to keep pace with technology changes.
In summary, adjusting the costs of security tests to the needs of the business and the application is entirely possible. It is just a matter of the right approach and having an engineer who works in a team on a daily basis.