<a href="https://www.gartner.com/en/newsroom/press-releases/2021-11-10-gartner-says-cloud-will-be-the-centerpiece-of-new-digital-experiences" rel="nofollow" target="_blank">Gartner reports</a> that by 2025 over 95% of new digital workloads will be deployed on cloud-native platforms—up from 30% in 2021. This ongoing shift means modern application development is fundamentally changing—from slow and cumbersome, waterfall-based monolithic development to agile development of highly distributed microservices. These microservices communicate over APIs and are deployed as orchestrated containers, usually on public cloud platforms.
Cloud-native application development lets you make smaller changes more frequently, and quickly evolve apps to incorporate the features your customers or users need.
The shift to cloud-native development affects several important aspects related to application security. In this post you’ll learn about those requiring your attention when assessing and testing the security posture in cloud-native applications.
Since each application function is implemented as a separate microservice, developers push frequent code changes – sometimes several times a day.
Since each microservice operates on its own, it doesn’t affect other moving parts of the application; there’s no need to update any other code except that of the microservice that’s being changed. This enables faster rollouts and makes continuous integration/continuous delivery a reality. If a function or feature grows bigger and unwieldy, it can be hived off or partitioned into more granular microservices. This results in reduced complexity and easier app monitoring and management.
From a security perspective, this means low-cadence, periodic assessments are no longer a viable option. Each change in application logic and functionality needs close monitoring and should trigger an updated assessment. This means security processes should be embedded as an integral part of regular DevOps flow and CI/CD pipelines.
Microservices that make up a cloud-native app need an intrinsic mechanism to talk to each other – to send and receive data, metadata, and service requests.
APIs are used by microservices to communicate between themselves. Often a single inbound client request to an app frontend generates dozens of internal API calls. In addition, many modern applications publicly expose API endpoints. From a security standpoint, testing all of them should be a major factor in the overall assessment process. And they come in many forms (e.g., RESTful, gRPC, GraphQL), so it’s critical to use the proper testing approach in addition to appropriate automation tools.
Microservices are often deployed as individual containers, orchestrated by platforms such as Kubernetes. In many cases, an entire cluster is hosted on public cloud infrastructure. This scenario directly affects how its security posture should be approached. That is, there are cloud-specific risks to consider, as well as cloud-specific best practices that should be followed. Moreover, an insecure cloud configuration might elevate the risk of a mildly-vulnerable application. It’s critical to gain a complete view of all application layers and understand the context of each vulnerability.
In legacy applications, vulnerabilities manifest entirely within. That is, user input enters the application (source), then flows through the code until it reaches a sensitive function (sink). This entire flow exists in this single monolith, which means static code analyzers can follow the code and easily flag a security flaw.
In a distributed cloud-native application, user input might enter a microservice (A, the source), get stored in a message queue or database (B), then get pulled by another microservice (C, the sink) where it’s used by a sensitive function. Here, a static code analyzer could never follow this potentially vulnerable flow, especially where some of the flow passes through third-party logic that can’t be analyzed (e.g., cloud services).
Legacy assessment tools might flag local vulnerabilities in each microservice, but will fail to grasp the full context.
The inability of static application security tools (SAST) to flag multi-service vulnerabilities isn’t the only drawback – they’re also susceptible to false positives. In the prior three-step example, imagine microservice A sanitizes user input, such that input pulled by microservice C will never contain potentially malicious data. Thus, a legacy SAST tool might flag C as being vulnerable when in reality this would amount to a false positive.
Assessing vulnerabilities in highly distributed, cloud-native applications requires security testing processes to 1) initially map all possible end-to-end flows, 2) understand all of the logic, layers, and configurations, then 3) use this information as context to each specific vulnerability on each microservice.
In summary, here are the essential takeaways for security testing in cloud-native applications:
Connect with our experts for a quick demonstration to see firsthand how Oxeye helps identify and resolve the most critical code vulnerabilities