Micro Focus is now part of OpenText. Learn more >

You are here

You are here

6 best practices for application security testing

Jaikumar Vijayan Freelance writer

For all the talk about the need to integrate security into continuous integration and continuous delivery (CI/CD) workflows, DevOps and security teams continue to function in different silos at many organizations.

Unsurprisingly, security continues to lag in DevOps environments. A recent survey of 350 IT decision makers by 451 Research showed that half of all DevOps teams still have not incorporated app security into their CI/CD workflows, despite having a high awareness of the need for it.

Though DevOps teams have begun working on increasingly large projects and are releasing software faster than before, they are often doing so without a clear strategy for integrating security into the process.

In another survey of over 2,050 professionals from the DevSecOps community, 72% of of those surveyed described the security function as a "nag," and 48% of developers admitted that, while security was important, they didn't have enough time to spend on it.

Application security testing is not optional. Experts share six best practices for DevOps environments.

1. Use automated tools in your toolchain

Leverage automated application security testing tools that plug directly into your CI/CD toolchain, says Meera Subbarao, senior principal consultant at Synopsys Software Integrity Group. To ensure that development velocity and workflows are not disrupted because of security issues, make sure you have direct feedback loops that push actionable and prioritized vulnerability data back to your developers, Subbarao says. This is the best way to ensure that any security vulnerabilities discovered during coding are remediated in the most expedient fashion.

Subbarao says the 451 Research report shows that one of the biggest obstacles to successful DevOps is a lack of automated and integrated security-testing tools. "We found that security in DevOps is lagging, with respondents reporting that only half of their CI/CD workflow implementations include any application security testing elements," she said.

The need for security automation is growing rapidly because modern businesses require the ability to have their vulnerability scans and pen test results worked back into the DevOps framework so it can happen continuously, adds Anthony Lauro, manager of enterprise security architecture at Akamai. "[Mission-critical applications should be] tested more often, as they are in constant change and represent more risk to the organization," he says.

2. Shift all the way left—to the beginning

 The traditional approach of having application security testing as a check point before deployment is no longer efficient since new code is developed and deployed faster than ever before, says Erdem Menges, senior product marketing manager at Micro Focus Fortify.

In addition, development teams continue to expand their teams by continuing to hire by at a rate of 80 developers per just one application security specialist, he says. This imbalance makes the adoption of consultative application security management practice a must.

Application security specialists need to provide the application security tools and the process to developers and be more involved with governance and process management rather than hands-on testing—which is their traditional rle.

"By shifting security to left and embedding security controls as integral parts of the integration/deployment processes, security defects are detected earlier on in the process and are fixed more easily."
Erdem Menges

Pete Chestna, director of developer engagement at CA Veracode, said it's not enough to implement security testing earlier in the development lifecycle so you can catch and fix flaws more quickly. It is equally important for your developers to learn from the mistakes they are making so they don't keep making the same ones over again.

"When people talk about shift left, they typically stop at the IDE while the developer is coding," Chestna says. That's because, in terms of cost, the early development environment is considered the cheapest place to find and fix your software vulnerabilities.

But if you want to reduce those costs even further—and improve the velocity of your development—consider using the results from your SAST to teach developers the things they can do to make their code more secure. "Because you're measuring in the first place, you should see the impact of the training directly," Chestna says.

"Education is the farthest left of shift left and should not be neglected."
Pete Chestna

3. Keep an eye on your third-party code

Open-source and third-party components can help you assemble code quickly, which can be an especially great thing in a DevOps setting. But a single flawed component can compromise the safety of your entire application. A recent survey by Vanson Bourne on behalf of Veracode found an average of 71 vulnerabilities per application resulting from the use of third-party components. Yet only 23% of the organizations using third-party components had processes in place for testing the code for security vulnerabilities, and only 52% updated the components when security vulnerabilities were disclosed in them.

"A single vulnerable code component in an application can open the door for a massive security breach," Chestna says. "So keeping a carefully maintained inventory of the code components your application relies on, combined with frequent testing, is the best way to prevent a hacker from slipping through the cracks of your code components."

Patrick Sullivan, senior director of security technology at Akamai, recommends including open-source components in vulnerability scanning and application scanning practices.

4. Include abuse cases in your testing

When testing for application security, it pays to think like a hacker or a malicious user. Developers need to consider the different ways an attacker or user might use or abuse their access to an app to get at data or systems they might be interested in. It is only by anticipating what a malicious user might do with a feature that a developer can put the right controls on place for preventing its misuse.

"Fortunately various abuse cases and test cases for detecting issues can be scripted and integrated into the QA testing harnesses with little man-hour overhead," says Jeremiah Grossman, chief executive of Bit Discovery.

Unlike functional tests, abuse case models capture how an application behaves under different use and misuse case scenarios so developers can put proper mitigations in place. By scripting such tests into the QA process they'd be routinely run alongside other regression tests, Grossman says.

Additionally, leveraging and integrating whatever security features are available in your chosen software frameworks can have amazing benefits as well.

"Doing so will make it far easier for developers to create new features, securely, without having to think about it all the time."
Jeremiah Grossman

5. Don't forget static testing

Many organizations are prioritizing penetration testing and dynamic application security testing (DAST) over static application security testing (SAST), says Subbarao, from Synopses. More teams are conducting tests during the central build and unit testing phases rather than when developers commit code or while they are actually coding. That's a mistake.

Shifting security testing further left in your DevOps and CI/CD workflows is vital, Subbarao says. "DAST and pen testing are important techniques, but they cannot be leveraged until you have a running application in the later phases of the SDLC." Apply SAST earlier in the development lifecycle and try to catch errors in real time while your developers are coding or every time they check in code.

"SAST can’t find every class of vulnerability, but when it is implemented proactively, it can save developers a lot of time and rework."
Meera Subbarao

6. Integrate patching into your CI/CD

Attackers have a tendency to pounce on newly announced vulnerabilities, says Akamai's Sullivan. When new flaws are announced, malicious hackers typically tend to conduct mass scans to find vulnerable applications and systems that haven't been patched yet.

Integrating patch testing and deployment into the CI/CD and DevOps toolchain can sharply reduce the time required for identifying and mitigating security issues in your software, Sullivan says. It moves patch management away from the operations team and makes it more a part of the development process.

Virtual patching using tools such as web application firewalls also help speed the time to protection from new vulnerabilities while you work on deploying the more permanent patch, he says.

"CI/CD and DevOps are great tools to be able to quickly respond to new vulnerabilities and reduce the time until protection is deployed to production."
—Patrick Sullivan

Shift left early and often

Early inclusion of security in the rapid release lifecycle continues to be elusive, but it is vital to reducing risk and rework. Follow the best practices outlined above to get out front on application security testing.

Share your team's best practices on application security testing below.


Keep learning

Read more articles about: SecurityApplication Security