Oct 18, 2021

The Cloud Native Application Security Challenges and How to Avoid Them

Ron Vider
CTO & Co-Founder

Cloud native applications – overview

Over 500 million applications will be deployed using cloud native approaches by 2023, according to IDC. This staggering number is approximately the same as the total number of applications developed in the last 40 years. And it’s happening everywhere – in small, medium, and enterprise-size companies. This transition is also reflected in the dev community; according to the Cloud Native Computing Foundation (CNCF), 44% of all backend developers are cloud native.

The single-unit, monolithic application is rapidly morphing into hundreds of small, independent microservices. This refers to both the infrastructure and the logic implementation. Physical servers are transforming to multiple virtual layers – cloud, clusters, and containers. The logic implementation is shifting from one main service to a group of loosely coupled microservices, with some implemented in-house, some being open source, and others remaining as external services.

How cloud native application risk assessment differs from traditional apps

Cloud native application risk assessment poses major challenges for existing methods. Cloud native applications run in an ever-changing environment. It’s composed of a wide range of components gathered from several resources having a range of security controls. 

The components are deployed on virtual infrastructure layers, each also made up of various software constructs. All components – both application code and infrastructure layers – are glued together only in the runtime environment. This is the only point where they communicate with one another. This adds a level of complexity to a world that is “shifting left,” as it requires the assessment to also “stretch right” to achieve optimal results.

Standard/Legacy App Cloud Native App
Application code All code exists in a single monolithic app Loosely coupled microservices
Deployed on Server (VM or bare metal) Orchestrated containers
Internal communication In-code API calls (east-west traffic) between microservices
Ancillary services DB servers, queue servers, et al Components deployed on various clusters, as well as on public cloud services (e.g., BaaS)
Nature of vulnerabilities All vulnerable code paths exist within the same code base (source & sink) Flow usually spans across multiple layers using disparate microservices, cloud native configuration files, and cloud services

Cloud native apps – an ever-changing map

When performing runtime testing for cloud native security to assess application layer risks, a major challenge is to understand what the environment looks like. That is, which components are deployed, how they communicate (flow tracing), and applicable rules of communication (micro-segmentation).

Moreover, all components are dynamically deployed and removed according to current application status. A current map and communication snapshot might differ from that of a few minutes ago, or before the latest deployment. From a real-time microservices risk-assessment perspective, this requires always-on, continuous mapping to know what it looks like at any given moment. 

Accurately assessing cloud native application risks requires knowing where vulnerable code exists, as well as how such vulnerabilities match the map flows. Without being able to see the complete picture in real-time, your cloud native application risk assessment will be focused on local issues and will miss critical vulnerabilities.

The cloud native mix

Usually, there will be two component categories inside your map:

  • Microservices developed in-house
  • External microservices

Using a variety of programming languages and versions, as well as a range of methodologies, your dev team creates in-house microservices. These are usually smaller pieces of code. External services are just that—external—thus there is no clear visibility into their inner workings. 

Thus, microservices risk assessment requires analysis of loosely coupled components and external services, giving consideration to various development languages, versions, and types—not an easy task.

New application layers & risks

The application layer isn’t the only component that’s changing. What used to be HW servers or VMs are now layers of software-defined infrastructure and services requiring their own risk assessment. But since they’re also part of an application, they could introduce additional risks to other layers or components. Therefore a thorough cloud native application risk assessment must also include these layers.

It all boils down to runtime

Given all of this, performing cloud native application risk assessment should only be done once an application is built and running. Without runtime visibility and microservices flow analysis, this is just a guessing game. This is exactly why legacy static application security testing (SAST) tools all fail when scanning cloud native apps. They can never see the big picture, never have access to the full application layer set, and have no visibility into the flow and communication between layers.

How to overcome these challenges 

Cloud native application development isn’t the future—it’s already here! Most new applications are already built and deployed using cloud native technologies. All pose cloud native application security challenges to existing (legacy) risk assessment tools. Cloud native runtime security testing requires a fresh approach – one that takes into account the following essential requirements:

  • Continuous deep mapping of all application components with respect to how they communicate with one another
  • Mapping of both internal and external microservices, as well as ancillary services being used (e.g., public cloud services)
  • Runtime assessment of all layers (app code, cloud, orchestration,
    and containers)

Any cloud native application risk assessment that doesn’t include all of the above is doomed to fail, generate many false positives and negatives, and waste your precious time.

Stay tuned for additional posts on this topic, where we’ll take a deeper dive into these topics.

October 18, 2021

The Cloud Native Application Security Challenges and How to Avoid Them

Ron Vider
CTO & Co-Founder

Cloud native applications – overview

Over 500 million applications will be deployed using cloud native approaches by 2023, according to IDC. This staggering number is approximately the same as the total number of applications developed in the last 40 years. And it’s happening everywhere – in small, medium, and enterprise-size companies. This transition is also reflected in the dev community; according to the Cloud Native Computing Foundation (CNCF), 44% of all backend developers are cloud native.

The single-unit, monolithic application is rapidly morphing into hundreds of small, independent microservices. This refers to both the infrastructure and the logic implementation. Physical servers are transforming to multiple virtual layers – cloud, clusters, and containers. The logic implementation is shifting from one main service to a group of loosely coupled microservices, with some implemented in-house, some being open source, and others remaining as external services.

How cloud native application risk assessment differs from traditional apps

Cloud native application risk assessment poses major challenges for existing methods. Cloud native applications run in an ever-changing environment. It’s composed of a wide range of components gathered from several resources having a range of security controls. 

The components are deployed on virtual infrastructure layers, each also made up of various software constructs. All components – both application code and infrastructure layers – are glued together only in the runtime environment. This is the only point where they communicate with one another. This adds a level of complexity to a world that is “shifting left,” as it requires the assessment to also “stretch right” to achieve optimal results.

Standard/Legacy App Cloud Native App
Application code All code exists in a single monolithic app Loosely coupled microservices
Deployed on Server (VM or bare metal) Orchestrated containers
Internal communication In-code API calls (east-west traffic) between microservices
Ancillary services DB servers, queue servers, et al Components deployed on various clusters, as well as on public cloud services (e.g., BaaS)
Nature of vulnerabilities All vulnerable code paths exist within the same code base (source & sink) Flow usually spans across multiple layers using disparate microservices, cloud native configuration files, and cloud services

Cloud native apps – an ever-changing map

When performing runtime testing for cloud native security to assess application layer risks, a major challenge is to understand what the environment looks like. That is, which components are deployed, how they communicate (flow tracing), and applicable rules of communication (micro-segmentation).

Moreover, all components are dynamically deployed and removed according to current application status. A current map and communication snapshot might differ from that of a few minutes ago, or before the latest deployment. From a real-time microservices risk-assessment perspective, this requires always-on, continuous mapping to know what it looks like at any given moment. 

Accurately assessing cloud native application risks requires knowing where vulnerable code exists, as well as how such vulnerabilities match the map flows. Without being able to see the complete picture in real-time, your cloud native application risk assessment will be focused on local issues and will miss critical vulnerabilities.

The cloud native mix

Usually, there will be two component categories inside your map:

  • Microservices developed in-house
  • External microservices

Using a variety of programming languages and versions, as well as a range of methodologies, your dev team creates in-house microservices. These are usually smaller pieces of code. External services are just that—external—thus there is no clear visibility into their inner workings. 

Thus, microservices risk assessment requires analysis of loosely coupled components and external services, giving consideration to various development languages, versions, and types—not an easy task.

New application layers & risks

The application layer isn’t the only component that’s changing. What used to be HW servers or VMs are now layers of software-defined infrastructure and services requiring their own risk assessment. But since they’re also part of an application, they could introduce additional risks to other layers or components. Therefore a thorough cloud native application risk assessment must also include these layers.

It all boils down to runtime

Given all of this, performing cloud native application risk assessment should only be done once an application is built and running. Without runtime visibility and microservices flow analysis, this is just a guessing game. This is exactly why legacy static application security testing (SAST) tools all fail when scanning cloud native apps. They can never see the big picture, never have access to the full application layer set, and have no visibility into the flow and communication between layers.

How to overcome these challenges 

Cloud native application development isn’t the future—it’s already here! Most new applications are already built and deployed using cloud native technologies. All pose cloud native application security challenges to existing (legacy) risk assessment tools. Cloud native runtime security testing requires a fresh approach – one that takes into account the following essential requirements:

  • Continuous deep mapping of all application components with respect to how they communicate with one another
  • Mapping of both internal and external microservices, as well as ancillary services being used (e.g., public cloud services)
  • Runtime assessment of all layers (app code, cloud, orchestration,
    and containers)

Any cloud native application risk assessment that doesn’t include all of the above is doomed to fail, generate many false positives and negatives, and waste your precious time.

Stay tuned for additional posts on this topic, where we’ll take a deeper dive into these topics.

This is some text inside of a div block.
This is some text inside of a div block.

Want to see what it looks like?