SCA, SAST, CVA, DAST: 4 Common Security Terms Explained

Acronyms are everywhere in technology, and when automating security scanning tools in our development pipelines it is one of the first things we notice. A software security or ethical hacking team may know each acronym stands for, but outside of the security organization people may just be starting to see these terms. SAST, DAST, CSA, OSSM, SCA? What do these acronyms mean, and what exactly do they do?

Let’s take a look at some of the acronyms that you may encounter when taking a look at not just my reference architecture, but any architecture where security controls are being automated.

OSSM / SCA

The first and most important of all security acronyms you will encounter is OSSM, also seen as OSS, which stands for Open Source Software Management. Sometimes this term is also seen as SCA, or Software Composition Analysis. I’ve seen both terms used in large enterprises referring to the same practice of managing open source components. You can think of these terms as referring to “what others packed in your suitcase”. That is, things that you don’t develop.

What’s the difference between the two terms? It’s subtle. Where OSSM refers to the management of components that enter the development environment and what vulnerabilities they contain, SCA differs slightly and refers to how developed software utilizes these components. I also lump in code quality, linting, code complexity, and other non-security quality indicators into the SCA bucket.

Why is OSSM/SCA the most important acronym you will see? It’s the biggest bang you can make from a security perspective to improve code quality. The 2019 State of the Software Supply Chain report found that anywhere between 85-97% of any code base comes from external suppliers. Think about that. Your development teams code 3-15% of any application your organization builds. The rest is built by a community that isn’t under your organizational policy control.

Other than identifying the majority of security and policy issues in your applications, most OSSM/SCA tools are extremely fast with a low false positive rate. These are perfectly suited for the rapid development and deployment practices demanded by elite DevOps teams.

SAST

Static Analysis and Security Testing, or SAST looks at the code that your developers actually write (if configured properly). This is a code that is written that knits components together to create application or code that implements custom business logic.

These security tools look for vulnerabilities in the way code is written by your developers. For example, they can identify many of the OWASP Top 10 vulnerabilities your application may include - like SQL injection. SAST tools will crawl the source code of your application, identify where vulnerabilities exist (or may exist) and crawl up the call stack to see where the vulnerability may have been introduced.

If improperly configured, these tools can bring down an entire development pipeline and introduce an overload of false positives. I’ll discuss more about the pitfalls of Static Analysis and Security Testing in future articles in this series, but if you want to learn more right now check out my chapter called “The Problem with Success” in the book Epic Failures of DevSecOps: Volume 1.

CVA / CSA

In my reference architecture you’ll see the acronym CVA, which stands for Container Vulnerability Analysis. I’ll be updating this in the future to be Container Security Analysis (CSA). This term refers to the analysis of containers and images (Docker, etc) for security vulnerabilities.

There are two primary tasks that CSA tools perform. The first is scanning images for vulnerabilities; ripping through the layers of an image and looking for security issues in the components making up the base operating system and any software loaded onto it. For example, if an image is created built on a base Ubuntu image which runs an Apache web server, CSA will identify any known vulnerabilities.

Remember Heartbleed? Container Security Analysis would identify the vulnerable version of this component in the images being deployed and be able to report where they are in the deployment ecosystem.

The second part of CSA tools is to monitor container hosts for vulnerabilities and suspicious activities. For example, if you are deploying applications with Kubernetes, the term refers to the nodes underlying the orchestration platform.

DAST

Dynamic Analysis and Security Testing (DAST) tests an application’s security from the outside in. Consider it as an attacker's view of your application. It’s also like beating a box with a sledgehammer. These tools blindly scan an application as it runs in either a staging or production environment.

DAST tools are extremely noisy and will try to identify any and all vulnerabilities for any language or technology it can. Let's say that the application you are testing is a web service deployed on a Microsoft stack. This category of tools will identify any potential issues with the stack, but will also test for Java, Tomcat, etc., as well. It’s an extremely inefficient way of identifying issues that could have been detected further left in the development lifecycle. Without fine tuning, DAST tools could run for days without returning any meaningful results at all.

A Good Place to Start

These security tools are the four main controls that you're going to want to look at to detect vulnerabilities in your code when starting to adopt DevSecOps practices. Each tool performs different types of analysis on your application code, binary, or running instances to identify security issues. While you may not need all four in order to implement automated security controls you will ultimately encounter each one of these tools in some form or another.

Now that you know the acronyms, download the latest Reference Architecture for some inspiration.

Photo by Michael Dziedzic