.png)
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.
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.
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.
Usually, there will be two component categories inside your map:
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.
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.
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.
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:
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.
Eliminate uncertainty from the application security process, and save your development and AppSec teams time.
