Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Adding Security to Testing to Enable Continuous Security Testing

Adding Security to Testing to Enable Continuous Security Testing

This item in japanese

Teams can be trained by security experts to become able to identify areas to add security testing in the test process and add security checks as part of functional test automation. This can lead to continuous security testing where security defects can be spotted at an early stage with higher security testing coverage in every release.

Christina Thalayasingam, a senior test engineer, spoke about continuous security testing at ConTEST 2021.

Security testing is a variant of software testing which ensures that the system and applications in an organization are free from any loopholes that may cause a big loss, Thalayasingam said. Security testing of any system is about finding all possible loopholes and weaknesses of the system which might result in a loss of information at the hands of the employees or outsiders of the organization.

To kick off security testing, security experts should train quality engineers about security and how to do manual security testing. Next, quality engineers can work with security experts to narrow down the tests for security testing and add value to existing test cases. This will lead to executing the security tests in sprint level activities, automating them, and making them part of continuous integration.

Quality engineers should add the security checks to their test process for each story, Thalayasingam suggested. This would help to find the obvious security vulnerabilities and a very early stay. The right guidance and training will help quality engineers to gain the security testing mindset.

Thalayasingam mentioned these reasons for making quality engineers part of security testing:

  • QEs are testing new features every sprint
  • QEs are known for thinking out of the box
  • QEs have a thorough knowledge of the application
  • QEs already have a testing methodology in place

The whole idea of having quality engineers looking out for security issues is to have obvious security vulnerabilities get spotted at an early stage, as Thalayasingam explained:

As the team moves into continuous security testing, they gain the ability to spot security issues that could be introduced by bug fixes, at an early stage. This process will help the entire team to be aware of the security issues when found. This enables the team to communicate and receive quick feedback mechanisms for every change.

Thalayasingam mentioned that releasing secure applications will help to gain customer trust. Also, it helps with avoiding unnecessary revenue impact and downtime. This will prevent the cost of securing the application against future attacks. Being a well secure application prevents your team from regulatory fines (GDPR), Thalayasingam said.

InfoQ interviewed Christina Thalayasingam about continuous security testing.

InfoQ: What can be done to find security defects at an early stage? What steps do you suggest?

Christina Thalayasingam: When working together, the security experts can train quality/test engineers to understand the security tests so that they could execute them manually.

This training can be enabled by the help of simulation tools such as:

  • DVWA
  • bWAPP
  • Bodgeit Store
  • iGoat
  • Goat Droid

Later security experts would work with the QEs and narrow down the tests to start with, and add value to existing test cases.

Some of these tests could be:

  • Authentication and authorization
  • Sensitive data in GET Request
  • File upload
  • Security response headers
  • Error handling

This would gradually lead to starting to execute the security tests in sprint level activities and eventually move to add them in automation and later part of continuous integration.

InfoQ: How can we embed security testing in the software development lifecycle?

Thalayasingam: Security needs to be thought, planned and discussed from the very beginning, from the requirements gathering phase. Security test planning should start at the design phase. Security white box testing should be incorporated during coding & unit testing. Black box testing and vulnerability scanning follows during the integration and system testing phase. Finally, penetration testing and vulnerability testing comes into the picture. Security needs to give the focus throughout the entire SDLC.

Periodic security testing using the following types is recommended:

  • SAST (Static Application Security Testing)
  • DAST (Dynamic Application Security Testing)
  • Application Penetration Testing

InfoQ: What open source tools can be used for security testing?

Thalayasingam: I can recommend the following tools:

  • Zed Attack Proxy (ZAP)
  • Wfuzz
  • Wapiti
  • W3af
  • SQLMap
  • SonarQube
  • Nogotofail
  • Iron Wasp
  • Grabber
  • Arachni

InfoQ: What types of security tests would be most useful? What can we start with?

Thalayasingam: Following are some of the security testing that your team can start looking at as they move into the culture running security tests:

  • Authentication and authorization
  • Sensitive data in GET Request
  • File upload
  • Security response headers
  • Error handling

InfoQ: How can testers advance their skills for security testing?

Thalayasingam: Test engineers could start by getting trained by security experts. Also, reading advanced security testing related material, for instance from the OWASP® Foundation, would help to become up-to-date with the latest trends. Getting hands-on experience on simulation tools or high vulnerable applications would help to understand how to execute attacks in your application. This would lead the test engineers to execute tests on the applications they are testing on a daily basis.

InfoQ: What have you learned?

Thalayasingam: Many think getting QEs/TEs to move into understanding security testing is an impossible task. As my team and I moved into adding security testing as part of our day-to-day sprint testing, we came up with various challenges and setbacks, but we were able to overcome them through constant training, practice and execution.

The team was able to achieve the ability to understand continuous security testing and contribute to it. The steps that I have shared with you have been highly beneficial for us. As we take small steps we are reaching into the big picture of achieving the complete inclusion of security testing into the testing process.

Rate this Article