Editor’s Note: This is the first in a series of posts about the 2020 DevSecOps Reference Architecture developed by DJ Schleen. In this series DJ explains various parts of the pipeline architecture.
I just released an updated version of the DevSecOps Reference Architecture created last year that has been updated with additional components, corrections, and mobile deployment methods. Not only can it be somewhat overwhelming to look at due to its sheer size, but it is filled with acronyms that may not generally be known by those looking to integrate security controls into their DevSecOps pipelines.
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. However, 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 most common acronyms 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. OSSM refers to the management of components that enter the development environment and what vulnerabilities they contain. On the other hand, 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 an 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 Container Security Analysis (CSA). This term refers to the analysis of containers and images (e.g., Docker) 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 that 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 they 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, and other similar software 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.
OWASP
I've already mentioned OWASP above. However, I didn't provide an explanation of what it is. Long story short, OWASP stands for the Open Web Application Security Project. It is a nonprofit organization dedicated to improving the security of software, best known for its OWASP Top 10, which is a list of the top 10 software vulnerabilities.
Other than that, OWASP provides resources, tools, and guidelines for developers and organizations to enhance the security of web applications and software systems. The primary focus of OWASP is on web application security, but its principles and best practices can be applied to the broader field of software security.
CSRF
Cross-Site Request Forgery (CSRF) is a security vulnerability in web applications that can have serious consequences. In a CSRF attack, malicious actors exploit an end user's authenticated session to perform unauthorized actions on a different website without the user's knowledge or consent. Here's how it works:
When a user is logged in to a legitimate website, such as a banking or email service, their browser stores authentication information in cookies. An attacker creates a deceptive webpage or email containing a hidden request to perform sensitive actions on the legitimate site, like transferring funds or changing passwords.
The attacker then tricks the user into visiting this malicious page or clicking a link. Once the victim's browser loads the page, it unwittingly sends the hidden request to the legitimate website because it still has the user's active session cookies. The website, seeing the request as coming from an authenticated user, may carry out the action, all without the user's knowledge.
To defend against CSRF attacks, developers often use anti-CSRF tokens, which are unique tokens tied to a user's session and required for requests to be considered valid. Additionally, setting the "SameSite" attribute on cookies and checking the "Referer" header can help prevent such attacks, thereby safeguarding web applications and user data.
XSS
Another web-related acronym is XSS, which stands for Cross-Site Scripting. In essence, it's a prevalent web security vulnerability that occurs when a web application allows cyber attackers to inject malicious scripts into web pages viewed by other users.
These scripts can be executed in the context of a victim's browser, potentially stealing sensitive data, manipulating content, or even taking control of user sessions.
There are three main types of XSS attacks you should be aware of:
- Stored XSS, where malicious scripts are permanently stored on a target website;
- Reflected XSS, where the injected script is reflected off a web server and only affects users who click on a specially crafted link or visit a particular URL;
- DOM-based XSS, where the attack occurs within the Document Object Model (DOM) of a web page, typically through client-side scripts.
Preventing XSS involves input validation, output encoding, and implementing security mechanisms like Content Security Policy (CSP). If you fail to address these threats, you risk substantial security breaches which may cause harm not only to end users but your entire organization as well.
DoS
Up next, we have a Denial-of-Service (DoS) attack. DoS is a malicious attempt to disrupt the normal functioning of a computer system, network, or website by overwhelming it with a flood of traffic or other resource-consuming activities. The goal here is to render a service or resource unavailable to its intended users, causing inconvenience or financial loss to individuals, organizations, or even entire online services.
In a typical DoS attack, the attacker floods the target with an excessive volume of requests, such as network traffic, HTTP requests, or data packets, to consume the available bandwidth, processing power, or memory resources. This overload leads to a significant slowdown or complete unavailability of the targeted system, making it difficult or impossible for legitimate users to access it.
When it comes to defending against DoS attacks, it typically involves implementing several strategies, including network monitoring, traffic filtering, rate limiting, and the use of specialized hardware or services designed to absorb or mitigate the impact of the attack.
CSP
Content Security Policy (CSP) is a crucial security feature implemented by web applications to mitigate the risk of Cross-Site Scripting (XSS) attacks (I've already discussed what these are). Put simply, CSP is a security standard that allows web developers to define a set of policies and rules regarding the sources of content that can be executed or loaded by a web page.
For instance, when a web browser encounters a CSP header in an HTTP response from a website, it enforces these policies. CSP effectively restricts the execution of scripts, styles, and other resources to only those sources that are explicitly allowed by the policy. This helps prevent malicious scripts from being executed in the user's browser, as they will be blocked if not included in the approved list.
As for implementing CSP, it requires careful configuration and testing to ensure that legitimate content is not inadvertently blocked, as it can impact the functionality of a website if not properly set up. Properly configured CSP headers are a valuable addition to a web application's security posture, helping to keep user data safe from malicious attacks.
SSRF
And last but not least, we have the SSRF acronym, which stands for Server-Side Request Forgery (SSRF). It's a security vulnerability that occurs when an attacker tricks a web application into making unauthorized requests to other resources or services on the server's internal network.
In an SSRF attack, the attacker typically manipulates input data, such as URLs or parameters, to force the vulnerable server to send requests to internal resources, potentially accessing sensitive information or services that were not intended to be exposed externally.
Preventing such vulnerabilities involves validating and sanitizing user-provided input, using whitelists of allowed resources, and implementing proper network and firewall configurations. Additionally, security patches and updates should be applied to mitigate known SSRF risks in libraries and software components.
A good place to start
Security tools like SCA, SAST, CSA, and DAST are the 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 the security issues explained above. While you may not need all of them 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.
