Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Why automation must drive modern app sec testing

public://pictures/temitope.jpeg
Temitope Odemo QA analyst/pen tester, FinTrak
 

No application is fully ready for public consumption until it has undergone thorough security testing. But with the frequency of software releases on the rise, it has become difficult for security experts to keep pace.

The trend now is to shift responsibility for security to the left, meaning moving it toward the early stages of its development. That makes sense. Catching bugs early saves a lot of money.

But coding of an efficient and effective application is exhausting all by itself. Are developers really in a good frame of mind at that point to test the app for security? Most are not. But automation doesn't get cranky or burned out.

Automating application security should be a critical part of the software development lifecycle (SDLC). Quite simply, conventional testing methods can't keep up in a continuous integration/continuous delivery (CI/CD) environment.

Here's how automation can fill the gap.

SAST, DAST, and IAST

Automating your DevOps with enough security tools will help the CI/CD of applications and aid collaboration between the development, operations, and security teams by rectifying what can be conflicting goals. Developers want to push changes as often as possible, the operation team wants a stable application, and the security team wants a secure application. With good tools in place, all these tasks can be carried out seamlessly with collaboration between the teams.

Early in the SDLC, the development team can use static application security testing (SAST) to quickly scan raw code to determine if any software flaws and vulnerabilities exist and can immediately be remediated.

For the security team, dynamic application security testing (DAST) does black-box testing that can be used to find vulnerabilities in a running application. The tool injects malicious data into the application in the form of SQL injection and cross-site scripting. DAST is designed to capture any weaknesses that SAST did not detect, such as authentication and server issues. It can be used during pre-deployment in the testing phases of the SDLC and also post-deployment, after all go-live requirements have been fulfilled.

Interactive application security testing (IAST) is designed to detect security issues in application code. It runs like an agent in the application server and provides real-time detection of vulnerabilities by analyzing application patterns such as the traffic and execution flow.

The role of the SDET

The software development engineer in test (SDET), a role first devised by Microsoft to help replace manual, repetitive tasks with automation, has been emulated across the industry.

Some SDETs even develop their own automation tools to carry out tests. Since they understand the application coding from head to toe, they are in a position to develop tools and write scripts to test the application's functionality and to suggest ways to increase efficiency and reliability for the applications under test.

Automation leads to global acceptance

Many automation security tools are generally accepted globally, to the extent that some organizations will not award any application development contract to a software-producing company until it confirms that it has some of these tools at its developers' disposal.

What should be the norm?

So what should be expected of developers as DevSecOps shifts responsibility to the left, toward them? They need to be conscious of security and keep it in mind, but their focus should be on the functionality of the application. Automation is what is needed to fill the gap.

Keep learning

Read more articles about: SecurityApplication Security