Micro Focus is now part of OpenText. Learn more >

You are here

Home/Security/Application Security

You are here

Home/Security/Application Security
Testing at DevOps speed

Why automating your security testing is mission-critical

public://pictures/Jaikumar-Vijayan-Freelance-Writer.png
Jaikumar Vijayan Freelance writer
 

Automated security testing has become fundamental to supporting the speed-to-market requirements of modern application development environments.

Organizations that have implemented DevOps and CI/CD models to accelerate application delivery are under intense pressure to integrate security into the software development lifecycle (SDLC).  

One reason for this is heightening concern over data breaches. Application vulnerabilities have emerged as one of the leading causes of data breaches in recent years, and more than nine in ten web applications these days have one or more exploitable vulnerabilities in them.  

The other reason is compliance. The EU's General Data Protection Regulation (GDPR) and other privacy mandates increasingly require companies to ensure that security is integrated by design into applications that handle sensitive data.

Here's why automated testing should be seen as mission-critical to your organization's application security approach.

Limitations of conventional testing

Conventional methods for static application security testing (SAST) and dynamic application security testing (DAST) are not suited for the high speed of modern application development and delivery. They do not provide the near-instant feedback and alerts that are critical to supporting a development environment where incremental and near continuous product changes are the norm, experts say.

Top-performing DevOps organizations are already releasing code to production multiple times a day. By 2020, IT will be required to release applications as often as 120 times a year to meet business requirements, Micro Focus estimates.

To support application delivery at DevOps speed, security tests need to be automated, continuous, and baked into the SDLC so developers can get and act on notifications about security issues before code is committed, said James Rabon, senior product manager at Micro Focus Fortify. 

"A traditional application security scan at the end of release as a gating measure is largely a practice of the past. You can’t produce quality software at the pace of modern development without automated QA testing. The same is true with regards to security."
—James Rabon

[ Also see: Why app sec and QA testing teams need to partner ]

Suggestions for automated security testing

Most security tests can be automated to varying degrees through the lifecycle of a software product. Integrating a static code analysis (SCA) mechanism directly into the development environment, for instance, can help automate bug detection as code is being written.

All changes and additions to code are automatically analyzed so developers can be quickly alerted of potential security issues. Problems can be addressed with little of the delay and overhead involved in manual testing.

No actual developer action is required other than checking code in and scheduling a build, Rabon said. "[There are] no buttons to press [or] widgets to utilize."

Other security tests that can be similarly automated include:

  • Those that check for known security weaknesses and behaviors in code, such as the use of weak encryption ciphers and presence of SQL injection flaws
  • Those that check security features such as authentication, authorization, and auditing mechanisms
  • Those that scan production-ready applications for vulnerabilities

The payoff from automated testing

When security automation is properly implemented, it can help development organizations catch common bugs and identify unexpected software behaviors and performance-hindering issues early in the lifecycle. In fact, according to a survey by Sonatype last year, 57% of organizations with mature DevOps practices said they had already automated security testing throughout the SDLC because of such benefits, compared to just 13% of organizations with no DevOps practice.

Automation allows development organizations to go fast without having to constantly worry about breaking security, said Himanshu Dwivedi, founder and CEO of Data Theorem. Many software development teams are under pressure to ensure that apps comply with regulatory requirements and are adequately protected against external hackers and those with trusted access.

But, typically, development teams are understaffed, overutilized, and in no real position to manually review each product, even with outside help, because of the sheer volume of code being pumped out, he said. "Baking security into the automated workflows is the best route," Dwivedi said.

"Knowing that security is baked into a release—like brakes on a car—allows developers to speed through the process without giving a second thought to security."
—Himanshu Dwivedi

Your mileage may vary

Of course, there are caveats and limits to automated testing. For one, the pace of development should be taken into account, Micro Focus' Rabon said. Also, automated security scans have a cost associated with them from a time and resource standpoint. "Running [tests] many, many times a day, when the actual source is not changing as frequently as you are scanning, is a waste of resources," he said.

Triage is another issue. When automated security checks are built into the development process, at least some human effort is required to triage the alerts to identify the important and unimportant issues and to add context, Rabon said. Importantly, the development pipeline needs some kind of mechanism for remembering relevant and nonrelevant security defects so automated tests don't keep identifying the same issues over and over again.

For example, developers and auditors in an organization might treat a read-only table in a database as a trusted source, but an automated SCA tool might flag it as untrusted. In these situations, a mechanism is needed to mark the table as a trusted data source and ensure that that knowledge persists through the application's lifecycle, Rabon said. 

"The quality of static analysis results improves overall with the addition of application context provided by developers and security auditors. Unaudited security results from a baseline scan should not be used to break [builds] or to mark builds as stable."
—James Rabon

Automated security testing also does little to find flaws in application logic, Data Theorem's Dwivedi said. Tools are available to automatically review every single line of code statically and for executing an application dynamically to find runtime issues. But there are some tests that only a human tester can do, he said.

For example, the best way to see if a mobile app meant to wire money from one account to another is working securely is to have a human tester actually complete a transaction with it. "While automation can cover a lot of things, there is always application logic attacks that are best addressed with manual testing," Dwivedi said.

[ Also see: 50+ resources for test automation engineers ]

Don't break the mold

Ultimately the key to integrating security testing into the SDLC is to ensure minimal disruption to existing processes. Automated tests should, as much as possible, not create new processes or slow down existing ones.

If you create a new process that developers must adhere to, chances are they will do it for one year, because security might have the authority to insist on it, Dwivedi says. But eventually, developers will avoid processes that are inconvenient and find a way to work around them.

"The more app sec can fit into an existing developer process, the more success it will have long term."
—Himanshu Dwivedi

Keep learning

Read more articles about: Security, Application Security
Twitter Twitter Facebook Watsapp Email share