Application Security Testing Best Practices – Part II

In our last post, we talked about some basic best practices that must be followed while performing security testing activities for an application. In this article, we will focus on application security testing best practices while working in a DevOps environment. 
We have often seen that the internal security team and DevOps team often work in different silos in many organizations. Though unfortunately, it needs to be accepted that security lags in DevOps environment and even though many decision-makers are aware of the importance of security in DevOps or DevSecOps, security still needs to be fully integrated into the CI/CD workflows. Here are some of the best application security testing practices compiled by our experts for conducting security testing in a DevOps environment. 

Automated Tools

As we have discussed in our previous posts, speed is an essential factor in a DevOps environment, and if security activities slow down the development process, the idea behind DevOps will actually fail. With the benefit of automation available at our end, it must be utilized. Automated application security testing applications which can be directly incorporated in your CI/CD must be preferred. We have discussed some of the static and dynamic testing applications here. 
Since the majority of the security testing activities will be automated, your internal security team can focus properly on serious issues while at the same time, the development process is not slowed down and the application developed is secure. 

Start from the beginning and start together

With cyber threats on the rise, the traditional idea of having security testing performed just before deployment now seems outdated. Coding, as well as security testing activities, must start simultaneously so that both the processes are closely related to each other. Moreover, an internal security team should also provide appropriate tools for the development team in order to assist them in maximizing the level of security.  

Third-party Code

Many times, the developers utilize open-source and/or third-party components which are publicly available in order to expedite the development process. However, a small flaw in an open-source/third-party component can invite the attackers for carrying out a major attack. The development team, along with the internal security team, should ensure that if any such components are used, they are properly tested to ensure that there are no loopholes left. 

Testing and Abuse cases

When you are testing an application from the security perspective, it is vital to assume the role of an attacker or a malicious user. The internal security team needs to explore all the possible ways an attacker can attempt to break into an application. And when the role of an attacker or a malicious user is assumed, the developers are better able to visualize the situation and implement appropriate controls to prevent such an event from happening.  
Unlike functional cases, abuse test cases capture how an application might behave under different uses, misuses, and malicious use cases. As a decision maker, such tests must be mandatorily added into the testing process so that they eventually become a routine for the concerned teams. 

Patching Integration in CI/CD

Newly found vulnerabilities always attract attackers from across the globe. Once a flaw is acknowledged, or a vulnerability is announced, the attackers start conducting application scans on a mass level to find applications and systems which have not been patched or updated yet. Our team recommends that if patching is integrated along with testing and deployment in the CI/CD environment, mitigation of security issues becomes easier and the patch management process becomes a part of the overall development process.