The OWASP Top 10: A new approach for cloud-native applications

The OWASP Top 10 has been an essential guide for Application Security professionals since 2003 – and continues to be! It continuously evolves to keep pace with the latest threats and saw significant updates in 2021. But with the rise of cloud-native applications, we need to change our approach to application security – not to the Top 10 itself, but how we understand and remediate Top 10 vulnerabilities.

What are Cloud-Native Applications?

In cloud-native applications, code and risks are distributed across applications and infrastructure in development and at runtime. To understand risk for these applications, context is everything. It is no longer enough to identify an input validation vulnerability or a cloud misconfiguration. AppSec professionals need to understand the system as a whole.

In cloud-native application security, the biggest pain for security teams is understanding, prioritizing, and remediating vulnerabilities before delivering software to production.

How the OWASP Top 10 Has Evolved

The OWASP Top 10 at its launch in 2003 was a straightforward list of vulnerabilities that could be understood and approached in a simple way:

• A1 Unvalidated Input
• A2 Broken Access Control
• A3 Broken Authentication and Session Management
• A4 Cross Site Scripting
• A5 Buffer Overflow
• A6 Injection Flaws
• A7 Improper Error Handling
• A8 Insecure Storage
• A9 Application Denial of Service
• A10 Insecure Configuration Management

Fortunately, OWASP has kept pace with modern threats, and made updates in 2004, 2007, 2010, 2013, 2017, and most recently, 2021. Here are the latest changes:

We can learn much from these changes, which reflect a more complex, ever-changing, modern application attack surface.

The most significant change is the new category for “Insecure Design”, debuting at number four on the list. This represents a drastic shift in how we need to think about application security.

How Our Approach to Securing Cloud-Native Applications is Different

The inherent complexity of cloud-native applications necessitates an entirely new approach to security.

To understand the challenge, consider a SQL Injection finding by a legacy SAST vulnerability scanner. Without investigating context from across the SDLC, it’s impossible to understand the risk to the business. For example:

• Does the application store sensitive information? What type of information?
• Is the application internal or Internet-facing?
• Is the application protected by an API Gateway? If so, what are its authentication and authorization controls?

In order to combat this complexity, we need to identify and remediate vulnerabilities and other weaknesses as early as possible in the SDLC. This means at the design. The “Shift Left” approach to application security is more than a buzzword. It provides real value to both AppSec Engineers and Developers by minimizing the rework that takes place when security issues are identified late in the development cycle – or even in production! This reduces friction between Security and Engineering teams and gives developers more time to focus on providing customer value.

Agile, DevOps, and now DevSecOps have also fundamentally changed how application security needs to be approached. Unnecessary security gates and guardrails are no longer acceptable. Security processes must be managed intelligently according to a deep understanding of risk and no longer function as a “check the box” exercise.

What Does This Mean for the OWASP Top 10?

In addition to prioritizing OWASP Top 10 vulnerabilities by analyzing the full context of the application as a complex system, we must also approach individual Top 10 vulnerabilities in a new way:

A01 – Broken Access Control

While identifying access control violations can be a stand-alone topic to identify vulnerabilities that allow excessive privileges via HTML request modification and other techniques, fully comprehending the risk in cloud native applications is far more complex. It requires an understanding of not only the technical control and how it may be bypassed but the risk of the exploit. To do this, a security practitioner must understand a convoluted matrix of security controls where, only when analyzed together, can definitively indicate:

• if the data may be accessed
• the types of users that can access the data
• cloud and API settings
• compliance requirements, and more. 

A02 – Cryptographic Failures

Previously titled “Sensitive Data Exposure”, this involves weaknesses in encryption methods for data at rest, in transit, or in use that may expose data to theft via a variety of techniques such as network sniffing, brute-force cracking, decryption due to weak or deprecated algorithms or short keys, etc.

For cloud-native applications, sensitive data exposures are often the result of far more than simple encryption weaknesses. It combines those technical issues with cloud platform settings, API gateway configurations, authentication controls, authorization controls, and the type of data being exposed (PII, PHI, PCI, etc.)

A03 – Injection

Injection has been a mainstay in the OWASP Top 10 since its inception, which included individual items for unvalidated input, cross-site scripting, buffer overflows, and injection flaws. Developers and Application Security professionals need to be aware of all of these vulnerabilities today, but in cloud-native applications, the issue is one of prioritization. A vulnerability finding from a legacy SAST tool cannot be used to appropriately understand the risk. See above for an example of how a SQL injection vulnerability must be put into context.

A04 – Insecure Design

Insecure Design is a new category in 2021 – and one that was long overdue! There are a number of areas that Application Security professionals need to add to their repertoires to understand and address security weaknesses at the Design stage:

• Secure design starts with the user story! Many AppSec experts spend a significant amount of time reviewing tickets to understand the risks that may be introduced into their code. This is an example of the power of “Shift Left” thinking, where vulnerabilities and risks can be avoided before a single line of code is written!
• In Agile development practices, the code is the design. Dev teams no longer spend weeks or even months creating detailed design documents that must pass through multiple security reviews. AppSec experts must be able to clearly understand an application’s architecture and design by looking directly at the code.

A05 – Security Misconfiguration

A complete understanding of the risk of a security misconfiguration in a cloud-native application is much more complex than identifying an unnecessarily open port or default account that hasn’t been disabled. While there are a number of configurations that should always be fixed, their risk in cloud-native applications depends on context. It requires an understanding of data, people, and internal processes and compliance requirements.

A06 – Vulnerable and Outdated Components

As we have increased the speed of Agile development, the use of open source packages and dependencies has skyrocketed. This expansive use of dependencies has accelerated development but increased application complexity and the size of the attack surface. Outdated components are no longer easy to find and may be hidden inside a series of sub-dependencies.

A07 – Identification and Authentication Failures

While identification and authentication issues may seem straightforward and include weaknesses such as default passwords, session ID reuse, and other common issues, the impact of each failure is not. To be able to appropriately prioritize the risk of an ID failure, additional context must be taken into account, such as the data that user has access to.

A08 – Software and Data Integrity Failures

The SolarWinds breach highlighted the importance of CI/CD security and integrity. The failure to prevent malicious code injection during CI/CD can lead to not only a single instance of compromised software, but to the compromise of all the users of that software. In cloud-native applications, it is essential to not only secure each individual step of the development pipeline but also to have the breadth of data to compare a compiled binary to the source code in order to prevent a build-time code injection attack.

A09 – Security Logging and Monitoring Failures

There are additional layers of complexity to monitoring events and analyzing log files for cloud-native applications. Control mechanisms, settings, and logs are not always consistent, complete, or usable across all the systems needed to create and deploy a cloud-native application. Some events and log files may not be reachable at all as they are heavily reliant on mechanisms provided by external systems and vendors.

A10 – Server-Side Request Forgery

SSRF is not new to AppSec Engineers but it has been added to the OWASP Top 10 list because modern web applications are exposed to many more cloud services. The perimeter of the ‘server’ has been expanded more than ever before – demanding that we define it clearly and understand the severity of SSRF in the era of cloud-native.

There is a common theme when understanding how these OWASP Top 10 Vulnerabilities apply in a cloud-native world: context. It is impossible to properly understand, prioritize, and remediate security issues without a deep understanding of risk, which in turn requires making connections between data points from across the SDLC.

Having set SLAs to approach the OWASP Top 10 is no longer sufficient for cloud-native applications. Instead of relying on siloed vulnerability scores, Application Security professionals must gain a contextual understanding of risk.