The security testing has been a very important thing in the application development because security vulnerabilities may damage an entire application and the entire reputation of an organization, putting organizations at risk for potential security breaches.

To minimize the costs and the risks of security vulnerabilities, the security testings need to be performed sooner and more frequently throughout the development process. As the development teams have been using the automation to streamline the manual activities such as build, deployment and functional testing for years now, it is important to perform security testing as well.

By integrating, automated security testing into the continuous integration/continuous development (CI/CD), we catch vulnerabilities sooner, so that the potential risk and the financial risk can be reduced.

In this article, we look into five ways of automated testing tools.

1. Static Application Security Testing (SAST)

2. Detecting Open Source Software Vulnerabilities

3. Identifying Compromising Credentials

4. Dynamic Application Security Testing

5. Verifying Cloud Infrastructure Security

Static Application Security Testing (SAST)

SAST provides the earliest check-in opportunity, allowing us to identify potential issues at the coding stage, so we can resolve problems without breaking builds or allowing vulnerabilities to get passed to the final application release.

Commercial solutions such as Checkmarx help to identify hundreds of security vulnerabilities and weaknesses in custom code. We can also leverage many open source linters for our specific platforms to detect various vulnerability patterns that can compromise code security.

Detecting Open Source Software Vulnerabilities

Just because the code is secure doesn’t mean the entire application is protected. Most of the applications use a large number of dependencies, or third-party open source software (OSS) components. These may have various security vulnerabilities and put our application at risk.

Tools such as Whitesource Bolt and Black Duck can scan all of our projects, not only to detect OSS components, but also identify and provide fixes for any known vulnerabilities.

Identifying Compromising Credentials

Human error is always a security concern, especially when it comes to credentials. Just consider how many times we've heard of developers committing code only to later realize they’d accidentally included a password. These errors can lead to high-cost consequences for organizations.

There are many tools that scan for secrets and credentials that can be accidentally committed to a source code repository. One example is Microsoft Credential Scanner (CredScan). Perform this scan in the PR/CI build to identify the issue as soon as it happens so they can be changed before this becomes a problem.

Once an application is deployed, we can continue to scan for vulnerabilities through the following automated continuous delivery pipeline capabilities.

Dynamic Application Security Testing

Unlike SAST, which looks for potential security vulnerabilities by examining an application from the inside the source code, Dynamic Application Security Testing (DAST) looks at the application while it is running to identify any potential vulnerabilities that a hacker could exploit.

OWASP Zed Attack Proxy (ZAP) is an open source tool for performing pen testing on web applications and APIs. Pen testing helps ensure that there are no security vulnerabilities hackers can manipulate. It can be installed as a client application or come configured on a docker container. OWASP ZAP scans can be incorporated into our pipeline to check every deployment for security vulnerabilities.

Verifying Cloud Infrastructure Security

Finally, in addition to validating the application, the infrastructure should be validated to check for vulnerabilities. When using a public cloud, deploying the application and shared infrastructure is easy, so it’s important to validate that everything has been done securely.

Each public cloud includes tools to help verify that the infrastructure has been provisioned securely. APIs can be leveraged to check immediately after deployment in lower environments to help ensure any infrastructure security issues are caught before they get into production. Additionally, tools such as InSpec provide compliance-as-code to enforce the intent of provisioned infrastructure is always being met.

Enabling continuous security validation through the CI/CD pipeline can help fortify applications against an expanding array of security threats that can lead to significantly higher costs and exposure. At the same time, automation tools can provide added layers of protection while meeting the organization application development demands.