According to the most recent Verizon Data Breach Investigations Report, almost 90% of data breaches are driven by financial gain, up from 71% in last year’s report. Most noteworthy, however, is that cloud platforms are particularly at risk, with web application attacks increasing by 43%. As more information is stored within cloud infrastructures, and as more enterprises rely on web applications to maintain business continuity, security teams should consider how security controls can be integrated to DevOps without impacting productivity. However, the security market is often shrouded by acronyms and buzzwords. With the increase in automated security testing tools, such as SAST, DAST and SCA, it’s important to understand the difference between each of these practices, and when to use them in the development cycle.

DevOps is the convergence of software development and IT operations that aims to continuously build, test and release software. Understandably, DevOps is becoming an integral part of any business as it facilitates delivering new products to end users faster and driving increased revenue. However, failure to secure these digital assets can open organizations to cyberattacks resulting in operational downtime, loss of customer trust and even hefty fines from a regulatory body. The sharp rise of application layer attacks proves that enterprises must proactively address security issues earlier in the software development stage.

Step 1 of 7

14%

Which of the following best describes how you currently monitor and manage systems across your hybrid cloud environment?(Required)

Multiple separate tools for different environments

Multiple separate tools for different monitoring and management functions

Single consolidated dashboard

Custom built monitoring and management solution

No full monitoring and management solution

Don’t know

How valuable would it be for your monitoring and management solution to incorporate predictive analytics to help you identify and address system issues that are critical and not waste time or effort working through all the data and “noise” that is not critical?(Required)

Extremely valuable

Moderately valuable

Somewhat valuable

Slightly valuable

Not valuable

How do you most typically address potential system issues BEFORE they impact your operations?(Required)

Automated workflows and playbooks to remediate potential issues as soon as they are detected

An orchestrated response process that leverages automation, AI, and human expertise to rapidly respond to potential issues

Advanced monitoring tools such as predictive analytics and anomaly detection to proactively identify and address potential issues

Respond to issues as they arise, using manual processes and troubleshooting techniques

A combination of automated remediation, orchestrated response, and/or proactive monitoring to address potential system issues

Don’t know

Other

What methods does your organization use to control and monitor cloud/IT spending?(Required)

Centralized procurement processes

Pre-approved budget thresholds

Automated cost monitoring tools

Department-level spending controls

Regular cost audits and reviews

Cloud cost optimization platform

Approval workflows for resource provisioning

Native financial operations tools provided by the cloud provider

No formal controls in place

Don’t know

Other

Please specify:

Which methods do you rely on most to detect security vulnerabilities in your systems?(Required)

Automated scanning tools

Manual assessments

Vendor notifications

Threat modeling (for early detection)

None of these

Don’t know

Other

Please specify:

What are the TWO most common ways you prioritize vulnerabilities to address within your environment?(Required)

Based on potential impact

Based on exploitability

Regulatory compliance requirements

Based on CVSS scores

Risk-based analysis of multiple factors

First-in-first-out approach

No formal prioritization process

Don’t know

How do you typically handle system updates and security patches?(Required)

Automated updates and patches

Manually review and apply updates and patches on a regular schedule

A combination of automation and manual review

Apply updates and patches on an as-needed basis.

Outsourced update and patch management

No defined process

Don’t know

Other

Δ

The evolution of DevSecOps takes the concept of DevOps one step further, putting security where it should be: at the heart of the development life cycle, using automation. DevSecOps has helped security professionals understand how they can successfully integrate automated security processes without slowing down development while allowing DevOps to focus on what matters most – building and creating software.

There are a host of automated application security testing tools out there, each with unique benefits, that are commonly used in the agile software development cycle. This raises the question: what tools should we use, and when, to ensure a secure software development life cycle (SDLC)?

The Difference Between SAST, SCA and DAST

The most popular application security testing tools businesses implement in their development cycles are static application security testing (SAST), software composition analysis (SCA) and dynamic application security testing (DAST). Knowing the differences between them and when to use them is crucial to enhance your DevSecOps strategy and secure your web applications.

Static Application Security Testing (SAST)

As the pressure to deliver high quality and secure code increases, and DevOps embraces new agile methodologies and technologies, integrated static analysis within the continuous software development pipeline can help detect vulnerabilities early in the software development process from the inside out (white box testing). The benefit of a SAST solution is it doesn’t require a running system to perform code security checks and won’t slow you down like a manual code review or penetration test.

One aspect that makes SAST unique is that it automatically checks for vulnerabilities within the application source code, byte code or binaries, line by line. This ensures security weaknesses – such as those listed in the OWASP top 10 and the 2019 CWE top 25 – in the proprietary code are detected from the start and during development. As a result, developers can identify the risks and fix any vulnerabilities before they make it into production. They are empowered to shift left and recognize early code defects in the development cycle, a security best practice, which also reduces the cost of fixing security issues.

However, SAST does have some disadvantages in that it requires access to source code and the underlying framework, making it unsuitable for testing commercial off-the-shelf software (COTS) or working with outsourced development. It is also unable to identify runtime and environment-related issues, which makes it difficult to determine the actual and contextual risks of security flaws and suggest meaningful remediation.

Dynamic Application Security Testing (DAST)

Unlike SAST, dynamic application security testing (DAST) is done from the outside in (black box testing), and identifies vulnerabilities when the application is running. DAST tools crawl web pages, locate web services endpoints, inputs and outputs; it requires a working version of a web application for the testing to work. Without looking into the source code, dynamic analysis works to simulate penetration testing to uncover exploitable vulnerabilities and business logic issues from a hacker’s point of view, with reliable results.

Yet, because this scanning occurs towards the end of the SDLC (running applications), the findings can be substantial and often put additional pressure on DevOps teams to fix these runtime vulnerabilities on short notice, creating friction between the security and development teams. Further drawbacks of DAST include the risk that vulnerabilities can be found too late in the SDLC, resulting in rushed or delayed remediation.

Software Composition Analysis (SCA)

Releasing new features on a deadline means that developers often don’t write all their own code. The use of prepackaged open source code is commonplace in modern DevOps practices, and so is the need for security governance. Some SAST solutions now include software composition analysis (SCA) functionality to locate weaknesses in proprietary code and vulnerabilities in open source code.

SCA tools are designed to analyze the open source components by detecting software licenses, deprecated dependencies and known vulnerabilities and potential exploits in a codebase. SCA enables DevOps teams to manage their security exposure and license compliance while still allowing the use of prepackaged code to speed up development processes. In addition, composition analysis can be run and expanded to newer architectures, including containerized environments, to automate detection for publicly disclosed vulnerabilities within your containers and prevent those disguised in public registries, such as Docker Hub, from being brought into the project.

With open source components now present in 96% of commercial applications, the ability to spot software supply chain vulnerabilities in development, in and out of the cloud, are vital to reduce web application risks – all of which can be a potential entry point for malicious actors, as we’ve learned from the Equifax and SolarWinds breaches.

Choosing the Best Application Security Testing Tool

There is no shortage of application security testing tools. The real conundrum arises when decision makers are presented with a host of various options and pressured to choose. However, these tools are not mutually exclusive. Instead, they form a holistic, almost linear, approach to the entire DevOps pipeline from plan to implementation. What does vary, however, is the application development model. Which tool(s) should you choose for your specific use case? Here are some general guidelines:

Outsourced Development and Commercial off-the-shelf (COTS) Applications: When it comes to critical business applications for prepackaged code, black box testing is advised for enhanced security peace of mind. Without access to the source code, DAST scanning and/or penetration testing are ideal to test the running application for any critical software vulnerabilities before deployment and to monitor security compliance in the long run.

Internal Development and Software Customization: For businesses with the resources and infrastructure to create applications in-house, it’s important to build security testing into the SDLC from the beginning. Doing so can help protect against application vulnerabilities including cross-site scripting. For true DevSecOps, arm your development teams with SAST/SCA tools to ensure code security in the ‘code and build’ stage, and apply black box testing (DAST) for security assurance before deployment. Once deployed, regular penetration testing and continuous vulnerability assessment of the underlying infrastructure are also recommended to keep security issues in check with each new release.

As cyberattacks targeting web applications increase, it is essential for organizations to have complete application security across the SDLC, providing maximum security coverage for development and ensuring they can keep up with business operations.